The 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: |
- <_194785> |
Fri 29 May 2020 04:20:45 AM UTC, comment #17:
Dropout control already enforces a minimum of 1 pixel in bilevel rendering, and a minimum of ¼ pixel in 4×4 oversampling anti-aliasing.
Anything to do with text rendering is only appropriate with gamma correction.
What do you mean?
Indeed, that's why hinting exists, to ensure uniform stems in bilevel rendering and minimize blur in grayscale rendering.
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: |
Alexei Podtelezhnikov <podtelez>![]() |
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.
|
Alexei Podtelezhnikov <podtelez>![]() |
Thu 28 May 2020 03:46:59 PM UTC, comment #14:
|
- <_194785> |
Thu 28 May 2020 12:46:47 PM UTC, comment #13:
|
Werner LEMBERG <wl>![]() ![]() |
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.
|
Alexei Podtelezhnikov <podtelez>![]() |
Sat 18 Oct 2014 05:35:31 AM UTC, comment #10: :-)
|
Werner LEMBERG <wl>![]() ![]() |
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>![]() |
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>![]() |
Fri 17 Oct 2014 04:59:25 PM UTC, comment #6: TT has an interesting concept of device-dependent color compensation in rounding distances:
|
Alexei Podtelezhnikov <podtelez>![]() |
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?
|
Alexei Podtelezhnikov <podtelez>![]() |
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?
|
Dave Arnold <darnold>![]() |
Tue 27 May 2014 11:55:06 PM UTC, comment #1: I wrote to Stuart in private recently:
|
Behdad Esfahbod <behdad> |
Tue 27 May 2014 11:13:18 PM UTC, original submission:
|
Dave Arnold <darnold>![]() |
Depends on the following items: None found
Items that depend on this one: None found
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 | Status | Confirmed | ![]() |
Postponed |
2014-10-18 | wl | Item Group | None | ![]() |
Wishlist |
comment #11:
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.