bugThe FreeType Project - Bugs: bug #42406, OTF and TTF versions of the same...

 
 

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

bug #42406: OTF and TTF versions of the same font render small type differently

Submitter:  Jerome <jeromeka>
Submitted:  Fri 23 May 2014 01:10:22 AM UTC
   
 
Severity:  3 - Normal Item Group:  None
Status:  Invalid Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  None

Jump to the original submission

Tue 25 Feb 2020 09:26:35 AM UTC, comment #6: 

I'm closing this bug as invalid; the suggestion to apply stem darkening to the TrueType engine is issue #42446.

Werner LEMBERG <wl>
Group administrator
Tue 10 Jun 2014 06:18:40 PM UTC, comment #5: 


Using FT_Set_Option to turn off stem darkening when poppler
inits FT solves the issue for me.

I've suggested to the poppler developers that they
disable this by default until ttf/cff rendering is made
uniform and the gamma issues are addressed.

We'll see if they accept that solution.



Jerome <jeromeka>
Wed 28 May 2014 06:05:32 AM UTC, comment #4: 

That's helpful.

Does this then indicate a problem in Fedora wrt gamma, what software component of the system is responsible for "using gamma
to blend the glyph density maps into the page background"?
Hopefully, there's a configuration I can tweak to fix this.

I suspect this may be affecting many many users who are not even
aware that something is broken. I believe In rertrospect I
may have been reading thousands of pages with extremely dark glyphs. Perhaps for years.

Jerome <jeromeka>
Tue 27 May 2014 11:38:25 PM UTC, comment #3: 

I suspect your system is not using gamma to blend the glyph density maps into the page background. This is the equivalent of using gamma 1.0. It has the general effect of making black text on a white background look darker, but it has numerous negative side-effects. The CFF rasterizer implements a stem darkening algorithm that assumes a blending gamma close to 1.8. That will give small text more contrast but without the negative effects. However, if you apply stem darkening and also blend with gamma 1.0, the CFF text will appear too dark. This is not intended!

As Werner suggests, we are considering adding stem darkening to TT. If you cannot change the blending gamma (blending is not a function controlled by FreeType), you can consider either adjusting or turning off stem darkening with FT_Property_Set().

Two other comments on your observations: 1) Acrobat uses stem darkening and gamma 1.8 for both TT and CFF. 2) The amount of darkening decreases as the text size increases, so zooming in will diminish the effect.

Savannah bug 42446 now describes the proposal to apply stem darkening to TT.

Dave Arnold <darnold>
Group Member
Sun 25 May 2014 11:12:16 PM UTC, comment #2: 

Thank you.

As a matter of personal taste, I don't like the dark apperence
at all. I was actually bothered enough by it to to go on this issue tracker safari.

> Acrobat's TT engine does that already,
> thus the rendering is very similar to CFF.


Yes, both both display much lighter then what poppler does for
cff (at least, as okular uses it) in adobe reader.

So, once stem darkening is added to the TT engine, ttf fonts
will conform in appearence to those of cff.

Does that eman that it is possible now to use FT_Property_Set
to conform the Adobe CFF engine to the appearence of the TT engine, that is to disable or diminish stem darkening?



Jerome <jeromeka>
Sat 24 May 2014 12:24:51 PM UTC, comment #1: 

This is a known issue, and we are working on it.  Maybe Dave Arnold can give more comments.

The problem is that the original code from Adobe expects correct use of gamma, but usually FreeType clients don't handle that in a sensible way, producing the results you are seeing: The rendering is too black.

Dave has recently suggested (in private mail) that FreeType gets modified to make both the auto-hinter and the TrueType engine behave similarly to the CFF engine, this is, adding stem darkening – Acrobat's TT engine does that already, thus the rendering is very similar to CFF.

As an intermediate solution we are probably going to provide different default values for the stem darkening in FreeType.

Note, however, that it is already possible to change the darkening parameters at run-time using `FT_Property_Set'.  In other words, Poppler could immediately adjust the rendering by using this function.

Werner LEMBERG <wl>
Group administrator
Fri 23 May 2014 01:10:22 AM UTC, original submission:  

Originally at https://bugs.kde.org/show_bug.cgi?id=335058 And then at
https://bugs.freedesktop.org/show_bug.cgi?id=78990

Okular and evince (and other) linux(-ish) pdf viewers rely on poppler
which in turn relies on freetype.

Included is a pdf demonstrating the issue. It contains two version of
the same font, the ttf version being generated from the otf original
using fontforge. also included is a screenshot showing the difference.

This is on fedora 20 x86-64 which packages freetype 2.5.0. The visual
difference disappears when one zooms in to the document.

My first guess that this is a hinting issue turned out false,I've
played around with ttfautohint and the FDK autohint and that doesn't
seem to be it.

James Cloos from the poppler tracker kindly informed me that recent
freetype uses a newer engine by adobe to render otf (CID 0C) fonts,
and indeed using ftview (at 12pt) as he suggested shows that different
engines are used to render ttf vs. otf and that individual glyphs are
rendered differently, the Adobe engine rendering them much
darker. Screenshot included.

Adobe acrobat reader displays both pdf lines (fonts) very similarly
and, strangely, seems to display both unlike the "Adobe" engine used
by freetype! That is, both fonts glyphs render much lighter then
freetype does using the "Adobe" engine. Perhaps that's a matter of
settings but significantly both fonts render similarly, which seems
like much saner behaviour.

I encountered this beehavior while trying to recreate a latex page
design as closely as possible, and I was very surprised to discover
that the format of the font has such an impact on how it's displayed
by the most popular document viewers out there.

Is this in fact a bug, by design, or an unfortunate outcome of having
two engines? if so, is there a workaround users and/or application
developers can use to ensure uniform rendering?


Jerome <jeromeka>

 

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

Attached Files
file #31417:  giveusahint-b.png added by jeromeka (27KiB - image/png)
file #31418:  ftview_comparison.png added by jeromeka (79KiB - image/png)
file #31419:  giveusahint.png added by jeromeka (9KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by darnold (Posted a comment)
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by wl
  • -email is unavailable- added by cloos
  • -email is unavailable- added by jeromeka (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 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-02-25 wl StatusConfirmed Invalid
        Open/ClosedOpen Closed
    2014-05-24 wl StatusNone Confirmed
        Assigned toNone wl
        Carbon-Copy- Added darnold
    2014-05-23 cloos Carbon-Copy- Added cloos
    2014-05-23 jeromeka Attached File- Added giveusahint-b.png, #31417
        Attached File- Added ftview_comparison.png, #31418
        Attached File- Added giveusahint.png, #31419

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code