Open Bug 1320270 Opened 7 years ago Updated 2 years ago

spans with font-feature-settings break OpenType layout

Categories

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

defect

Tracking

()

People

(Reporter: khaled, Unassigned)

Details

Attachments

(1 file)

Attached file Test HTML file
In the attached test file, the span with font-feature-settings breaks OpenType layout (Arabic shaping here), unlike the span with color.

This makes it impossible to, say, apply a stylistic set or a character variant to part of the word. Gecko already knows that some styles should not break OpenType layout like color, and I think this should be extended to cover font features as well.
I wonder whether it is possible to keep the OpenType layout with different font-feature-settings... font-feature-settings can change shape of glyphs, so it is probably not expected to work at all.

jfkthame, what do you think?
Flags: needinfo?(jfkthame)
In general, we expect changes to font-feature-settings will break shaping across the run boundary, as the text on each side will be shaped separately (with its own distinct feature settings).

However, ideally we would still support the basic Arabic shaping features (init/medi/fina/isol) even across such boundaries, as these are applied by the shaper based on the Unicode text rather than being user-specified features that depend on the style. To make this work, we need to pass the appropriate context to harfbuzz when shaping the run, so that it can apply the correct features to the initial/final characters. Harfbuzz has API that supports this, but we don't currently use it in gecko.

(Note that when we implement this, the gfxFont shaped-word cache will need to be aware of it, too.)
Flags: needinfo?(jfkthame)
(In reply to Jonathan Kew (:jfkthame) from comment #2)
> In general, we expect changes to font-feature-settings will break shaping
> across the run boundary, as the text on each side will be shaped separately
> (with its own distinct feature settings).

But HarfBuzz can apply features to ranges inside the buffer, so they don’t have to be shaped separately.

> However, ideally we would still support the basic Arabic shaping features
> (init/medi/fina/isol) even across such boundaries, as these are applied by
> the shaper based on the Unicode text rather than being user-specified
> features that depend on the style. To make this work, we need to pass the
> appropriate context to harfbuzz when shaping the run, so that it can apply
> the correct features to the initial/final characters. Harfbuzz has API that
> supports this, but we don't currently use it in gecko.
> 
> (Note that when we implement this, the gfxFont shaped-word cache will need
> to be aware of it, too.)

This will fix the basic shaping, but other OpenType feature will not be applied, which makes it practically impossible to use certain classes of OpenType features that should be applied only to individual characters (like character variants) without breaking, say, kerning or ligatures.
(In reply to Khaled Hosny from comment #3)
> (In reply to Jonathan Kew (:jfkthame) from comment #2)
> > In general, we expect changes to font-feature-settings will break shaping
> > across the run boundary, as the text on each side will be shaped separately
> > (with its own distinct feature settings).
> 
> But HarfBuzz can apply features to ranges inside the buffer, so they don’t
> have to be shaped separately.

True, though I suspect that making Gecko use this would be a substantially more invasive (and perhaps expensive) change, which may make it less likely we'll get it done any time soon.

> > However, ideally we would still support the basic Arabic shaping features
> > (init/medi/fina/isol) even across such boundaries, as these are applied by
> > the shaper based on the Unicode text rather than being user-specified
> > features that depend on the style. To make this work, we need to pass the
> > appropriate context to harfbuzz when shaping the run, so that it can apply
> > the correct features to the initial/final characters. Harfbuzz has API that
> > supports this, but we don't currently use it in gecko.
> > 
> > (Note that when we implement this, the gfxFont shaped-word cache will need
> > to be aware of it, too.)
> 
> This will fix the basic shaping, but other OpenType feature will not be
> applied, which makes it practically impossible to use certain classes of
> OpenType features that should be applied only to individual characters (like
> character variants) without breaking, say, kerning or ligatures.

In principle, yes. I wonder how common it is, though, to need to specify features on the individual-character level. Even something like character variants (cvXX features) would usually be set "globally" for a text or style: IIUC, the normal use-case is something like "I want to use the 'round a' variant of 'a' throughout this text for new readers" rather than "this individual instance of 'a' should be the round variant, while others in the same word are the two-storey form".

So while I agree that would be the ideal, I'm not sure how high of a priority it is compared to other things. Preserving basic Arabic shaping across style-run boundaries (by providing context to the harfbuzz buffer) seems higher priority to me, and can probably be implemented more easily.
I must disagree very strongly that this is unimportant or an uncommon use case. Kerning must cross over feature boundaries. I format text with OpenType layout with a difference in individual characters all the time. I am not alone. This is a VERY COMMON use case.

The existing behavior is simply wrong and broken.

Examples:
- Caps with small caps. First letter is a cap, further letters in same word small caps.
- Formatting a word with a starting swash cap, starting titling alternate, or an ending swash
- Use of initial, medial, final or isolated forms, if applied either manually or by the text engine, will break the run within a word. Initial, medial and final forms are specifically intended to be applied to different portions of the same word.
- stylistic alternates (salt) are often applied to individual letters in a word

Those are only the examples that occur to me in the time it takes me to type this reply. There will be many more.
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: