1953642 - info.svg "circled-i" favicon has its content off-center (biased leftwards, leaving rightmost column of pixels mostly blank)

Status: NEW

(Toolkit :: Themes, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 - comparing current icon (top) vs. old icon (bottom), scaled up 20x to make detail easier to see

The current (i) info.svg favicon that we got in bug 1699889 has a bit of a problem -- its content isn't nicely centered in its viewBox.

This causes visible trouble as shown in bug 1834939, where it makes the notification-dot look off center (but really the notification dot is centered, and it's the favicon's graphics that are off-center).

See attached testcase, which has:

• the current contents of info.svg at the top, scaled up 20x and wrapped in a red border.
• the previous contents of info.svg at the bottom, scaled up 20x and wrapped in a green border.

If you look carefully at the two icons and compare their left/right sides, you can see that the current icon (bordered in red) is off-center -- it has much more space on the right edge than on the left edge; whereas the previous icon (bordered in green) looks balanced.

Comment 1

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

Set release status flags based on info from the regressing bug 1699889

:mconley, since you are the author of the regressor, bug 1699889, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Daniel Holbert [:dholbert]]

This might actually affect all of the 16x16 icons that were landed in that patch... :-/

Spot-checking a few others:
https://searchfox.org/mozilla-central/source/toolkit/themes/shared/icons/warning.svg
https://searchfox.org/mozilla-central/source/toolkit/themes/shared/icons/update-icon.svg
... I'm seeing the same issue, where their drawing is centered as if they were 15px wide, when in fact they're 16px wide (so the rightmost pixel is mostly empty, and their content appears off-center).

Comment 3

[Daniel Holbert [:dholbert]]

These ones have the same problem as the ones that I listed above (their content is biased to the left, as if they were a 15px-wide-icon, ignoring the rightmost pixel for centering/filling purposes):
https://searchfox.org/mozilla-central/source/toolkit/themes/shared/icons/error.svg
https://searchfox.org/mozilla-central/source/toolkit/themes/shared/icons/help.svg
https://searchfox.org/mozilla-central/source/toolkit/themes/shared/icons/info-filled.svg
https://searchfox.org/mozilla-central/source/toolkit/themes/shared/icons/newsfeed.svg
https://searchfox.org/mozilla-central/source/toolkit/themes/shared/icons/plus.svg
https://searchfox.org/mozilla-central/source/toolkit/themes/shared/icons/security-warning.svg

I also found some with the the opposite problem, where the drawing is snapped to the right and leaves the leftmost column of pixels blank:
https://searchfox.org/mozilla-central/source/toolkit/themes/shared/icons/blocked.svg
https://searchfox.org/mozilla-central/source/toolkit/themes/shared/icons/folder.svg
https://searchfox.org/mozilla-central/source/toolkit/themes/shared/icons/defaultFavicon.svg
https://searchfox.org/mozilla-central/source/toolkit/themes/shared/icons/undo.svg

And this one's right-aligned and draws outside of its bounds, at least when viewed in inkscape (with fill="black" rather than `fill="context-fill"):
https://searchfox.org/mozilla-central/source/toolkit/themes/shared/icons/columnpicker.svg

And this one's top/left-aligned and leaves the bottom/right ~half-pixel blank (not as much dead space as the others)
https://searchfox.org/mozilla-central/source/toolkit/themes/shared/icons/experiments.svg

We also previously had an issue with highlights.svg, but fixed it in bug 1927897.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Hey jules, this feels design-systems-y, so I'm redirecting the needinfo. Do we need to regenerate these icons that dholbert has identified?

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 2: all the off-center icons identified as of comment 3 (requires about:config pref flip to be able to see them)

Here's a testcase that's directly showing all of these chrome:// icon URIs at 160x160x (i.e. scaled up 10x), with a red border and a small red circle to show their midpoint, to demonstrate that they're currently off-center.

As noted at the top of the testcase, this requires you to set about:config pref svg.context-properties.content.enabled so that you can see the icons (specifically so that the testcase's fill: black;-moz-context-properties: fill; can give each icon a fill-color).

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 2

Comment 7

[Daniel Holbert [:dholbert]]

(whoops, I mis-classified a few of the icons in testcase 2 / comment 3 -- it looks like blocked.svg and defaultfavicon.svg are actually biased to the bottom-right, not just rightwards. I'll repost for clarity.)

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: testcase 2: all the off-center icons identified as of comment 3 (requires about:config pref flip to be able to see them)

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 2

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: testcase 3: arrow icons

Here's a testcase with the various arrow icons, with/without the "-12" suffix. I'm not exactly sure about the intended alignment of these, but they do have some inconsistencies between them that might be worth looking into.

e.g. for chrome://global/skin/icons/arrow-right-12.svg (the first one here), the arrow's "elbow" is noticeably further outwards (rightwards) from the center-of-the-image (red dot) as compared to the other arrows that follow.

Comment 11

[Daniel Holbert [:dholbert]]

Of all the icons here, arguably the most important ones here with-respect-to this centering are the ones that are displayed with something centered alongside them -- particularly any that might be displayed as favicons with a notification-dot (per bug 1834939) in the tab-strip and/or in Firefox View.

So: hypothetically if regenerating/realigning all of these takes a lot of manual work and we want to pick a first few to prioritize, then those are the ones that I'd suggest.

Comment 12

[Sam Foster [:sfoster] (he/him)]

Just to re-state what might be obvious: those icons with a vertical stroke have a even-numbered grid problem. You simply cannot make a 1.25 wide line appear centered on a 12 or 16px grid without straddling 2 pixels and resulting in a blurry stroke. So we have to pick one column or the other, which necessarily biases left or right. We went through this at length in bug 1704274. Maybe we can at least make this consistent, but the trap here is that unless you are using a 1:1 devicePixelRatio on sub-par display hardware the obvious solution of centering the line looks fine. So we tend to be poorly equipped to assess the impact of a "fix" unless you take deliberate steps to evaluate using the environment on the bottom end of our user's bell curve of display hardware and configuration.

Some of the icons above do not feature a vertical stroke so maybe we can better center those. Or at least make them consistent so when they appear together they look aligned and evenly distributed.

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to Sam Foster [:sfoster] (he/him) from comment #12)

Just to re-state what might be obvious: those icons with a vertical stroke have a even-numbered grid problem. You simply cannot make a 1.25 wide line appear centered on a 12 or 16px grid without straddling 2 pixels and resulting in a blurry stroke. So we have to pick one column or the other, which necessarily biases left or right.

FWIW, for at least the (i) info.svg favicon this^ is not a problem that our current icons actually solve, at least in 100% pixel-scaling situations.

If you look at my screenshot attachment 9471571 [details] (from bug 1834939) and zoom in on the pixels in the "i" favicon (in the tab-strip or in the Firefox View listing), you can see that it's antialiased across two columns of pixels -- the left one a bit brighter than the right one. So we're not e.g. drawing that "i" as a single-pixel-wide stroke of pixels in a 15px-wide left-biased sub-region (as I think comment 12 might be suggesting we're trying to do).

But in any case, I agree that this makes an ideal-outcome a bit trickier to reason about here. (Not sure if we'd ideally want a 2px-wide "i" glyph there with equally-bright pixels, or what.)