bugThe FreeType Project - Bugs: bug #38662, True Type hinting issue probably...

 
 

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

bug #38662: True Type hinting issue probably introduced in 2.4.x (it's fine in 2.3.11)

Submitter:  None
Submitted:  Thu 04 Apr 2013 06:46:15 PM UTC
   
 
Severity:  3 - Normal Item Group:  Incorrect behaviour
Status:  Invalid Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  None

Jump to the original submission

Wed 15 May 2013 10:28:45 AM UTC, comment #6: 

I've now re-examined the `Freetype - 2.3 vs 2.4.png' image.  This image shows the rendering of the auto-hinter!  2.3.11 and the current git version of FreeType yield exactly the same rendering results if native hinting (without subpixel support) is used.  (There are spacing differences, however, which are unrelated to the very problem.)

I'm closing this issue as invalid.  Feel free to add further comments if necessary.

Werner LEMBERG <wl>
Group administrator
Tue 09 Apr 2013 07:07:01 AM UTC, comment #5: 

Your Win XP snapshot confuses me a lot since the B/W rendering result completely differs from what FreeType produces; normally the differences are just a few pixels, if at all.  My first thought was that probably the new subpixel hinting code is the culprit, but even older FreeType versions produce completely different renderings.  I have absolutely no idea what's going on.

I have to investigate in more detail whether this is a bug.  Unfortunately, this will take some time.  Feel free to send a ping if it takes too long :-)

Werner LEMBERG <wl>
Group administrator
Mon 08 Apr 2013 06:16:00 PM UTC, comment #4: 

Hi Werner!


Thank you very much for your reply. I acknowledge that the font is very old and might have its own issues. These issues are even noticeable on the Freetype-2.4-Microgramma Issue.png screenshot, where you can see the font rendered by different applications including the ones not using FreeType. But anyway, the issues demonstrated by the applications not using FreeType look less scary then the rendering issues in the ftview demo.

Enabling the subpixel hinting algorithm (TT_CONFIG_OPTION_SUBPIXEL_HINTING) improves the quality, but unfortunately not to the degree shown by FreeType 2.3.11. If you take a look at the attached file Freetype - 2.3 vs 2.4.png, you may see 2.3.11 renders this font a lot better than 2.4.11 even with sub-pixel hinting on. The issue with 2.4.11 among the other visual artefacts, seems to affect the proportions of the glyphs. For instance, check out these words:

  • "brown" at 14pt - letter 'o',
  • "over" at 14pt and 16pt - letters 'o', 'e'
  • "lazy" at 14pt and 18pt - letter 'a'
  • notice FreeType 2.3.11 doesn't have problems with 'q'


We don't have old Macs in our office, but I found a WinXP machine. I switched font smoothing off, and made a waterfall in WordPad. Please see Microgramma-WinXP-NoSmoothing.png. It looks pretty bad, and I guess it's this way partially because of the font itself.

As a matter of experiment, I tried FreeType 2.3.12 and it renders as good as 2.3.11.

Putting it all together:

  • I have a not very good very old font MicrogrammaDMedExt (and several more fonts with similar problems).
  • Somehow this font is rendered perfectly by FreeType 2.3.12, 2.3.11 and some older versions of the library.
  • FreeType 2.4.x does not render this font as good as FreeType 2.3.x even when sub-pixel hinting is on.


I'm wondering what changed on the way from 2.3.x to 2.4.x? And what is more important: what was the reason for the change? So, the drop in the rendering quality could be:

  • A bug. Then I can simply postpone updating FreeType to the moment when the bug is fixed.
  • A feature. I mean, it could be some old compatibility code which was cleaned up, or it could be a fix to a bug which made this broken font to look good in previous versions. In this case I need to update my FreeType and find replacements to all broken fonts (this is my nightmare scenario =).


Do you think it is a bug or a feature?


Best Regards,
Alexander



Anonymous
Sat 06 Apr 2013 07:44:33 AM UTC, comment #3: 

OK, you have compiled FreeType without subpixel support.  However, the Windows rendering results in your images are certainly with subpixel rendering.  Try to activate subpixel rendering in FreeType, and you get much improved results.  But this is something different...

I've tested older FreeType versions, and they all have problems with glyph `q' at 17ppem, so even if 2.4.10 (without subpixel support) delivers better results than 2.4.11, it's far from good rendering.

This font is very old.  Looking at the `name' record table, I see that it has a field `Version 001.005'.  I thus suspect it has been automatically converted from a PostScript font.  (BTW, search for `MicrogrammaD-MediExte.otf' to get a CFF version.)

On the page

  http://ttfonts.net/font/25345_MicrogrammaDMedExt.htm

you can also see a waterfall; it looks like it has been generated with Windows, since the rendering results differ from FreeType.  Interestingly, it exhibits similar rendering issues.

Since FreeType is using Windows as the reference implementation, it would be most helpful if you can provide a waterfall image generated on Windows without subpixel hinting (this is, with ClearType switched off).  I have no idea whether this is possible at all with recent Windows versions...

Alternatively, rendering of this font using an old MacOS version (not OS X) would probably even better; given that the font contains the Apple glyph I think that the target was a Mac computer.  Old Mac fonts are not well supported in FreeType; some details in the TrueType specification are not compatible with Windows.  This is probably another reason why this font looks so awful.

Werner LEMBERG <wl>
Group administrator
Fri 05 Apr 2013 08:24:01 PM UTC, comment #2: 

Hi Werner,

I tried the latest version which I got from the git repository using these links:

git://git.sv.nongnu.org/freetype/freetype2.git
git://git.sv.nongnu.org/freetype/freetype2-demos.git

I built Freetype as a static library not touching its options (freetype/config/ftoption.h)

Then I built the ftview demo and ran it with this command line:
14 microgme.ttf

The issue is still there, please, see the attached screenshot.

platform: Windows 7
compiler: MSVC Express 2010

I experience this issue with every (tested) 2.4.x version on both Windows and Linux. Firefox (which as far as I know relies on freetype) on Linux has the same kind of troubles with this font.

When I used freetype 2.3.11 I had no problems on both platforms in my software, as well as in Firefox on Linux.

As I mentioned earlier microgme.ttf is not the only affected font, but it is affected the most. This is why I use it for test purposes.


Cheers,
Alexander


Anonymous
Thu 04 Apr 2013 08:11:35 PM UTC, comment #1: 

Please retry with the current git version of FreeType.  I don't see the artifacts marked in the image.

Werner LEMBERG <wl>
Group administrator
Thu 04 Apr 2013 06:46:15 PM UTC, original submission:  

When I upgraded from FreeType 2.3.11 to 2.4.8 and later to 2.4.11 I noticed a significant decrease of font rendering quality. Some fonts are less affected then the others. I think the issue has to do with the hinting algorithms.

The worst example so far is microgme.ttf (see the attachment) which I found in my Windows/Fonts folder. I'm not sure if it's shipped with Windows or has been installed with other software.

On the "Freetype - 2.3 vs 2.4" picture you can see the issue demonstrated using ftview demo. Both 2.3.11 and 2.4.11 libraries were built using default configs. Then I made one more build of 2.4.11 with the TT_CONFIG_OPTION_SUBPIXEL_HINTING option on, unfortunately it didn't help much.

On the "Freetype - 2.4 - Microgramma Issue" screenshot the freetype  2.4.x rendering issue demonstrated against other applications rendering that same microgme.ttf.

Let me know if you need more information. Thank you very much for your great work!!!


Cheers,
Alexander

-email is unavailable-

Anonymous

 

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

Attached Files
file #27811:  Microgramma-WinXP-NoSmoothing.png added by None (45KiB - image/png)
file #27781:  Freetype - current version - git.sv.nongnu.org.png added by None (77KiB - image/png - ftview - latest version from the git repository)
file #27774:  Freetype - 2.4 - Microgramma Issue.png added by None (755KiB - image/png - screenshots and the font)
file #27772:  Freetype - 2.3 vs 2.4.png added by None (153KiB - image/png - screenshots and the font)
file #27773:  microgme.ttf added by None (54KiB - application/octet-stream - screenshots and the font)

 

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

    Date Changed by Updated Field Previous Value => Replaced by
    2013-05-15 wl StatusConfirmed Invalid
        Open/ClosedOpen Closed
    2013-04-09 wl StatusNeed Info Confirmed
    2013-04-08 None Attached File- Added Microgramma-WinXP-NoSmoothing.png, #27811
    2013-04-05 None Attached File- Added Freetype - current version - git.sv.nongnu.org.png, #27781
    2013-04-04 wl StatusNone Need Info
        Assigned toNone wl
    2013-04-04 None Attached File- Added Freetype - 2.3 vs 2.4.png, #27772
        Attached File- Added microgme.ttf, #27773
        Attached File- Added Freetype - 2.4 - Microgramma Issue.png, #27774

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code