Proposal: deprecate ReqFeatureIndex

[Peter Constable]

The ReqFeatureIndex field is really inadequate for the general problem of forcing a shaping engine to apply certain features, such as 'rlig': as we know, there are several features that should always be mandatory. This field can only specify one, and those details should be documented in the feature registry and then hard coded into shaping engine implementations.

Now, there is a different potential use for that field: indicating a feature that may not be mandatory for the script generally, but that should always be applied for a particular language. (Note that the field is in a langsys table, not a script table.) Now, any examples I've seen of attested usage (_very_ few) do not appear to be of that nature, and so I would not cite them as precedents. Also, even for this scenario, one could imagine a better data structure. For instance, it might have been useful if one could specify a feature and also an index for a type 3 (alternates) lookup, or to specify more than one feature. Even so, it can still be useful for this scenario in its present form by allowing a cvnn or ssnn feature to be specified.

Thus, even though it hasn't been used much (or, in those few cases, used well), it's not clear to me that it warrants deprecation. We're just now getting to a point in implementations at which langsys tables can actually become useful.


Peter

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Sairus Patel
Sent: August 13, 2012 3:20 PM
To: opentype-migration-list at indx.co.uk; mpeg-OTspec at yahoogroups.com
Subject: [mpeg-OTspec] Proposal: deprecate ReqFeatureIndex



I propose that this be considered for the 3rd edition of OFF that's being worked on right now.

--- Rationale:

Currently, each language system table in a GSUB or GPOS can specify the index of a "required" feature. A layout engine is always to apply this feature when performing layout in that language system.

However, this doesn't quite fit in a layout model wherein features are to be applied one at a time, and wherein certain feature tags are designated by a separate layout specification (and not in the font itself) as being required. For example, see MS's Arabic and Indic layout specifications at http://www.microsoft.com/typography/SpecificationsOverview.mspx.

Adobe's CoolType font engine (used by most Creative Suite products) removed support for ReqFeatureIndex in 2005, and FTE (Flash Text Engine) has never supported it.

Deprecating ReqFeatureIndex has come up a couple times on the OT and OFF lists, most recently Nov 29, 2011 (Subject "ReqFeatureIndex: obsolete?"), and I have not heard from anyone objecting to this. I have heard only supportive comments.

Thus, this proposal.


--- Proposal:

{ In section "Language System Table" at http://www.microsoft.com/typography/otspec/chapter2.htm, replace the following paragraphs: }

Optionally, a LangSys table may define a Required Feature Index (ReqFeatureIndex) to specify one feature as required within the context of a particular language system. For example, in the Cyrillic script, the Serbian language system always renders certain glyphs differently than the Russian language system.

Only one feature index value can be tagged as the ReqFeatureIndex. This is not a functional limitation, however, because the feature and lookup definitions in OpenType Layout are structured so that one feature table can reference many glyph substitution and positioning lookups. When no required features are defined, then the ReqFeatureIndex is set to 0xFFFF.

All other features are optional. For each optional feature, a zero-based index value references a record (FeatureRecord) in the FeatureRecord array, which is stored in a Feature List table (FeatureList). The feature indices themselves (excluding the ReqFeatureIndex) are stored in arbitrary order in the FeatureIndex array. The FeatureCount specifies the total number of features listed in the FeatureIndex array.

Features are specified in full in the FeatureList table, FeatureRecord, and Feature table, which are described later in this chapter. Example 2 at the end of this chapter shows a Script table, LangSysRecord, and LangSys table used for contextual positioning in the Arabic script.

{ by (a modified version of the last two paragraphs above): }

For each feature in this table, a zero-based index value references a record (FeatureRecord) in the FeatureRecord array, which is stored in a Feature List table (FeatureList). The feature indices themselves are stored in arbitrary order in the FeatureIndex array. The FeatureCount specifies the total number of features listed in the FeatureIndex array.

Features are specified in full in the FeatureList table, FeatureRecord, and Feature table, which are described later in this chapter. Example 2 at the end of this chapter shows a Script table, LangSysRecord, and LangSys table used for locale-specific numeric forms in the Arabic script.

{ In the entry for ReqFeatureIndex in the "LangSys table" table, replace the "Name" value with: }

Reserved

{ and replace the "Description" value with: }

Set to 0xFFFF. (This used to be ReqFeatureIndex in some previous versions of the specification.)

{ In the "Example 2" section further down the page, replace: }

Then the text-processing client uses a required OpenType Layout glyph substitution feature, defined in the Urdu LangSys table, to access the correct Urdu glyphs for the 4, 6, and 7 numerals.

{ by: }

Then the text-processing client uses the Localized Forms ("locl") feature referenced in the Urdu LangSys table to access the correct Urdu glyphs for the 4, 6, and 7 numerals.

{ In the table in "Example 2":

Under DefLangSys, replace the comment "ReqFeatureIndex, no required features" by "Reserved".

Under UrduLangSys, replace the ReqFeatureIndex line with: FFFF | 0xFFFF | Reserved

Under UrduLangSys, change the FeatureCount from 3 to 4

Under UrduLangSys, add an additional line: 0003 | 3 | FeatureIndex[3], "locl" feature (localized forms)
}

Sairus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20120821/49f1f404/attachment.html>