Open
Bug 1126704
Opened 10 years ago
Updated 2 years ago
local font clipped at certain sizes while webfont is not
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
REOPENED
People
(Reporter: peter, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150125221831
Steps to reproduce:
This is my first bug report here; apologies if I'm messing this up.
Starting with FF35, we've had reports of unexpected clipping of glyphs with a couple of fonts (MathJax, STIX General) at certain font sizes / zoom levels.
The clipping only occurs with locally installed fonts while webfonts work as expected.
It seems to happen at font-sizes around 10-14pt, i.e., zooming in or out works around the problem (and also triggers it).
Here's a minimal example: http://jsbin.com/foboca/2/edit?html,output (you need to install the font locally to see the clipping).
Actual results:
In the example, the second integral sign is clipped at the top right.
Expected results:
Identical rendering using local fonts and webfonts.
![]() |
||
Comment 1•10 years ago
|
||
Thanks for the report. Is it still reproducible? Does it depend on whether hardware acceleration (Preferences → Advanced → General) or hinting or sub-pixel stuff is enabled?
Flags: needinfo?(peter.krautzberger)
Comment 2•9 years ago
|
||
Due to the lack of response from the reporter I will change the status of this bug to Resolved:Incomplete.
Reporter, fell free to reopen it if you still reproduce the issue and you are willing to provide the needed info.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Reporter | ||
Comment 3•9 years ago
|
||
@Aleksei Sorry for missing the original response! @Liviu thanks for following up.
> Is it still reproducible?
Yes, I can still reproduce this on FF 43.0, Ubuntu 15.10.
> Does it depend on whether hardware acceleration
No.
> or hinting or sub-pixel stuff is enabled?
I'm not sure how to test that. On the system level? I tried something similar to [1] (switching off hinting and aliasing) but that did not fix the observed bug.
Since the bug used to come and go (but has been "stable"/broken for a while now), I'm guessing it's not due to any OS setting. But happy to try something else you can suggest.
Thanks again for looking into this.
[1] http://superuser.com/questions/606561/firefox-subpixel-rendering-on-ubuntu
Flags: needinfo?(peter.krautzberger)
Comment 4•9 years ago
|
||
Thanks for the info. Reopening this bug.
Status: RESOLVED → REOPENED
Component: Untriaged → Layout: Text
Ever confirmed: true
Product: Firefox → Core
Resolution: INCOMPLETE → ---
Reporter | ||
Comment 5•9 years ago
|
||
Thanks, Liviu.
Comment 6•9 years ago
|
||
If you add the property
text-rendering: optimizeLegibility;
to your example (e.g. in the style of <body> or <span>), does that avoid the problem?
Reporter | ||
Comment 7•9 years ago
|
||
@Jonathan: thanks for looking into it. Yes, adding optimizeLegibility seems to avoid the problem.
Comment 8•9 years ago
|
||
OK, that confirms my guess as to what you're seeing. Basically, some of the time we use an optimization in text handling whereby we don't measure the true bounding box of the glyphs (to determine the area of the screen that needs to be painted), but instead just use the typographic advance width of the string, and the ascent/descent of the font. This avoids the additional cost of looking up each glyph's bounding box and keeping track of the union of all those boxes.
In general, that works fine; it often means we paint a slightly larger area than strictly necessary, because glyphs don't usually reach all the way to the font's ascent/descent, but that's cheaper than actually processing the bounding boxes.
However, when the last glyph in a text run projects to the right of its advance width (as is the case with that integral sign), it may lead to some undesired clipping because we don't account for that projecting tip. (A similar issue can occur on the left side if a glyph projects to the left of its origin, as the italic 'f' does in some fonts.)
So this is a problem of the "fast path" for text rendering. There are several cases where we avoid that "fast path" and use the "quality path" instead, and you don't see the problem:
a) above a certain size threshold (the browser.display.auto_quality_min_font_size preference), because such glitches become more noticeable at larger sizes, and the extra cost will only be paid for a relatively small minority of text content;
b) if you explicitly request the quality path with text-rendering:optimizeLegibility;
c) when using webfonts, where we assume the designer/author is more concerned about getting exactly the text rendering they wanted.
Obviously, (a) is why you see this being affected by font size/zoom, (b) is what you just confirmed, and (c) is why it doesn't affect the webfont in your example.
So to sum up, this is working as designed, and you happen to have noticed an unfortunate limitation of the design. You could work around it in pages you control by setting the text-rendering property; and/or you can work around it locally for your browser by setting browser.display.auto_quality_min_font_size to a lower value (I think zero should work).
The question that remains, then, is whether we could improve the default/automatic behavior. Perhaps we could afford to use the "quality path" for all text; but we'd need to check what the performance and memory impact would be. Or perhaps we could detect when fonts have such "overhanging glyphs" (without actually getting all the glyph bounds!) and force the quality path only for them. Or maybe we could find a better heuristic for the "loose bounding box" that avoids examining each glyph's true bounds.
Reporter | ||
Comment 9•9 years ago
|
||
Thank you for the background information on this, Jonathan! It sounds like optimizeLegibility is the way to go to ensure the rendering is ok for all users.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•