697049 - out of range font feature settings still activate feature

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[John Daggett (:jtd)]

While testing patches to support various font-variant-xxx subproperties, I noticed that we seem to handle unsupported feature values incorrectly.  Tal Leming put together a feature testing font that maps different PUA codepoints to pass/fail glyphs for a given feature.  This allows us to check whether individual features are activated or not.

U+E140 - default glyph shows 'PASS', nalt=1 glyph shows 'FAIL'
U+E141 - default glyph shows 'FAIL', nalt=1 glyph shows 'PASS'

#test1 { -moz-font-feature-settings: "nalt=1"; }
#test2 { -moz-font-feature-settings: "nalt=2"; }

<p>&#xe140;</p>
<p id="test1">&#xe141;</p>
<p id="test2">&#xe140;</p>

In this case, "nalt=2" should display the default glyph since there's no nalt=2 glyph available but instead it shows the alternate glyph.

This may be an artifact of the way this font is constructed, the particular lookups may not be the appropriate lookup type for a multivariate feature like 'nalt'.  But I don't think the lookup type should dictate the behavior like this.

Note: using Hiragino Mincho ProN instead of the test font displays the default glyph correctly.

Comment 1

[Jonathan Kew [:jfkthame]]

It'd be interesting to confirm whether this is affected by updating to the latest harfbuzz code (bug 695857).

Comment 2

[Behdad Esfahbod]

Can someone package that font into a test for harfbuzz upstream?

What you explain happens with all gsub lookup types except for AlternateSubst.  For AlternateSubst, we return if requested alternate is out of range.  For all other lookup types, they're simply booleans, and we don't even bother checking the value requested.

I have a feeling that what we do is at least good enough.  But I'm open to suggestions.

Comment 3

[Jonathan Kew [:jfkthame]]

I'm inclined to agree: for GSUB lookup types other than AlternateSubst, it makes sense to regard the feature as a boolean switch, and treat 0 as "off" and non-zero as "on".

(The same would apply to GPOS lookups, so "mark=2,mkmk=3" would be expected to enable the mark and mkmk features in exactly the same way as the more "canonical" version "mark=1,mkmk=1".)

Comment 4

[John Daggett (:jtd)]

I think the problem with use "non-zero enables" logic for boolean lookup types is that the OpenType spec doesn't define features normatively in terms of the lookups used for each nor does it restrict them to one lookup type or another.

The annotation feature is an example of this, the recommended lookup can either be type 1 or type 3.  In which case "nalt=23" will behave differently depending upon the lookup type used.  I don't think that's a really great idea, I think the error handling behavior needs to be consistent independent of lookup type used in the font.

Is there a strong reason in *favor* of using "non-zero enables" logic?  Seems like you're just trying to be more tolerant of obvious user errors (e.g. "mark=2,mkmk=3").

Comment 5

[Behdad Esfahbod]

(In reply to John Daggett (:jtd) from comment #4)
> I think the problem with use "non-zero enables" logic for boolean lookup
> types is that the OpenType spec doesn't define features normatively in terms
> of the lookups used for each nor does it restrict them to one lookup type or
> another.
> 
> The annotation feature is an example of this, the recommended lookup can
> either be type 1 or type 3.  In which case "nalt=23" will behave differently
> depending upon the lookup type used.  I don't think that's a really great
> idea, I think the error handling behavior needs to be consistent independent
> of lookup type used in the font.

John,

The use of "nalt=23" presumes that the user knows the font and its 'nalt' feature, so the lookup type is already known.  This is font specific afterall.  Any value other than "enable" is extremely font specific and presumes that user knows the exact font they are using and what they are doing.

> Is there a strong reason in *favor* of using "non-zero enables" logic? 
> Seems like you're just trying to be more tolerant of obvious user errors
> (e.g. "mark=2,mkmk=3").

It's just how the code naturally flows.

Comment 6

[John Daggett (:jtd)]

This is simply the nature of different lookup types in OpenType.  Kinda sucks but, meh...