[mpeg-OTspec] Re: [OpenType] RE: Proposal: deprecate ReqFeatureIndex

[Behdad Esfahbod]

Hi Peter,

Thanks for the detailed reply.  Comments inline:

On 08/24/2012 07:50 PM, Peter Constable wrote:
> 
> Every feature must still be in the feature tree -- that is, in the tree of tables pointed to by the FeatureList offset in the GSUB or GPOS headers.

Correct.  But I wouldn't call that the feature "tree".  To me, the feature
"tree" is the features listed by LangSys tables, and not every feature has to
be part of that.


> And a feature reference by ReqFeatureIndex must be associated with a language system since that field exists (and only exists) in the LangSys table. It would certainly be possible for that feature not to appear as well in the FeatureIndex array of the LangSys table -- in fact, the spec appears to suggest that, if it is reference by ReqFeatureIndex, then it is _not_ expected to be included in the FeatureIndex array:

Right.  I think we all agree that a feature pointed to by ReqFeatureIndex may
or may not appear as a listed feature in any LangSys.  Right?


> "The feature indices themselves (excluding the ReqFeatureIndex) are stored in arbitrary order in the FeatureIndex array."

Ok, so you have a point, that the spec kinda suggests that ReqFeatureIndex
cannot overlap with the FeatureIndex array.  But I thin that's an artificial
requirement that can be relaxed.


> Technically, that is possible. What happens, though, if you create a font and decide on some arbitrary tag "abcd" and that tag later gets proposed by someone as an addition to the feature tag registry? Might this cause problems in some libraries, tools or apps?

If the arbitrarily tagged feature "abcd" is not referenced in the FeatureIndex
array of any LangSys, there is no room for confusion.  That's my point.


> If you wanted to take this approach, then the details and assumptions should be spelled out in the OpenType spec. E.g., it might be specified that a FeatureList can have two or more FeatureRecord tables that use (say) "xxxx" as a tag, that a feature with such a FeatureRecord can only be referenced by the ReqFeatureIndex field of some LangSys table, that tools can provide special behaviour (as the tool designer chooses) for such features given the assumption that they can only be used in that way, and that application UI never needs to present any UI in connection with such a FeatureRecord.

The way the spec is written right now leaves it open to interpretation what
happens when a feature with a given index is enabled more than once, be it
once by ReqFeatureIndex or otherwise.  Say, what if both 'locl' and 'ccmp'
point to the same feature index.  Is it applied twice, or just once.  I'm
leaning on once the way the spec is.  The way I look at it, the spec is great
at specifying the file format, but not how to use it.


> Of course, all this assumes ReqFeatureIndex is considered a useful mechanism to keep around and recommend to implementers for support. But we've had a proposal from Adobe for exactly the opposite. Seems like that should be sorted out first.

I think most of the ongoing discussion is not limited to ReqFeatureIndex, but
the general lack of a documented layout algorithm.

behdad