- From: Jonathan Kew <jfkthame@googlemail.com>
- Date: Wed, 23 Jun 2010 11:53:20 +0100
- To: John Hudson <tiro@tiro.com>, opentype-migration-list@indx.co.uk
- Cc: John Daggett <jdaggett@mozilla.com>, www-font <www-font@w3.org>, Bram Pitoyo <brampitoyo@gmail.com>, Vladimir Levantovsky <Vladimir.Levantovsky@MonotypeImaging.com>
On 23 Jun 2010, at 04:46, John Hudson wrote: >>> I'm guessing that layout engines encountering unregistered features, >>> if they do anything with them at all, will process them after >>> registered features, but to my knowledge there is no standard >>> protocol regarding this. > >> Is this something that we should ask the OpenType folks to clarify in >> a future spec revision? Including this in a CSS spec doesn't feel >> right although it would be expedient. > > Yes, I think the OT/OFF specs or related documentation would would be the place for this. Yes, the OT/OFF specs could use some clarification. cc'ing the OpenType list, which is probably a better place for any further discussion. In general, it seems that all features are supposed to be applied "together", with the actual lookups that implement the features being applied in the order they're defined in the font: <quote src="http://www.microsoft.com/typography/otspec/chapter2.htm"> After choosing which features to use, the client assembles all lookups from the selected features. Multiple lookups may be needed to define the data required for different substitution and positioning actions, as well as to control the sequencing and effects of those actions. To implement features, a client applies the lookups in the order the lookup definitions occur in the LookupList. As a result, within the GSUB or GPOS table, lookups from several different features may be interleaved during text processing. </quote> I think this is a good approach, in that it gives the font developer the freedom to decide how best to implement the lookups for interacting features. However, some of the specs for implementing particular scripts conflict with this, in that they explicitly require certain features to be applied in a predetermined order; for example, the Devanagari specification calls for features to be applied "one at a time", and for a glyph reordering step that is interposed between two sets of features: <quote src="http://www.microsoft.com/typography/otfntdev/devanot/shaping.aspx"> All characters from a string are first mapped to their nominal glyphs using the cmap lookup. The shaping engine then proceeds to shape (substitute) the glyphs using GSUB lookups. The features for localized forms and basic shaping forms are applied one at a time to the cluster or a relevant portion of the cluster. The results after basic shaping forms features have been applied impact the final syllable analysis in terms of final designation of Ra as a pre-base reordering form and final reordering positions for reph and matras. Next, the features for presentation forms are applied to the entire cluster simultaneously. Note: since the presentation form features are applied simultaneously over the entire cluster, several features are operationally equivalent to a single feature. Multiple features are provided as an aid for font developers to organize the lookups they implement. Note: final reordering occurs after features for basic shaping forms have been applied and before features for presentation forms are applied. Font developers must consider the effects of initial reordering (before any features are applied) and final reordering (after basic shaping forms features have applied) when they create GSUB feature and lookup tables. These predefined features are described and illustrated in the Features section and are applied in the order below. </quote> This clearly conflicts with the standard feature/lookup processing model presented in the OT spec, as quoted above. Moreover, there is no indication of where additional user-specified features should be applied in this scenario. In practice, applying them during the final step, together with the defined "features for presentation forms", probably makes the most sense, but (AFAIK) this is not specified anywhere. JK
Received on Wednesday, 23 June 2010 10:53:58 UTC