Open Bug 1139008 Opened 10 years ago Updated 2 years ago

Text rendering does not follow font metrics


(Core :: Graphics: Text, defect)

35 Branch





(Reporter: mihai.bazon, Unassigned)


(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:

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".
Could be a Linux-only issue.  Seems numbers are consistent with other browsers when running on Windows / OSX.
Component: Untriaged → Graphics: Text
Product: Firefox → Core
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

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.
Whiteboard: [gfx-noted]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.