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

There's so much wrong with these pictures.

• The gasp table DISABLES anti-aliasing. The way it works is that a renderer may use bilevel rendering when the font specifies anti-aliasing, but a font specifying bilevel rendering may not be anti-aliased by the renderer. This is not what the font designer intended and by doing that you are making the already inaccurate renderer even worse.
• The anti-aliasing in gamma 1.0 is entirely an incorrect setting. It is nowhere near a linear interpolation. It is significantly closer to quadratic interpolation biased towards 0, leading to distorted anti-aliasing, when there shouldn't have been anti-aliasing in the first place.
• The stemdark setting then misses its point entirely. This is obviously not what the type designer intended, and thicker text can be done by using the bold fonts, which unlike the stemdark is hinted as the type designer intended.

sRGB is visually indistinguishable from gamma=2.2.
Rec. 601,  Rec. 709, and Rec. 2020 are visually indistinguishable from gamma=2.0.
The tiny linear segment in all of these helps to avoid singularity and associated comutation errors. It has no other purpose and should not be overemphasized.

comment #13:

> > Stemdark is unnecessary distortion in most cases.
>
> Well, the Adobe people disagree: They do use stem darkening in their (subpixel) ClearType engine version.

Yes, and it does distort the weight. How am I supposed to read text that has silently been replaced with an artificial Semibold version of it?

No, Adobe couldn't possibly use ClearType, as it's a registered trademark of Microsoft.

> I agree, though, that stem darkening shouldn't be applied in GDI mode.
>

You mean a reflowable layout?

Stemdark is unnecessary distortion in most cases. It should only be used if the Regular weight uses thin stems, as is the case in Microsoft Courier New, which is why Microsoft ClearType has a stemdark hack for Microsoft Courier New to convolute the 6×1 oversampled subpixel grid by performing a logical 'or' with itself shifted one oversampled unit (1÷6 of a pixel) to the left and right. But for all other fonts it distorts the text which is clearly undesirable. The gamma if existent should, of course, always be about 2.2 or 2.3, but the best option is instead of using gamma to use the proper sRGB/linear conversions, which is what TD renderer 1.0 and TD renderer 2.0 do. Any unnecessary distortions should not ever be enabled by default. However, if a person has damaged eyesight causing a bias in vision, the renderer might allow a distortion either prescribed by the doctor or chosen by the user, but for normal eyesight there should be no artificial distortions (those that just don't help snap to grid and such).

:-)

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'.

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.

TT has an interesting concept of device-dependent color compensation in rounding distances:
https://developer.apple.com/fonts/TrueType-Reference-Manual/RM02/Chap2.html#engine_compensation

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.

Do you mean something like this?

#ifdef TT_CONFIG_OPTION_SUBPIXEL_HINTING
src/truetype/ttgload.c:836
src/truetype/ttgload.c:839
src/truetype/ttgload.c:961
#endif /* TT_CONFIG_OPTION_SUBPIXEL_HINTING */

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.

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.

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