Open
Bug 1139008
Opened 8 years ago
Updated 6 months ago
Text rendering does not follow font metrics
Categories
(Core :: Graphics: Text, defect)
Tracking
()
UNCONFIRMED
People
(Reporter: mihai.bazon, Unassigned)
Details
(Whiteboard: [gfx-noted])
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20150125222008 Steps to reproduce: Compared to other browsers, Firefox appears to draw text narrower, for the same font and size. Can be seen at: http://lisperator.net/s/ff/text-narrow/index.html The example loads a TrueType font (DejaVu Sans Mono) and renders some text in it. When you click the "Test" button, it'll walk the element and draw a border around each text node, as well as dumping to the console the width of each rectangle. If you try the same example in other browsers, the widths of the rectangles will be significantly larger (and consistent across browsers--I tried Chrome, IE10 and IE11). Actual results: Although the rectangles fall perfectly into place, if you try "print preview" you can see the actual issue: in Firefox, they are smaller than the text. I'm arguing that the actual bug is in the page rendering, rather than in print, because all other browsers consistently report larger numbers. Expected results: Text should be displayed in its actual size on page—just as it is displayed in "print preview".
Reporter | ||
Comment 1•8 years ago
|
||
Could be a Linux-only issue. Seems numbers are consistent with other browsers when running on Windows / OSX.
Updated•8 years ago
|
Component: Untriaged → Graphics: Text
Product: Firefox → Core
Reporter | ||
Comment 2•8 years ago
|
||
I attribute the issue to font hinting. The text as rendered by the browser is a bit narrower (but sometimes wider) than it would be when rendered at the natural glyph size (as defined in the font file). I'm not sure this can be called a bug (there's definitely a bug to be seen in print preview though) — but it completely messes up my plans. :-( I'm using the layout information given by getBoundingClientRect to generate PDF. The same issue occurs in Chrome on Windows too, but it can't be seen in print preview. I examined a PDF generated by Chrome and found that it works around the issue in a "smart" (awful, really) way: 1 0 0 -1 190 72 Tm <0025> Tj 1 0 0 -1 204 72 Tm <002F> Tj 1 0 0 -1 218 72 Tm <0024> Tj etc. every piece of text is rendered a single char at a time, by adjusting the text matrix, to avoid using the font's official metrics. Gets the problem solved and I could do the same from JS, but with a 10x speed penalty. What would be nice instead would be to have a way to disable font hinting (say via CSS) and retrieve layout information that's correct with regards to the font metrics.
Updated•8 years ago
|
Whiteboard: [gfx-noted]
Updated•6 months ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•