1716435 - getBBox() on <text> element: width shrinks as font-size increases

Status: UNCONFIRMED

(Core :: SVG, defect, P4)

Description

[Sam Ettinger]

Attachment: A demo that graphs getBBox().width values with respect to font-size

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

Enter the following in Web Developer Tools Console, Firefox 89.0 (64-bit) on a Windows 10 PC:

document.documentElement.lang = "en";
const svg = document.createElementNS("http://www.w3.org/2000/svg", "svg");
svg.setAttribute("style", "font-family: monospace");
document.body.prepend(svg);
for (let i=1; i<20; i++) {
const txt = document.createElementNS("http://www.w3.org/2000/svg", "text");
txt.textContent = "M";
svg.appendChild(txt);
txt.setAttribute("font-size", i);
txt.setAttribute("x", 50);
txt.setAttribute("y", 50);
console.log("Glyph width is", txt.getBBox().width, "at font size", i);
}
svg.remove();

Actual results:

For any single monospace or sans-serif character that I tested, getBBox().width is appreciably larger at size 15px than it is at size 16px. In fact, getBBox().width for a 15px glyph is larger than 16px, 17px, 18px, 19px, or 20px glyphs.

Expected results:

getBBox.width() should return a value that scales approximately linearly with font-size, regardless of font-family value.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::SVG' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Sam Ettinger]

My apologies if this bug report is deficient in any way. This is my first submission.

I have prepared a CodePen that can help illustrate the issue: https://codepen.io/settinger/pen/mdWQjvL?editors=0010

When applied to a single character within an SVG <text> element, getBBox().width is expected to increase roughly linearly with respect to font-size. This is true in most cases on most browsers that I have tried. However, in Firefox on Windows 10, when font-family is set to monospace or sans-serif, the BBox width shrinks at font-size 16. In my case, at font-size 15, a monospace glyph had width 12, but at font-size 16, the same glyph had width 9.600000381469727. By comparison, in Chrome 91.0 on the same Windows machine, both glyphs are reported as width 9.

Incidentally, I have noticed that this also depends on the ISO-639-1 language code of the page that renders the SVG. Languages where monospace font width never decreases are: bo (Tibetan), dz (Dzongkha), hi (Hindi), ja (Japanese), mr (Marathi), ne (Nepali), sa (Sanskrit), zh-* (Chinese).

When font-family is set to sans-serif, practically all the languages have a width shrinkage between 10px and 11px and between 15px and 16px. The only languages that don't are the ones listed above. Again, the BBox() width never decreases on Chrome or Firefox Mobile.

Incidentally, when font-family is set to monospace, some languages still render a sans-serif font. Other browsers do not appear to have this behavior. The languages are: am (Amharic), as (Assamese), bn (Bengali), gu (Gujarati), hy (Armenian), iu (Inuktitut), ka (Georgian), km (Khmer), kn (Kannada), ko (Korean), ml (Malayalam), or (Oriya), pa (Punjabi), si (Sinhala), ta (Tamil), te (Telugu), ti (Tigrinya).

Comment 3

[Emilio Cobos Álvarez [:emilio]]

That's great, thanks! Fwiw, monospace is a special font-family in the sense that font-size: medium behaves like font-size: 13px rather than 16px, but not sure if that's at play here yet... On Linux the behavior is as expected, fwiw.

Comment 4

[Jonathan Kew [:jfkthame]]

What you're seeing here is the result of Firefox switching between different Windows font-rendering modes depending on the font size, for certain "legacy" font families on Windows that were specifically optimized for older display systems.

Look in about:config for the two settings with force_gdi_classic in their names; there's a list of specific font families that it will affect, and a size threshold where we switch from the "GDI Classic" rendering (which tends to make the glyphs wider at very small sizes) to the default DirectWrite rendering mode.

If you set that size threshold to zero, the graph will look a lot more like you'd expect.

So I don't think this is really a bug, it's more of a quirk that arises from a setting that was deliberately chosen to mitigate the disruption when we began migrating from the old GDI rendering to DirectWrite, and users were unhappy with how the old GDI-optimized fonts appeared.

Maybe by now the world has moved on sufficiently that we could reconsider this behavior (although touching font rasterization in any way does tend to arouse strong opinions among users!)

Comment 5

[Jonathan Watt [:jwatt]]

jfkthame: should we use this bug if we're going to reconsider the behavior, or open a more generic bug?

Comment 6

[Jonathan Kew [:jfkthame]]

I think it should be a separate bug (specifically about the choice of Windows font rendering modes). The impact on measurement seen here is basically a side-effect of that.