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

RESOLVED INVALID

Status

()

RESOLVED INVALID
8 years ago
6 years ago

People

(Reporter: dr.khaled.hosny, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

8 years ago
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.
(Reporter)

Comment 1

8 years ago
Created attachment 501054 [details]
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.
(Reporter)

Updated

8 years ago
Component: General → Layout: Text
Product: Firefox → Core

Comment 2

8 years ago
I know that the feature bit setting is bogus, have not fully figured it out yet.  Lets keep this bug open.
Component: Layout: Text → Style System (CSS)
QA Contact: general → style-system
(Reporter)

Comment 3

6 years ago
Created attachment 731882 [details]
Test file showing the broken behaviour

Updated test file using new -moz-font-feature-settings syntax.
Attachment #501054 - Attachment is obsolete: true
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?)
(Reporter)

Comment 5

6 years ago
(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.
(Reporter)

Comment 6

6 years ago
Created attachment 731945 [details]
Test file

This new test file compares the two approaches for selectively enabling default features (just for the record).
Attachment #731882 - Attachment is obsolete: true
(Reporter)

Updated

6 years ago
Attachment #731945 - Attachment mime type: text/plain → text/html
(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".
(Reporter)

Comment 8

6 years ago
(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

6 years ago
I agree that it's time to close this.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.