bugThe FreeType Project - Bugs: bug #38622, An alternative to autohinting:...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #38622: An alternative to autohinting: autopositioning

Submitter:  None
Submitted:  Fri 29 Mar 2013 10:09:53 AM UTC
   
 
Severity:  3 - Normal Item Group:  Wishlist
Status:  Works For Me Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  None

Wed 02 Mar 2016 08:33:43 AM UTC, comment #3: 

No further comments, thus I'm closing this report.

Werner LEMBERG <wl>
Group administrator
Fri 29 Mar 2013 06:43:48 PM UTC, comment #2: 

FreeType already has code which does what you are suggesting, I think.  You can activate it by defining AF_CONFIG_OPTION_USE_WARPER; the source code is in file src/autofit/afwarp.c.  Improvements to this code are highly welcomed :-)

Werner LEMBERG <wl>
Group administrator
Fri 29 Mar 2013 03:55:58 PM UTC, comment #1: 

I have an experimental implementation now.

For horizontal text, any vertical adjustments must be done per face+size combination, or the lack of proper baseline becomes rather noticeable and annoying. It is noticeable even after halving the optimal adjustment search range to -0.25 to 0.25, suggesting that there is no future on per-glyph adjustment strategy. On the other hand, in the horizontal direction this type of adjustments are generally tolerable and seem to blend well in the general kerning errors arising from quantization to the pixel grid, especially for LCD-filtered text.

So, partial success but this was harder than I expected. Further thought is required.

Anonymous
Fri 29 Mar 2013 10:09:53 AM UTC, original submission:  

One of the objectives of hinting is to improve the contrast of the glyph bitmap by moving the control points either by program or by an automatic heuristic such that the control points would match with the pixel grid. Hinting has the problem that the program must match the expectation of the glyph rasterizer, or for instance diagonal stem in Times New Roman z tends to vanish. The autohinter, on the other hand, doesn't always preserve glyph symmetry, which leads to results that are perceived as artifacting.

Therefore, unhinted glyphs are generally preferable as they more faithfully represent the shapes of the glyph, but they suffer from features not aligning with the pixel grid which reduces the perceived contrast of the text. Can something be done about this? It occurred to me that an alternative approach is possible: not hinting altogether, but simply translating the glyph within the pixel grid in order to maximize the glyph features coinciding with the pixel grid. The translations considered are of course less than half a pixel in x and y.

I have a simple hack which approaches unhinted glyph displaying based on this theory, and it can generally improve the average saturation seen by user considerably. The approach I have chosen uses FreeType as a black box, first translating the glyph a trial amount, scoring it, and improving the translation based on the results. In 45 iterations, it probably converges to the optimal translation. Attached are a few simple example results of Times New Roman in 32px size.

The cost paid by user is the jumpiness of the glyph baseline as the optimizer will occasionally move things up and down, but of course at most only half a pixel, so it is not certain that it will be noticeable. Additionally there is a tendency for cohesion in the corrections, as stems and serifs in the glyph are features which the algorithm will want to align to the pixel grid. In some cases such as !, the algorithm favors symmetric rendering.

Would it be possible for FreeType to use its knowledge of the control points and produce a suggestion for this kind of automatic translation as an alternative to doing hinting or autohinting?

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #27711:  autopositioned-bang.txt added by None (912B - text/plain - Here are a few sample renderings to consider)
file #27712:  autopositioned-plus.txt added by None (2KiB - text/plain - Here are a few sample renderings to consider)
file #27713:  autopositioned-d.txt added by None (3KiB - text/plain - Here are a few sample renderings to consider)
file #27714:  autopositioned-e.txt added by None (1KiB - text/plain - Here are a few sample renderings to consider)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by wl (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-03-02 wl Item GroupNone Wishlist
        StatusNeed Info Works For Me
        Open/ClosedOpen Closed
    2013-03-29 wl StatusNone Need Info
        Assigned toNone wl
    2013-03-29 None Attached File- Added autopositioned-bang.txt, #27711
        Attached File- Added autopositioned-plus.txt, #27712
        Attached File- Added autopositioned-d.txt, #27713
        Attached File- Added autopositioned-e.txt, #27714

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code