622876 - Manually selecting isol/init/medi/fina OpenType features applies them unconditionally

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[Khaled Hosny]

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b8) Gecko/20100101 Firefox/4.0b8
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b8) Gecko/20100101 Firefox/4.0b8

I was trying to test the new CSS property "-moz-font-feature-settings" with Arabic fonts, and found that features that should be applied conditionally like isol, init, medi or fina, are applied unconditionally when selecting using this property.

Reproducible: Always

Steps to Reproduce:
1. Open the attached file
2. Watch the rendering of each line
3.
Actual Results:  
Feature are applied in places where it shouldn't.

Expected Results:  
Features should be applied conditionally based of character's position in the word, as it does correctly of no features are set.

The actual result differs slightly from a font to another, but all are broken.

Comment 1

[Khaled Hosny]

Attachment: Test file showing the broken behaviour

BTW, without the empty @font-face declaration the text comes all isolated with no shaping at all, I'm not sure if this is another bug.

Comment 2

[Behdad Esfahbod]

I know that the feature bit setting is bogus, have not fully figured it out yet.  Lets keep this bug open.

Comment 3

[Khaled Hosny]

Attachment: Test file showing the broken behaviour

Updated test file using new -moz-font-feature-settings syntax.

Comment 4

[Jonathan Kew [:jfkthame]]

I don't think this is a bug. -moz-font-feature-settings is expected to apply feature settings "globally" to whatever text it's applied to.

Those features are not really designed to be controlled directly by authors; they're intended for "internal" use by script-specific shaping engines, which decide where to apply them on a character-by-character basis. By setting them with -moz-font-feature-settings, you're explicitly overriding that behavior, and forcing the feature(s) to be applied even to characters where the script rules wouldn't use them.

(What are you actually trying to achieve here?)

Comment 5

[Khaled Hosny]

(In reply to Jonathan Kew (:jfkthame) from comment #4)
> I don't think this is a bug. -moz-font-feature-settings is expected to apply
> feature settings "globally" to whatever text it's applied to.
> 
> Those features are not really designed to be controlled directly by authors;
> they're intended for "internal" use by script-specific shaping engines,
> which decide where to apply them on a character-by-character basis.

Given the inherit contextual nature of these features, I don’t see contridiction here; just like enabling, say, “calt” on the whole text does not mean the engine has to apply the substitution lookup unconditionally on each glyph.

> By
> setting them with -moz-font-feature-settings, you're explicitly overriding
> that behavior, and forcing the feature(s) to be applied even to characters
> where the script rules wouldn't use them.
> 
> (What are you actually trying to achieve here?)

For demonstration purposes, I want to show in steps the effect of applying each feature on a string of text. Now I see this can be achived in a different way; be selectively disabling features one by one instead of disabling them all then re-enabling them one by one like I’m doing now.

Overall, the issue is not really important, it was just a neat hack I wanted to try back then, and it is really a HarfBuzz issue not Firefox’s.

Comment 6

[Khaled Hosny]

Attachment: Test file

This new test file compares the two approaches for selectively enabling default features (just for the record).

Comment 7

[Jonathan Kew [:jfkthame]]

(In reply to Khaled Hosny from comment #5)
> (In reply to Jonathan Kew (:jfkthame) from comment #4)
> > I don't think this is a bug. -moz-font-feature-settings is expected to apply
> > feature settings "globally" to whatever text it's applied to.
> > 
> > Those features are not really designed to be controlled directly by authors;
> > they're intended for "internal" use by script-specific shaping engines,
> > which decide where to apply them on a character-by-character basis.
> 
> Given the inherit contextual nature of these features, I don’t see
> contridiction here; just like enabling, say, “calt” on the whole text does
> not mean the engine has to apply the substitution lookup unconditionally on
> each glyph.

I don't think that's comparable. Enabling 'calt' -does- cause the engine to apply the 'calt' lookup(s) to every glyph. However, those lookups will normally involve lookahead/behind contexts, such that they will have no effect except in specific contexts as determined by the font designer.

You -could- do the same thing in init/medi/fina (i.e. provide contexts for the lookups, such that they'd do the "right" thing when applied globally), but nobody does, because it's understood that the shaping engine will decide exactly which glyphs to apply them to. But for the same reason, it doesn't really make sense to override them with a global feature setting, as per -moz-font-feature-settings.

> 
> > By
> > setting them with -moz-font-feature-settings, you're explicitly overriding
> > that behavior, and forcing the feature(s) to be applied even to characters
> > where the script rules wouldn't use them.
> > 
> > (What are you actually trying to achieve here?)
> 
> For demonstration purposes, I want to show in steps the effect of applying
> each feature on a string of text. Now I see this can be achived in a
> different way; be selectively disabling features one by one instead of
> disabling them all then re-enabling them one by one like I’m doing now.
> 
> Overall, the issue is not really important, it was just a neat hack I wanted
> to try back then, and it is really a HarfBuzz issue not Firefox’s.

HarfBuzz would (I think) support applying these features to specific substrings of a run, overriding what the Arabic shaper would do. But -moz-font-feature-settings doesn't provide you with an interface that can access this; whatever you specific with the CSS feature properties will apply to the entire run.

It would presumably work, for demonstration purposes, to wrap each character in a separate <span>, so that you could set different features on each one. But that would prevent -any- features applying across multiple characters, as spans with different feature settings will be shaped in separate operations.

As you say, selectively -disabling- some of the "automatic" shaper features is probably a usable workaround for your purposes. If you disable them all in the @font-face declaration, there's nothing in CSS that will let you re-enable them selectively -with their script-specific shaping behavior-; any re-enabling you do in CSS styles will override that and set them "globally".

Comment 8

[Khaled Hosny]

(In reply to Jonathan Kew (:jfkthame) from comment #7)
> As you say, selectively -disabling- some of the "automatic" shaper features
> is probably a usable workaround for your purposes. If you disable them all
> in the @font-face declaration, there's nothing in CSS that will let you
> re-enable them selectively -with their script-specific shaping behavior-;
> any re-enabling you do in CSS styles will override that and set them
> "globally".

Understood (and I’m happy with the existing solution for my need). Feel free to close this issue.

Comment 9

[Behdad Esfahbod]

I agree that it's time to close this.

Comment 10

[Jonathan Kew [:jfkthame]]

OK - resolving this as "invalid", as I think current behavior is correct (behaving as designed) for the CSS font-feature properties.

To support the behavior Khaled was originally hoping for, I think we'd need to define an "auto" value for individual features, so that you could do something along the lines of:

@font-face {
  ...
  font-feature-settings: "init" off, "medi" off, "fina" off, "rlig" off, ....
}

to turn all the features off as a baseline setting, and then:

.initial-forms {
  font-feature-settings: "init" auto;
}

.medial-forms {
  font-feature-settings: "medi" auto;
}

.final-forms {
  font-feature-settings: "fina" auto;
}

to hand control of individual features back to the shaper, rather than setting a fixed value for them. But at this point, I don't see a compelling need to add this complexity.