939132 - CSS letter-spacing results in erratic spacing on platforms without subpixel glyph positioning

Status: RESOLVED WORKSFORME

(Core :: Layout: Text and Fonts, defect, P4)

Description

[Jonathan Kew [:jfkthame]]

Attachment: testcase for letter-spacing at various font sizes

On platforms where glyph positions are rounded to the nearest pixel (e.g. Windows GDI, Linux, Gaia apps), the text shaping code tries to maintain inter-glyph spacing as near as possible to the "ideal" value (e.g. see bug 716402), while rounding the final glyph positions to whole pixels.

However, when letter-spacing is used, this defeats the careful work done there, as it is applied as an adjustment on top of the already-rounded positions, and accumulates along the text run. As a result, using letter-spacing may lead to undesirable irregularities when the newly-adjusted glyph positions are again snapped to whole pixels.

It would be better to apply letter-spacing at the end of the shaping process but *before* the glyph advances/positions are rounded, so that the (often fractional) letter-spacing value is taken into account at that stage, and rounding of ideal glyph positions to whole pixels (with the associated loss of accuracy) only happens once.

Comment 1

[Jonathan Kew [:jfkthame]]

Attachment: screenshot of testcase as rendered on Linux

The glyph spacing in the middle <div> (no letter-spacing) is consistent; in both the left and right <div>s (negative and positive letter-spacing respectively) it becomes inconsistent.

Windows/GDI rendering is similar.

Comment 2

[Jonathan Kew [:jfkthame]]

BTW, if we fix this, it will supersede bug 368107, which suggests rounding letter-spacing values to the nearest pixel. (I don't think that's desirable, as it would make it impossible to use letter-spacing for more subtle adjustments.)

Comment 3

[Kan-Ru Chen [:kanru] (UTC+9)]

I plan to work on this in my spare time since the irregular letter spacing on fastmail.com is driving me crazy (they apply letter-spacing: 1px to their default webfont).

My understanding so far:

* Text shaping is executed in gfxFont::SplitAndInitTextRun from gfxFontGroup::InitScriptRun from gfxFontGroup::MakeTextRun
* In gfxGraphiteShaper or gfxHarfBuzzShaper, after ShapeText, glyph spacing is carefully rounded in SetGlyphsFromRun or SetGlyphsFromSegment.
* Letter spacing is stored as mLetterSpacing in nsTextFrame::PropertyProvider
* gfxTextRun::DrawGlyphs use the provider to calculate the spacing and pass it to gfxFont::Draw (does it mean spacing is calculated for every repaint?)

(In reply to Jonathan Kew (:jfkthame) from comment #0)
> It would be better to apply letter-spacing at the end of the shaping process
> but *before* the glyph advances/positions are rounded, so that the (often
> fractional) letter-spacing value is taken into account at that stage, and
> rounding of ideal glyph positions to whole pixels (with the associated loss
> of accuracy) only happens once.

It looks like when shaping the text we already know the letter spacing parameters. We just need to pass it to the text shaper then the letter/word spacing will become part of the glyph spacing calculated by the text shaper. This will require we re-shape text when layout changes, I assume we do.

:jfkthame, does this sounds right? Anything else I need to consider?

Comment 4

[Jonathan Kew [:jfkthame]]

Yes, it sounds like you're on the right track.

I think you'll need to consider the shaped-word cache (attached to each gfxFont instance, see gfxFont::CacheHashKey and CacheHashEntry). I'm not sure whether a single shaping operation can cross a boundary between different letter-spacing values; I think we currently break shaping there, although that may not be the best behavior. Assuming letter-spacing is constant within a single shaping run, you may be able to just include it in the cache key.

I suppose changing this will make it more expensive to animate letter-spacing, because it will force re-shaping all the text, and the shaped-word caches could grow due to the presence of multiple instances of each word with different spacing. But that's probably a rare enough scenario that it's an acceptable trade-off.

Comment 6

[Kestrel]

Several reports of this on reddit recently:

https://www.reddit.com/r/firefox/comments/8n8p87/css_letterspcaing_with_non_natural_integers/
https://www.reddit.com/r/firefox/comments/8nldcm/firefox_shows_wrong_fontkerning_in_gmail/
https://www.reddit.com/r/firefox/comments/7xezu1/firefox_linux_font_kerning_is_off/
https://www.reddit.com/r/firefox/comments/7x24au/can_anybody_help_me_with_font_rendering_on_linux/
https://www.reddit.com/r/firefox/comments/7i19tl/bad_kerning_in_google_sheets/

Perhaps more popular sites are using letter-spacing making it more noticeable.

Comment 8

[Alistair Buxton]

Attachment: kerning.gif

Many Google sites including Gmail use sub-pixel letter spacing. The attached gif shows the difference between 0.2px and forced 0px letter-spacing with Stylish on the new Gmail UI. The one with random spaces in words is the default.

Comment 9

[Calin Cruceru [:crucerucalin]]

This is really annoying -- is someone still working on this?

Comment 10

[Gianluca Recchia]

This is the only reason I'm still using Chrome. Will this never be fixed?

Another instance of the same issue can be found on https://about.google. Something is clearly off in the navbar at the top.

Comment 11

[Laurențiu Nicola]

Does Firefox use Pango? The latest version supports sub-pixel positioning, maybe that would help here?

https://blogs.gnome.org/mclasen/2019/07/27/more-text-rendering-updates/

Comment 12

[Kestrel]

This is fixed for me in latest Nightly.

Fix window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=28fcea56b3a3ee186aa736c80e1f95b62c7bcf74&tochange=566dce282e2c06afa4318ba35d471f5c2b8c85e2

Fixed by Bug 1583707.

Comment 13

[Gianluca Recchia]

It seems fixed for me too. I just downloaded the latest nightly build and checked.

Comment 15

[Gian-Carlo Pascutto [:gcp]]

In the context of this bug, it should be noted that this was fixed by enabling sub-pixel font positioning for almost all users. However, if you use settings that force it off (e.g. Kubuntu as we discovered in bug 1481545), then this will break again and make things like Gmail look particularly ugly.