465393 - Honor TEXT_DISABLE_OPTIONAL_LIGATURES in gfx{Pango,FT2}FontGroup

Status: RESOLVED WONTFIX

(Core :: Graphics, defect, P2)

Description

[Zack Weinberg (:zwol)]

Fragment of bug 464168 (q.v. for discussion) -- the Pango and FT2 implementations of gfxFontGroup need to honor the TEXT_DISABLE_OPTIONAL_LIGATURES flag in the return value of nsLayoutUtils::GetTextRunFlagsForStyle.

Comment 1

[Peter Weilbacher]

I think that, like gfxOS2Fonts, the gfxFT2Fonts implementation doesn't do font shaping yet, and therefore doesn't display ligatures. So this bug should (for now) only be concerned with the Pango implementation.

Comment 2

[Jonathan Kew [:jfkthame]]

Unfortunately, I don't think Pango currently provides an API for adjusting font features, to allow us to disable common ligatures when we're intending to letterspace the resulting glyphs.

I noticed that Pango does support a letterspacing attribute, so I wondered if we could use this rather than allowing it to do its normal shaping, and then space the resulting glyphs. But I have just tested and found that this also fails to break common ligatures.

So there are two issues here that we could regard as Pango bugs or shortcomings: (1) lack of an API to customize the collection of layout features used; and (2) letterspacing does not prevent formation of default ligatures like fi, ffi, etc. Until at least one of these is addressed in Pango, it's going to be hard for us to make much progress here.

An alternative approach would be to break the text into individual "letters" (not individual Unicode characters, actually; more likely graphemes) ourselves, rather than passing entire words to Pango, but this is unattractive because we'd lose not only the ligatures but also other shaping that we might want to keep (e.g., contextual swashes).

Perhaps as an interim solution, we should simply bypass Pango if there is non-zero letterspacing, and go via the FT2 path that doesn't do shaping. This would mean that letterspacing will break complex script rendering, but on the other hand it probably doesn't make much sense there anyway.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Egad.

I'd really hate to break required ligatures. Sure, people shouldn't be using letter-spacing with those scripts but we can't be sure they don't.

Another important principle is that changing our behaviour between releases has a cost to Web authors and users. So if we can't fix this right, let's just leave it alone for now. I don't think this bug is very serious.

Comment 4

[Zack Weinberg (:zwol)]

Would it be practical to take the FT2 path if there is letterspacing (well, if the DISABLE_OPTIONAL_LIGATURES flag is on -- layout might need to set that for other things in the future) *and* the characters in the text run are limited to a region of Unicode that we can assume doesn't have required ligatures?  For instance, "all characters <= U+02FF", U+0300 being the first of the combining diacritics.  That'd nail the original complaint - "ffi" in a letterspaced section heading - without breaking Arabic and the like.

Although if we can't fix it on Windows, maybe it's not that important to get it right on Linux.

I wish we didn't need so much platform-specific code for this stuff.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #4)
> Would it be practical to take the FT2 path if there is letterspacing (well, if
> the DISABLE_OPTIONAL_LIGATURES flag is on -- layout might need to set that for
> other things in the future) *and* the characters in the text run are limited to
> a region of Unicode that we can assume doesn't have required ligatures?  For
> instance, "all characters <= U+02FF", U+0300 being the first of the combining
> diacritics.  That'd nail the original complaint - "ffi" in a letterspaced
> section heading - without breaking Arabic and the like.

Possible, but not worth it IMHO.

Comment 6

[Jonathan Kew [:jfkthame]]

At this point, I think both Windows and Linux share the same problem: we can't selectively turn off the ligature feature(s) with the layout APIs we're currently using, short of abandoning OpenType shaping altogether.

Better feature control through the layout engine APIs would let us fix not only this, but also bugs like #463940 (referring to 'calt') and #458634 ('smcp'). The former ought really to be fixed within the layout engine itself, but the latter definitely requires us to be able to apply the feature on demand.

We'll run into the same problem more broadly trying to support font features in CSS. Maybe we need to try and and push HarfBuzz forward (AFAIK it doesn't yet offer what we need either).

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Vlad, you can make this 'wanted' but we still don't know how to implement it :-).

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Sure, that doesn't make it any less wanted, though :)

Comment 9

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.

Comment 10

[Jonathan Kew [:jfkthame]]

As we're now using the harfbuzz backend as our primary shaping path, and it supports the TEXT_DISABLE_OPTIONAL_LIGATURES flag, I think this bug is essentially obsolete. Should we resolve it as FIXED (indirectly, by using a different path), or as WONTFIX (because it's no longer important), or what?