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

 
 

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

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

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

Jump to the original submission

Sun 09 Aug 2020 08:14:00 AM UTC, comment #18: 


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.

- <_194785>
Fri 29 May 2020 04:20:45 AM UTC, comment #17: 


comment #15:

> Stem darkening is applied to very thin (otherwise vanishing) stems at very small sizes.

Dropout control already enforces a minimum of 1 pixel in bilevel rendering, and a minimum of ¼ pixel in 4×4 oversampling anti-aliasing.

>It is only appropriate with gamma correction

Anything to do with text rendering is only appropriate with gamma correction.

> and not desirable otherwise (including GDI).

What do you mean?

>Readability just wins over faithful shape preservation. We all know this.

Indeed, that's why hinting exists, to ensure uniform stems in bilevel rendering and minimize blur in grayscale rendering.

> As for sRGB, or Rev.601, or gamma = 2.2, or gamma = 1.8. That linear region minute and does not contribute much if anything to user experience. It is so happen that actual monitors in use have very wide range of gamma values to choose from. In my possession, I have a monitor with gamma of 1.6 and another with 2.1.

It is true that the monitor errors are often larger than the inaccuracy of the gamma approximation. The proper sRGB conversions is the most correct way to blend. It is however undesirable (if not used to distortions) to distort a text to 1.0 or 1.2 or 1.4 or 1.6 or 1.8 gamma because it is a much worse deviation from the standard sRGB than a gamma of 2.2 or 2.3.

- <_194785>
Thu 28 May 2020 08:26:37 PM UTC, comment #16: 

sRGB is visually indistinguishable from gamma=2.2.
Rec. 601Rec. 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.

Alexei Podtelezhnikov <podtelez>
Group Member
Thu 28 May 2020 07:39:30 PM UTC, comment #15: 

Stem darkening is applied to very thin (otherwise vanishing) stems at very small sizes. It is only appropriate with gamma correction and not desirable otherwise (including GDI). Readability just wins over faithful shape preservation. We all know this.

As for sRGB, or Rev.601, or gamma = 2.2, or gamma = 1.8. That linear region minute and does not contribute much if anything to user experience. It is so happen that actual monitors in use have very wide range of gamma values to choose from. In my possession, I have a monitor with gamma of 1.6 and another with 2.1.

 


Alexei Podtelezhnikov <podtelez>
Group Member
Thu 28 May 2020 03:46:59 PM UTC, comment #14: 


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?

- <_194785>
Thu 28 May 2020 12:46:47 PM UTC, 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.  I agree, though, that stem darkening shouldn't be applied in GDI mode.

Werner LEMBERG <wl>
Group administrator
Thu 28 May 2020 10:26:12 AM UTC, comment #12: 

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

- <_194785>
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>
Group 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>
Group administrator
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>
Group 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>
Group 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:
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.

Alexei Podtelezhnikov <podtelez>
Group 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?

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

Alexei Podtelezhnikov <podtelez>
Group 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>
Group 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

Dave Arnold <darnold>
Group Member

 

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

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 _194785 (Posted a comment)
  • -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)
  •  

    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 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.13-4b48.
    Corresponding source code