[OTL feature suggestion : Required Contextual Forms <rclt>

[Adam Twardoch (List)]

On the other hand, I don't think there would be much harm in registering
a "rclt" feature.

In addition, it might be good practice to assign the same lookups to
both the "rclt" feature and the "calt" feature.

To ensure compatibility with older OTL engines that may not be aware
that "rclt" is a "required" feature but that do implement the
ReqFeatureIndex mechanism (I must admit, I do not know which those are),
font developers would be encouraged to point the ReqFeatureIndex to that
newly introduced "rclt" feature, or to the functionally identical "calt"
feature.

In such situation:

1. "rclt"-aware OTL engines, i.e. those that that understand the nature
of the new "rclt" feature (that it is "required by the engine") would
always apply "rclt" -- regardless of the user's choice.

2. Older ReqFeatureIndex-compliant OTL engines, i.e. those that may not
know or understand the nature of "rclt" or may have no notion of it
whatsoever but do implement the ReqFeatureIndex mechanism would apply
the "rclt" feature since it's mandated by ReqFeatureIndex. An even safer
option would be if "calt" were marked by ReqFeatureIndex. Older
ReqFeatureIndex-compliant OTL engines would typically know of its
existence, and would ensure that it's applied since it's mandated by
ReqFeatureIndex -- regardless of the user's choice.

3. Older ReqFeatureIndex-non-compliant OTL engines, i.e. those that do
not know what "rclt" is and do not implement the ReqFeatureIndex
mechanism would still apply "calt" as they normally would, i.e. would
probably have it on by default but allow the user to turn it off.

Best,
Adam

Adam Twardoch (List) wrote:
> Message from OpenType list:
> 
> 
> John,
> 
> the OpenType specification has (I think always) contained a mechanism
> for what you describe:
> 
> http://www.microsoft.com/typography/otspec/chapter2.htm
> 
> "Language System Table
> 
> The Language System table (LangSys) identifies language-system features
> used to render the glyphs in a script. (The LookupOrder offset is
> reserved for future use.)
> 
> 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. (...)"
> 
> In other words: in addition to the OpenType features that a layout
> engine considers "required" (such as "rlig" or "ccmp"), the font maker
> can define which (one) feature she considers "required" for a given OTL
> languagesystem (including the DefaultLangSys) within a given OTL script.
> 
> So if the font maker considers the "calt" feature "required" for the
> "latn" script in her font, she can point the ReqFeatureIndex for
> "latn"/DefaultLangSys to the "calt" feature.
> 
> Whether and which OTL engines support ReqFeatureIndex is another matter.
> But I'm not certain if introducing a new mechanism where an old (and a
> quite reasonably specified) one already exists is a wise choice. We
> might be better off to encourage OTL engine makers to recognize and
> automatically apply the feature indicated by ReqFeatureIndex along with
> other "required" features for a given script.
> 
> Best,
> Adam
> 
> 
> John Hudson wrote:
>>  
>>
>> Each OpenType Layout feature is optimally implemented by layout engines
>> and applications in one of three possible states:
>>
>> 1. On by default and impossible to turn off (required feature, e.g. <rlig>);
>>
>> 2. On by default but possible to turn off (standard feature, e.g. <liga>);
>>
>> 3. Off by default but possible to turn on (discretionary feature, e.g.
>> <dlig>.
>>
>> In practice, some software makers opt, given limited support for feature
>> UI, to treat e.g. standard features as required for some scripts, but
>> the ideal is fairly clearly defined in the feature description (and can
>> be even more clearly defined with appropriate annotations).
>>
>> [If I were designing the OpenType Layout architecture from scratch, I
>> think I would be inclined to try to treat these states as lookup-level
>> flags, rather than feature-level properties, which among other benefits
>> would decrease the number of features needed. But that's not the
>> architecture we've got, so consider this an speculative aside.]
>>
>> In the past couple of years, I've noticed an increasing number of fonts
>> using contextual substitutions for design-specific basic shaping, e.g.
>> variants to improve spacing as in my own Gabriola font or as described
>> in Eben Sorkin's TypeCon 2008 presentation. Most recently, there was a
>> query about making such fonts in the Typophile Build forum.
>>
>> At present, such substitutions are typically implemented in the
>> Contextual Forms <calt> layout feature. However, this feature is
>> intended to be implement using state 2: standard feature, on by default,
>> can be turned off. Because these substitutions are intrinsic to the
>> correct or desired normal display of the typeface design -- and because
>> of the possibility that the same font may include other, standard
>> substitutions that are not similarly intrinsic to the design --, I am
>> increasingly of the view that we need a Required Contextual Forms <rclt>
>> layout feature, which would be on by default and impossible to turn off
>> (state 1).
>>
>> I'm happy to draft a feature description, but am writing to the OT and
>> OFF lists first to garner feedback on the idea.
>>
>> John Hudson
>>
>> -- 
>>
>> Tiro Typeworks www.tiro.com
>> Gulf Islands, BC tiro at tiro.com <mailto:tiro at tiro.com>
>>
>> Car le chant bien plus que l'association d'un texte
>> et d'une mélodie, est d'abord un acte dans lequel
>> le son devient l'expression d'une mémoire, mémoire
>> d'un corps immergé dans le mouvement d'un geste
>> ancestral. - Marcel Pérès
>>
>> 
> 
> 


-- 

Adam Twardoch
| Language Typography Unicode Fonts OpenType
| twardoch.com | silesian.com | fontlab.net

Reporter: "So what will your trip to Ireland look like?"
Lech Wałęsa: "I get into a car, then onto a plane, and then the other
way around."