patchThe FreeType Project - Patches: patch #7471, Automatically fall back to...

 
 

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

patch #7471: Automatically fall back to autohinting when the font provides no hinting bytecode

Submitter:  Kevin Kofler <kevinkofler>
Submitted:  Thu 17 Feb 2011 05:04:35 PM UTC
   
 
Category:  None Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  wl Open/Closed:  Closed

Jump to the original submission

Mon 07 Mar 2011 04:22:39 AM UTC, comment #11: 

Currently, there is no hinting fallback support for unhinted CFF or Type 1 fonts at all – I've just filed a new bug report (#32696).  Note that noone has ever complained about this...

Both strategies are useful for handling broken fonts (and fonts which have both hinted and unhinted glyphs are essentially broken if used for screen display).  Usually, they are old, and many of them contain embedded bitmaps to compensate for the lack of hints.  But people today want anti-aliased display for all sizes, making such embedded bitmaps useless.  Similarly, many fonts with good hinting cause bad anti-aliased rendering since users ignore the values in the `gasp' table.

Werner LEMBERG <wl>
Group administrator
Sun 06 Mar 2011 06:01:25 PM UTC, comment #10: 


> In git, I've fixed the problem reported in #6 by adding a test
> whether the font is really TTF and not a CFF-based OTF.


While this fixes the regression, won't this bring the problem at hand back for unhinted CFF fonts?

> In particular, auto-hinting single glyphs won't give satisfying
> results since the glyphs won't blend with other, natively hinted
> ones.


Uhm, indeed, that also sucks. :-(

So what do you think is the best way to handle those fonts whose main purpose is to cover CJK characters, but carry hinting only for non-CJK characters? Should we lobby upstream to remove the partial hinting? Or use fontconfig rules to force autohinting for those fonts? (I'm worried about the scalability of the latter approach, which is why I submitted this patch in the first place. Unfortunately, it didn't turn out quite as effective as I had hoped.)

Kevin Kofler <kevinkofler>
Sun 06 Mar 2011 05:46:04 PM UTC, comment #9: 

In git, I've fixed the problem reported in #6 by adding a test whether the font is really TTF and not a CFF-based OTF.

Regarding comment #8: Supporting partially hinted fonts is a can of worms which I don't want to open.  In particular, auto-hinting single glyphs won't give satisfying results since the glyphs won't blend with other, natively hinted ones.

Werner LEMBERG <wl>
Group administrator
Sun 06 Mar 2011 04:53:29 PM UTC, comment #8: 

About the issue of partially-hinted fonts: I've done some testing: The patch is working as expected for Inconsolata, which is really unhinted, but our CJK fonts in Fedora all seem to be partially hinted rather than unhinted, meaning the patch does not help there. :-(

Kevin Kofler <kevinkofler>
Sun 06 Mar 2011 04:36:01 PM UTC, comment #7: 

Well, I think the best solution would probably be to use the autohinter if that PARTICULAR glyph has no hinting information. That should solve both the problem in comment #6 and the issue of partially hinted fonts (e.g. fonts which have hinting info for Latin characters, but not for CJK ideographs), where this patch doesn't help.

Unfortunately, I don't know how to code that. I'm afraid somebody more familiar with Freetype and/or font file formats would have to implement this.

Unfortunately, the code structure is such that the decision whether to autohint or not is taken before the glyphs are actually loaded.

Kevin Kofler <kevinkofler>
Tue 01 Mar 2011 04:03:44 PM UTC, comment #6: 

Hello :).

I seem to have encountered quite a few (if not all) OpenType CFF fonts that don't play nice with this patch... They fall back to autohint even when they do have PS hints. It does work as intended with TrueType or OpenType TTF fonts though.

I'm not sure if non TrueType outlines fonts are even supposed to have/fill the maxp table, which might explain this issue.

NiLuJe <niluje>
Sat 19 Feb 2011 10:13:51 PM UTC, comment #5: 

Applied now, thanks.

Werner LEMBERG <wl>
Group administrator
Sat 19 Feb 2011 05:33:22 PM UTC, comment #4: 

Silly me :-)

Werner LEMBERG <wl>
Group administrator
Sat 19 Feb 2011 03:15:03 PM UTC, comment #3: 

It's a logical or. It INCLUDES all non-TTF/OTF fonts.

If you don't like this, you can use:
( FT_IS_SFNT( face ) && ttface->max_profile.maxSizeOfInstructions == 0 )
(with the extra parentheses!) instead. That will exclude the non-TTF/OTF fonts instead.

I think those non-TTF/OTF fonts are handled by the upper-level "if" anyway.

Kevin Kofler <kevinkofler>
Sat 19 Feb 2011 06:08:46 AM UTC, comment #2: 

Thanks for the patch.  Looking at this:

-        if ( mode == FT_RENDER_MODE_LIGHT             ||
-             face->internal->ignore_unpatented_hinter )
+        if ( mode == FT_RENDER_MODE_LIGHT                   ||
+             face->internal->ignore_unpatented_hinter       ||
+             !FT_IS_SFNT( face )                            ||
+             ttface->max_profile.maxSizeOfInstructions == 0 )

I wonder about the `!' before FT_IS_SFNT, which looks wrong, since it excludes all TTFs and OTFs...

Assuming that you've tested the patch: Are you sure this is really what you want?

Werner LEMBERG <wl>
Group administrator
Thu 17 Feb 2011 05:32:15 PM UTC, comment #1: 

A more striking comparison (from http://mso-chronicles.blogspot.com/2009/10/mark-difference-ugly-fonts-in-fedora.html ):
http://2.bp.blogspot.com/_lh41g82r7rk/SuWk7rqgaJI/AAAAAAAAAQ8/AfWQU9yAHu8/s1600-h/mark-the-difference.png
(Look at the CJK characters. The CJK font in use here doesn't provide hinting bytecode, the Latin one does.)

This is from a FreeType from Fedora Rawhide with the BCI enabled, before it got reverted due to this issue.

The first 2 lines are control lines:
Line 1 is no antialiasing, no hinting.
Line 2 is antialiasing only.

The next 2 lines are showing the issue:
Line 3 is antialiasing+hinting, using the BCI.
Line 4 is antialiasing+hinting with forced autohinter.

The Latin font in this example provides hinting bytecode, so it actually looks better in line 3. On the other hand, the CJK font in this example doesn't provide hinting bytecode, and as a result, looks ugly as in line 2.

The desired behavior here is to have the Latin font rendered as in line 3, but the CJK one as in line 4. This is what the patch implements.

Kevin Kofler <kevinkofler>
Thu 17 Feb 2011 05:04:35 PM UTC, original submission:  

This patch fixes https://bugzilla.redhat.com/show_bug.cgi?id=547532 , which is preventing enabling the (no longer patented) bytecode interpreter in Fedora.

In current FreeType, when the BCI is built, if the font provides no hinting bytecode, there will be no hinting done on the font at all (unless autohinting is explicitly forced for that particular font in the fontconfig configuration, but doing so for every single unhinted font does not scale). The resulting rendering on a font without TrueType hinting bytecode can be seen in this comparison:
BCI disabled, autohinting used: https://bugzilla.redhat.com/attachment.cgi?id=378369
BCI enabled, no hinting: https://bugzilla.redhat.com/attachment.cgi?id=378370
With the patch, the first (autohinted) rendering will be used even with the BCI enabled.

The patch is based on a patch from http://www.infinality.net/blog/ , but cleaned up to:
1. drop the commented-out junk,
2. respect the indentation and whitespace style of the surrounding code,
3. rename face2 to ttface and
4. check FT_IS_SFNT before trying to use ttface members (probably not strictly needed because only TrueType has a native hinter at all and there's a check for FT_DRIVER_HAS_HINTER at the higher-level if clause, but I think it's better to write safe code).

Kevin Kofler <kevinkofler>

 

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

Attached Files
file #22718:  freetype-2.4.4-auto-autohint.patch added by kevinkofler (964B - text/x-patch - freetype-2.4.4-auto-autohint.patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by niluje (Posted a comment)
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by mkasik
  • -email is unavailable- added by anssi
  • -email is unavailable- added by kevinkofler (Submitted the item)
  •  

    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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-02-19 wl StatusNeed Info Done
        Open/ClosedOpen Closed
    2011-02-19 wl StatusNone Need Info
        Assigned toNone wl
    2011-02-18 mkasik Carbon-Copy- Added mkasik
    2011-02-17 anssi Carbon-Copy- Added anssi
    2011-02-17 kevinkofler Attached File- Added freetype-2.4.4-auto-autohint.patch, #22718

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code