ScaledFontDWrite mishandles the 'gasp' table ranges
Categories
(Core :: Graphics: Text, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox102 | --- | fixed |
People
(Reporter: jfkthame, Assigned: jfkthame)
Details
Attachments
(1 file)
Noticed this while experimenting with bug 1770132: when Arial is rendered at 8ppem (i.e. 8px on a display with 100% scaling; correspondingly smaller px sizes on higher-res displays), it looks terrible because we render the glyphs without antialiasing, but their hinting doesn't actually kick in effectively until 9ppem.
This happens because we misinterpret the 'gasp' table ranges: a range should apply at ppem sizes up to and including its maxPPEM field.
|
Assignee | |
Comment 1•2 years ago
|
||
|
||
Updated•2 years ago
|
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/88d31f6c458d Make OpenType 'gasp' table ranges apply up to their maxPPEM size, inclusively. r=lsalzman
|
||
Comment 3•2 years ago
|
||
| bugherder | ||
This appears to have caused a regression with some font.
Example:
https://www.trademe.co.nz/a/marketplace/computers/laptops/laptops/other/listing/3622992918
|
|
Assignee | |
Comment 5•2 years ago
|
||
The "Story Sans" font that site is using has a gasp table:
<gasp>
<gaspRange rangeMaxPPEM="8" rangeGaspBehavior="10"/>
<gaspRange rangeMaxPPEM="16" rangeGaspBehavior="5"/>
<gaspRange rangeMaxPPEM="65535" rangeGaspBehavior="15"/>
</gasp>
At sizes above 8ppem and up to 16ppem (which is what the site is using if viewed on a low-res display with 100% scaling), it requests behavior 5, which according to the definitions at https://docs.microsoft.com/en-gb/typography/opentype/spec/gasp is a request for grid-fitting but no smoothing.
So it may not be pretty, but this is what the font asks for.
Description
•