The FreeType Project - Bugs: bug #58352, B/W hinting differences of...
You are not allowed to post comments on this tracker with your current authentication level.
bug #58352: B/W hinting differences of "a" and "z" in Tahoma if compared to Windows
Submitter: | None | ||
Submitted: | Mon 11 May 2020 04:04:09 PM UTC | ||
Severity: | 3 - Normal | Item Group: | Incorrect behaviour |
Status: | Fixed | Privacy: | Public |
Assigned to: | wl | Open/Closed: | Closed |
Planned Release: | 2.10.3 |
Jump to the original submission
Wed 02 Dec 2020 02:41:15 AM UTC, comment #40: |
Alexei Podtelezhnikov <podtelez> |
Tue 01 Dec 2020 08:13:56 PM UTC, comment #39: Your patch is not the actual rendering method that is used, and therefore risks causing regressions elsewhere. Type Design did not bother to attempt reproducing your patch because it is meaningless with respect to getting every single case right. However, with the correct method, the correct rendering of a at 16ppem was reproducible in the development of TD renderer. |
Anonymous |
Tue 01 Dec 2020 07:00:07 PM UTC, comment #38: It is certainly possible to explore corner cases with synthetic fonts, but the cost-benefit is minuscule if any. It is just not useful. Do you really think that somebody uses opposite conttour orientation intentionally? They probably might in Andromeda galaxy, our universe is large, of course. For the real *world*, we fixed Tahoma a and p, which indeed counts a progress. (It is only now you begin to combine rounding and averaging in one expression, which is a good too). We analyzed Tahoma z and realized that FreeType's solution is more accurate.
|
Alexei Podtelezhnikov <podtelez> |
Tue 01 Dec 2020 04:13:49 PM UTC, comment #37: Note that this subdivider formula is ONLY for finding the fractional edges. The integer edges, as necessary for determining whether dropout control exists and for finding where filled pixels start and end, are done with a completely separate and completely different formula that uses integer computation to trace edges through the spline. |
Anonymous |
Tue 01 Dec 2020 04:11:11 PM UTC, comment #36: Round half down average formula for midpoint: (1+a+(2*b)+c)>>2
|
Anonymous |
Tue 01 Dec 2020 04:08:44 PM UTC, comment #35: To clarify when doing smart dropout control to find the fractional position within a horizontal scanline, you round half down if the start point is lower than the end point, half up if the start point is higher than the end point, in both dimensions.
|
Anonymous |
Mon 30 Nov 2020 09:06:29 PM UTC, comment #34: Found the actual smart dropout control used in TrueType rendering!
|
Anonymous |
Sat 21 Nov 2020 08:20:50 PM UTC, comment #33:
|
Anonymous |
Mon 28 Sep 2020 08:56:47 AM UTC, comment #32:
|
Anonymous |
Mon 28 Sep 2020 06:56:22 AM UTC, comment #31: Thanks for the documentation of your algorithm.
|
Werner LEMBERG <wl> |
Sun 27 Sep 2020 12:31:49 PM UTC, comment #30: To keep track of the best known method for dropout control see https://pixelbuilding.createaforum.com/quadratic-pixel-building/dropout-control/ |
Anonymous |
Sun 27 Sep 2020 12:27:58 PM UTC, comment #29:
|
Anonymous |
Sun 27 Sep 2020 07:10:50 AM UTC, comment #28: It's an unfortunate fact of life that the specification is not sufficient: there are so many corner cases not discussed. For the sake of the zillion fonts that have been created with VOLT and other MS tools it is mandatory to imitate MS rendering.
|
Werner LEMBERG <wl> |
Sun 27 Sep 2020 05:47:28 AM UTC, comment #27:
|
Anonymous |
Sat 26 Sep 2020 06:01:54 PM UTC, comment #26: This is certainly not MS code. Neither Alexei nor I have access to that. |
Werner LEMBERG <wl> |
Sat 26 Sep 2020 05:57:59 PM UTC, comment #25:
|
Anonymous |
Sun 13 Sep 2020 06:14:08 PM UTC, comment #24: A fix is committed. |
Alexei Podtelezhnikov <podtelez> |
Fri 11 Sep 2020 06:29:02 AM UTC, comment #23: Yes, I think we should apply it.
|
Werner LEMBERG <wl> |
Wed 09 Sep 2020 03:18:20 AM UTC, comment #22: To reproduce smart dropouts a la GDI, first we need to floor the profile coordinates to 26.6 and then apply smart dropout rounding. Then the increased resolution would not change dropout control outcome, which probably makes sense.
|
Alexei Podtelezhnikov <podtelez> |
Tue 08 Sep 2020 03:36:25 AM UTC, comment #21: Below are the traces of FreeType correctly calculating the smart dropout pixel.
|
Alexei Podtelezhnikov <podtelez> |
Sat 05 Sep 2020 01:59:22 AM UTC, comment #20: Thanks! I am under impression that most of the reported glitches are related to curves passing close by. So I wanted to rule hinting out before testing the next hypothesis: flattening the curve is too aggressive and still grabs the pixel on the concave side. I cannot imagine that the dropout rule is not followed and the right pixel has preference over the left one.
|
Alexei Podtelezhnikov <podtelez> |
Fri 04 Sep 2020 08:41:20 PM UTC, comment #19: The problem with glyph 'a' is definitely not hinting, as the image shows: similar to FreeType, both pixel centers are outside of the contour.
|
Werner LEMBERG <wl> |
Fri 04 Sep 2020 03:49:41 PM UTC, comment #18: Then we are back to MDRP, where FreeType does better job than GDI in preserving parallel lines 2--3 and 7--8. Therefore, reverse engineering GDI flaws is the only dubious choice. I am no longer interested in Tahoma-15ppem-z.
|
Alexei Podtelezhnikov <podtelez> |
Fri 04 Sep 2020 04:27:57 AM UTC, comment #17: Nope, it's not. VTT reports the following coordinates at 15px for B/W hinting:
|
Werner LEMBERG <wl> |
Fri 04 Sep 2020 03:09:51 AM UTC, comment #16: I think I solved tahoma-15ppem-z. It is the vertical interpolation of point 2 between points 1 and 8 that makes the difference:
|
Alexei Podtelezhnikov <podtelez> |
Thu 03 Sep 2020 09:36:57 PM UTC, comment #15: In Tahoma-15ppem-z, the sequence of SDPVTL, RDTG, MDRP keeps the lines 2--3 and 7--8 parallel. FreeType finds the best solution for its current point positions. I would need the entire outline generated by Windows to investigate further. |
Alexei Podtelezhnikov <podtelez> |
Mon 31 Aug 2020 01:17:10 PM UTC, comment #14: This proof-of-concept fix demonstrates that Tahoma-15ppem-z likely glitches in MDRP.
|
Alexei Podtelezhnikov <podtelez> |
Fri 22 May 2020 06:53:39 AM UTC, comment #13: FreeType 2.10.2 is indeed extremely glitchy. A renderer with a competing rasterizer is TD renderer 2.0, but it's extremely glitchy too. That's why it is extremely important to research the Microsoft bilevel renderer (all other Microsoft renderers are based on the bilevel renderer). |
- <_194785> |
Thu 21 May 2020 11:53:11 AM UTC, comment #12: 1)
|
Tim <bapinta> |
Thu 21 May 2020 11:52:06 AM UTC, comment #11: 1)
|
Tim <bapinta> |
Thu 21 May 2020 10:35:22 AM UTC, comment #10: So,
|
- <_194785> |
Wed 20 May 2020 08:29:25 PM UTC, comment #9: I have added another example:
|
Tim <bapinta> |
Wed 20 May 2020 08:28:12 PM UTC, comment #8: I have added another example:
|
Tim <bapinta> |
Wed 20 May 2020 10:18:34 AM UTC, comment #7:
|
- <_194785> |
Sun 17 May 2020 01:51:24 PM UTC, comment #6: I have added some more examples (see attachment):
|
Tim <bapinta> |
Sat 16 May 2020 07:37:49 PM UTC, comment #5:
|
- <_194785> |
Fri 15 May 2020 12:24:49 PM UTC, comment #4: I completely agree that z at 15ppem might be a bytecode issue: the point 3 is adjusted but not snapped to the grid. We might ask Werner to look at the bytecode if the point 3 can be "fixed". On the other hand, the pixel is so close to the outline that the rounding error might be in the profile calculation. |
Alexei Podtelezhnikov <podtelez> |
Fri 15 May 2020 12:17:07 PM UTC, comment #3: Dropout control direction:
|
- <_194785> |
Fri 15 May 2020 11:29:49 AM UTC, comment #2: This is really two separate issues: the "a" in 16ppem and the "z" in 15ppem.
|
- <_194785> |
Mon 11 May 2020 08:40:01 PM UTC, comment #1: ftgrid from ft2demos demonstrates 2 incredibly close calls
|
Alexei Podtelezhnikov <podtelez> |
Mon 11 May 2020 04:04:09 PM UTC, original submission:
When anti-aliasing is deactivated, then "a" and "z" of the font Tahoma are not hinted like they are in Windows.
|
Anonymous |
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 12 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2020-12-01 | podtelez | Status | Ready For Test | Fixed | |
Open/Closed | Open | Closed | |||
2020-09-13 | podtelez | Status | Confirmed | Ready For Test | |
Planned Release | None | 2.10.3 | |||
2020-09-04 | wl | Attached File | - | Added tahoma-a-15px-VTT.png, #49742 | |
2020-05-21 | bapinta | Attached File | - | Added bad_C_and_G.png, #49137 | |
2020-05-20 | bapinta | Attached File | - | Added bad_hinted_big_P.png, #49135 | |
2020-05-17 | bapinta | Attached File | - | Added Bad@hinted@Y,@g@Win-Lin@Tahoma.png, #49104 | |
2020-05-11 | wl | Status | None | Confirmed | |
Assigned to | None | wl | |||
Summary | When anti-aliasing is deactivated, then "a" and "z" of the font Tahoma are not hinted like they are in Windows. | B/W hinting differences of "a" and "z" in Tahoma if compared to Windows | |||
2020-05-11 | None | Attached File | - | Added a@and@z@Win7@and@Linux@comparison.png, #49058 |
Powered by Savane 3.13-02a9.
Corresponding source code
About 1/64 of curvy dropouts would have this ambiguity. Therefore, it should not be too hard to notice any regression. So far we did not see any, nor did we receive any bug reports.
This is such old technology to obsess about. The dropouts were cool 25 years ago. Do you realize how little it matters now with dramatically increased screen resolutions? Do you realize that Windows is certainly not the most dominant OS counting all screens in use? The role of dropouts with oversampling is even smaller. Do you realize that you basically work on TD for your own amusement? This is fine, of course, when you are young.