Open
Bug 721531
Opened 12 years ago
Updated 2 years ago
text width occasionally decreases when font size increases (hinting or interaction of kerning with pixel-rounded glyph widths)
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
UNCONFIRMED
People
(Reporter: kdevel, Unassigned)
Details
Attachments
(1 file)
2.98 KB,
text/html
|
Details |
User Agent: Steps to reproduce: 1. Open Testcase, press OK! (with Font "Arial"). Actual results: 1. Some lines have smaller text widths than the preceeeding one (red values). Expected results: 1. Text width increases monotonically with increasing font size.
Summary: text width occassionally decreases when font size increases (hafbuzz, TrueType, kerning) → text width occassionally decreases when font size increases (harfbuzz, TrueType, kerning)
Attachment #591946 -
Attachment mime type: text/plain → text/html
Updated•12 years ago
|
Component: Untriaged → Layout: Text
Product: Firefox → Core
QA Contact: untriaged → layout.fonts-and-text
Comment 3•12 years ago
|
||
Updating summary: this is not specific to harfbuzz, it also occurs with the older Pango text path, as can be confirmed by setting gfx.font_rendering.harfbuzz.scripts to zero. (Also note that the issue has existed since Fx 3.0, according to comment 2, and harfbuzz was not even present then.) I'm not sure if this should be considered a bug, or just a peculiarity of font scaling behavior.... what's happening is that glyph widths are being rounded to device pixels (to ensure consistent spacing/rendering), and so the Arial glyphs at (for example) 30.4pt and 30.5pt (which equate to 40.5333px and 40.66667px) end up with the exact same advance widths. However, certain kern values such as between "T" and "a" happen to work out one pixel more (tighter) at the larger scale - the "Ta" kern in Arial is -227 units in a 2048-unit em-square, which at these two font sizes comes to -4.4927px and -4.5075px respectively. So once pixel alignment of the final glyph positions is considered, at 30.4pt, we end up kerning the "Ta" by -4px, while at 30.5pt, we kern it by 5px.
Summary: text width occassionally decreases when font size increases (harfbuzz, TrueType, kerning) → text width occasionally decreases when font size increases (interaction of kerning with pixel-rounded glyph widths)
Comment 4•12 years ago
|
||
Yes, the advances we get are hinted advances from FreeType which are already aligned to pixels, which makes it difficult to integrate the rounding of advances and offsets. (If we don't use the hinted advances, I assume well get other problems from glyphs changing size with the hinting of stems.) However, even without kerning similar issues still exist. These are the numbers I'm seeing from harfbuzz for the 4 glyphs in the word PIPA at two different sizes: 7.2pt $26 = {{ x_advance = 0x70000, x_offset = 0x0, }, { x_advance = 0x30000, x_offset = 0x0, }, { x_advance = 0x6a100, x_offset = 0x0, }, { x_advance = 0x6a100, x_offset = 0xffffa100, }} 7.9pt $39 = {{ x_advance = 0x60000, x_offset = 0x0, }, { x_advance = 0x20000, x_offset = 0x0, }, { x_advance = 0x59780, x_offset = 0x0, }, { x_advance = 0x79780, x_offset = 0xffff9780, }} Note how advances for the first two glyphs (for 'P' and 'I') are both 1 pixel smaller at 7.9pt than at 7.2pt, and there is no kerning involved between those glyphs. This suggests that a size reduction is coming from the hinting instructions, or from the way FreeType provides its hinted metrics. Might be interesting to check GDI rendering to see whether the hinting has the same effect there.
Summary: text width occasionally decreases when font size increases (interaction of kerning with pixel-rounded glyph widths) → text width occasionally decreases when font size increases (hinting or interaction of kerning with pixel-rounded glyph widths)
Not affected seem more recent revisions, e.g. the current bbc7014db2de. Is this due to "AzureBackend skia"?
Correction to Comment 5: testcase testcase FT2 Version Arial Verdana DejaVu Sans Bug 717149 Bug 722105 2.3.7-11.1* bad bad bad good bad 2.4.5 bad bad bad good bad 2.4.7 good good bad bad bad 2.4.8 good good bad bad bad * OpenSUSE Evergreen 11.1 freetype2-2.3.7-24.8.1
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•