1738564 - dominant-baseline middle is inconsistent at small font-sizes, probably due to nscoord precision

Status: NEW

(Core :: SVG, defect)

Description

[Sam Dinner]

Attachment: An example HTML file demonstrating the bug.

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

I set dominant-baseline to "middle" on a SVG <text> element. Then I copied the <svg> element and scaled all the dimensions by factors of 10 so that each <svg> should render the same thing just with a different size.

Actual results:

I expected the same SVG every time since everything was scaled consistently.

Expected results:

Each scale aligns the text in a different place.

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 Dinner]

Attachment: Screenshot of test.html

A screenshot of what test.html looks like on Ubuntu 21.10.

Comment 3

[Sam Dinner]

I tried testing this on Windows and noticed the issue was still there but the offset was more subtle. I also experienced the issue on Nightly (20211030103646).

Comment 4

[Robert Longson [:longsonr]]

Only the really tiny font doesn't work on my Mac. The other 3 are OK.

Comment 5

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

The severity field is not set for this bug.
:boris, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[Boris Chiou [:boris]]

Attachment: Screen_shot_mac_Nightly

This is my screenshot. The 0-0.01 and 0-0.1 are different.

Comment 7

[Daniel Holbert [:dholbert]]

This is particularly a problem for small font-sizes, I think -- updating the bug title to mention that. I'll attach a testcase I came up with while investigating a case of this at bug 1918604, too.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (top half has `dominant-baseline:middle`)

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: reference case 2

Here's a reference case for testcase 2, where I've just scaled up all of the sizes inside the SVG content by 10 (which shouldn't actually impact the rendering, since the SVG content is still squished into the same size container).

The expectation is that testcase 2 should exactly match this reference case. But in Firefox, the first "E" is lower down in testcase 2 as compared to this reference case.

(This offset gets even worse if you zoom out with Ctrl -, too. Depending on your screen resolution, you might have to do that in order to see this bug in the first place.)

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 2 (left) vs reference case 2 (right) on Nightly

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 2 (left) vs reference case 2 (right) on Nightly with 50% full-page-zoom

(This offset gets even worse if you zoom out with Ctrl -, too. Depending on your screen resolution, you might have to do that in order to see this bug in the first place.)

Here's a screenshot to demonstrate this^. In the top left of this screenshot (showing the top half of testcase 2, viewed at 50% full-page-zoom), the "E" is protruding quite a ways outside of the orange area.

Comment 12

[Robert Longson [:longsonr]]

I think because we're working with the nscoord type so small values are simply rounded to 0.

nsIFrame::GetLogicalBaseline returns nscoord
nsfontMetrics->XHeight() returns nscoord (https://searchfox.org/mozilla-central/source/gfx/src/nsFontMetrics.cpp#179)

So you simply lose precision with small values.

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to Robert Longson [:longsonr] from comment #12)

I think because we're working with the nscoord type so small values are simply rounded to 0.

That makes sense, yup.

nscoord units really aren't well-suited to this scenario where things have been scaled up by this much... They're fractions of a CSS pixel and are implicitly meant to be fractions-of-the-smallest-distance-a-user-can-perceive, but in cases where the scale-factor is such that they end up being larger than (or around the same magnitude as) a display pixel, things break down like this.

I wonder if we could hack around this in some cases (at least for viewBox scales) by adding another internal scale factor of some sort, so that we could be working with units that are in the right ballpark in terms of sub-pixel positioning... That wouldn't be especially robust in the face of scales from per-element transform-scales, but maybe it'd still be worth exploring for this viewBox-scaling scenario at least.