D2Coding 1.3.3 Regular renders three related glyphs one pixel above the baseline with native FreeType hinting at exactly 18 ppem:
| Glyph |
Code point |
Bitmap bottom at 16-20 ppem |
i |
U+0069 |
0, 0, 1, 0, 0 |
uni0456 |
U+0456 |
0, 0, 1, 0, 0 |
uni045D |
U+045D |
0, 0, 1, 0, 0 |
This looks like a remaining part of #70. That issue reported the same visible problem with i at 18 pt, and the 1.3.2 release notes say it was fixed. The 1.3.2 update added some instructions to Regular i, but its lower stem still has matching -1 px DELTAP corrections at 19 and 20 ppem with no correction at 18 ppem. The equivalent Cyrillic glyph programs were unchanged.
The missing corrections are:
i: points 2 and 5uni0456: points 2 and 5uni045D: points 9 and 16
For each point, the existing packed values encode the same -1 px correction at 19 and 20 ppem. Adding the corresponding value for 18 ppem keeps the glyph on the shared baseline.
I tested that change against both Regular TTFs. The three isolated baseline lifts dropped to zero, and only the affected glyph programs changed. Bold already renders these three glyphs on the baseline at 16-20 ppem.
The static scan finds many DELTAP gaps that do not cause a raster defect, so I only treated a glyph as affected when the missing delta coincided with an isolated 18 ppem lift. In Regular, that reduced 359 static candidates to these 3 raster-confirmed cases.
Test environment:
- FreeType 2.13.2 with native grayscale hinting
- D2Coding 1.3.3 Regular SHA-256
fdd2b06844f9e936390d5c8e47355156954098d41debf1b191a9bfbf272836d0
I can send a PR that updates the three Regular UFO instruction sources, both shipped Regular TTFs, and adds a 16-20 ppem raster regression check for all four builds.
Before
After
D2Coding 1.3.3 Regular renders three related glyphs one pixel above the baseline with native FreeType hinting at exactly 18 ppem:
i0, 0, 1, 0, 0uni04560, 0, 1, 0, 0uni045D0, 0, 1, 0, 0This looks like a remaining part of #70. That issue reported the same visible problem with
iat 18 pt, and the 1.3.2 release notes say it was fixed. The 1.3.2 update added some instructions to Regulari, but its lower stem still has matching-1 pxDELTAP corrections at 19 and 20 ppem with no correction at 18 ppem. The equivalent Cyrillic glyph programs were unchanged.The missing corrections are:
i: points 2 and 5uni0456: points 2 and 5uni045D: points 9 and 16For each point, the existing packed values encode the same
-1 pxcorrection at 19 and 20 ppem. Adding the corresponding value for 18 ppem keeps the glyph on the shared baseline.I tested that change against both Regular TTFs. The three isolated baseline lifts dropped to zero, and only the affected glyph programs changed. Bold already renders these three glyphs on the baseline at 16-20 ppem.
The static scan finds many DELTAP gaps that do not cause a raster defect, so I only treated a glyph as affected when the missing delta coincided with an isolated 18 ppem lift. In Regular, that reduced 359 static candidates to these 3 raster-confirmed cases.
Test environment:
fdd2b06844f9e936390d5c8e47355156954098d41debf1b191a9bfbf272836d0I can send a PR that updates the three Regular UFO instruction sources, both shipped Regular TTFs, and adds a 16-20 ppem raster regression check for all four builds.
Before
After
