bugThe FreeType Project - Bugs: bug #42446, Autohinter and TrueType engine...


bug #42446: Autohinter and TrueType engine should provide stem darkening

Submitted by:  Dave Arnold <darnold>
Submitted on:  Tue 27 May 2014 11:13:18 PM UTC  
Severity:  3 - Normal Item Group:  Wishlist
Status:  Postponed Privacy:  Public
Assigned to:  Werner LEMBERG <wl> Open/Closed:  Open
Planned Release:  None

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Sat 18 Oct 2014 02:30:48 PM UTC, comment #11: 

I just committed a change that makes it easier to manipulate the engine compensation. As a prove of concept I played with well-hinted Times and Arial using the following settings.

      metrics->compensations[0] = 0;   /* gray     */
      metrics->compensations[1] = 16;  /* black    */
      metrics->compensations[2] = -16; /* white    */
      metrics->compensations[3] = 0;   /* reserved */

This was too aggressive in the hindsight. The before and after images are attached.

Alexei Podtelezhnikov <podtelez>
Project Member
Sat 18 Oct 2014 05:35:31 AM UTC, comment #10: 


I think the approach suggested in the OP is the way to go.  However, right now I have no time to examine this more closely, so I'm tagging it as `wishlist'.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Sat 18 Oct 2014 01:39:11 AM UTC, comment #9: 

Right. If you can implement this universal autohinter darkening using the concept of distance color, you can then possibly bytecode it. I see Werner all excited to add this new feature to his ttfautohint.

Alexei Podtelezhnikov <podtelez>
Project Member
Fri 17 Oct 2014 10:13:48 PM UTC, comment #8: 

Thanks Alexei.  Though, I think we're more interested in darkening in the TrueType autohinter than in the bytecode hinter.  We should aim for unified darkening setting and implementation.

Behdad Esfahbod <behdad>
Fri 17 Oct 2014 07:13:24 PM UTC, comment #7: 

I see some problems using TrueType "distance type" or "color" to darken glyph stems. The color values come from the glyph program instructions, with the default GREY(0) producing no adjustment. Only those parts of a glyph controlled by MDRP, MIRP, ROUND or NROUND instructions could be darkened and then only if the font were designed to do so. For example, an unhinted glyph would not be darkened at all. And it may be difficult to darken a glyph uniformly.

Dave Arnold <darnold>
Project Member
Fri 17 Oct 2014 04:59:25 PM UTC, comment #6: 

TT has an interesting concept of device-dependent color compensation in rounding distances:

It is coded in ttinterp.c, but not used as all compensation values are currently set to zero. I have a feeling that this is what should be adjusted or perhaps even set dynamically through API. To achieve the desired effect of stem darkening.

Alexei Podtelezhnikov <podtelez>
Project Member
Wed 15 Oct 2014 05:37:14 AM UTC, comment #5: 

Yes, the subpixel stuff is a good start.

Behdad Esfahbod <behdad>
Fri 05 Sep 2014 05:17:25 PM UTC, comment #4: 

Do you mean something like this?


I know that current implementation of FT_Outline_EmboldenXY is not perfect for points that are too close or collapsing so I would be cautious with this at the moment.

Alexei Podtelezhnikov <podtelez>
Project Member
Mon 02 Jun 2014 08:29:53 PM UTC, comment #3: 

I'm not an expert in the autohinter code by any means, but I think it should be fairly straightforward to make it do exactly that.

Behdad Esfahbod <behdad>
Wed 28 May 2014 03:20:59 AM UTC, comment #2: 

I expected that we might use the existing emboldening code. But it is a great idea to use the autohinter to measure stem width. Is there a way to invoke that part of the autohinter, then pause to do the emboldening, and finally do the full autohint processing?

Another, less accurate, way to estimate stem widths is to use the weight from the OS/2 table. In the absence of any other information, a default value for an average regular weight font can be used.

It is also handy to treat horizontal and vertical stem widths differently, and to embolden by different horizontal and vertical amounts.

Dave Arnold <darnold>
Project Member
Tue 27 May 2014 11:55:06 PM UTC, comment #1: 

I wrote to Stuart in private recently:

The way it would happen is to change the autohinter to apply the darkening.  Code to apply the actual darkening exists in FreeType already as part of the synthetic emboldening.  The only missing piece is the stem widths (which are coded explicitly in CFF, but not TrueType), but the autohinter has an idea of the stem widths already.  So, looks like it needs mostly wiring up and lots of testing.

Behdad Esfahbod <behdad>
Tue 27 May 2014 11:13:18 PM UTC, original submission:  

Hi Werner,

Over the past few months, I've seen more examples of FreeType clients misusing gamma. Usually, this is an attempt to improve text contrast when stems are small, on the order of one pixel or less. Usually this involves setting a gamma too low to "darken" black text, but I've also seen teams that set gamma too high to "improve" white text. Gamma has this apparent effect because it modifies the density of "mid tone" pixels, whose values are between 0 and 1. The problem is that gamma does not modify pixels at the ends of the range, where density is either 0 or 1.  Since the effect is not uniform, this leads to a geometric distortion in the perceived shape of the glyph. There was a recent example where the slight taper of a stem was exaggerated. There are other bad effects of incorrect gamma, but this one is the most common, since black and white text colors are so common.

In my opinion, "stem darkening" as performed by the Adobe CFF rasterizer is the correct solution to the low contrast problem. The rasterizer compensates for low contrast by uniformly adding weight to the entire glyph. This creates a minimum of distortion. And by gradually reducing the amount of darkening as the scaled stem width increases, we preserve relative weights of fonts (e.g., light vs. regular) and sizes.

I think it is a problem for FreeType clients that stem darkening is only available for CFF fonts. If gamma is set correctly (and I believe this is a function of physics and not of personal taste) then darkened CFF fonts look good but undarkened TT fonts look wrong. If gamma is misadjusted to "improve" TT fonts, then CFF fonts look wrong (or stem darkening is turned off or reduced to match TT).

What do you think about adding stem darkening to TrueType?

In CFF, we have a convenient way to simultaneously adjust the hints and the outlines, so the darkened result remains hinted. This same approach is not possible with native TrueType because of the way TT hints work. But with the autohinter, it should be relatively easy to darken the outline before computing the hints.

For native TT hints, a compromise is possible with "light" hinting.  In "light" mode, only horizontal stems are hinted, and hints that operate on vertical stems are carefully ignored. (This is true also for subpixel rendering, or LCD mode.) We actually do this at Adobe in our TT rasterizer. We darken the outlines in the x-direction only. There is no bad interaction between the darkened vertical stems and the native hints, because those hints are disabled. We don't darken the horizontal stems and they remain properly hinted. In Western scripts, vertical stems dominate the total ink anyway, so the limited darkening still works well. And grid-aligned horizontal stems serve the purpose of improving readability.

I propose that we apply stem darkening at least to autohinted rendering, since that is the most common mode for TT. This would solve a problem for clients using a mix of CFF and TT.


Dave Arnold <darnold>
Project Member


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

Attach Files:

Attached Files
file #32291:  Arial-0.png added by podtelez (55KiB - image/png)
file #32292:  Times-0.png added by podtelez (53KiB - image/png)
file #32293:  Arial-16.png added by podtelez (57KiB - image/png)
file #32294:  Times-16.png added by podtelez (55KiB - 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 wl (Posted a comment)
  • -email is unavailable- added by podtelez (Posted a comment)
  • -email is unavailable- added by behdad (Posted a comment)
  • -email is unavailable- added by darnold (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-10-18 podtelez Attached File- => Added Arial-0.png, #32291
        Attached File- => Added Times-0.png, #32292
        Attached File- => Added Arial-16.png, #32293
        Attached File- => Added Times-16.png, #32294
    2014-10-18 wl StatusConfirmed => Postponed
    2014-10-18 wl Item GroupNone => Wishlist

    Back to the top

    Powered by Savane 3.5