Eben,

the code Henadij posted is principally correct but it is better to name the glyphs according to the Adobe/FontLab naming conventions: baseglyphname.suffix. Fontlab Ltd. recommends that the suffix for localized forms corresponds either to the primary OpenType feature name that the localized glyph is associated with (that would be "locl") or to the OpenType language tag of the primary language that the localized form is associated with (that would be "PLK" for Polish in Henadij's example).

So if I wrote the code, it would be:

@loclPLK1 = [cacute nacute oacute sacute zacute];
@loclPLK2 = [cacute.PLK nacute.PLK oacute.PLK sacute.PLK zacute.PLK];

feature locl { # Localized Forms
language PLK exclude_dflt; # Polish;
sub @loclPLK1 by @loclPLK2;
} locl;

Alternatively, the glyph names "cacute.PLK" etc. could be "cacute.locl".

Adobe software does not parse the glyph suffixes into anything meaningful yet, but Fontlab Ltd. does plan to have some smart algorithms that takes notion of properly formed glyph name suffixes.

Regards,
Adam

Eben, it doesn't hurt to have a locl feature in yout font. And you can also "double-up" the feature as a Stylistic Set, which will allow present users of InDesign CS2 access to it.

Adam, Wow! So clearly put & so fast! Awesome.

Chester, can you point me at some feature code for a 'stylistic set'? Is the feature called 'ss01'? Or is it 'salt?' I bet it's ss01 ( ss02, etc) There is probably some discustion of this feature here on typophile. I'd better search for it.

Thanks to you both!

ssXX is it. The first one in your font will be ss01. And the way it would look, borrowing Adam's code above:

feature ss01 { # Polish Localized Forms
language PLK exclude_dflt; # Polish;
sub @loclPLK1 by @loclPLK2;
} ss01;

So then the complete code would look like this :

@loclPLK1 = [cacute nacute oacute sacute zacute];
@loclPLK2 = [cacute.PLK nacute.PLK oacute.PLK sacute.PLK zacute.PLK];
feature ss01 { # Polish Localized Forms
language PLK exclude_dflt; # Polish;
sub @loclPLK1 by @loclPLK2;
} ss01;

Or do you only need the code you showed if the locl feature precedes the ss01 feature?

Also I noticed that when I test The locl or the langage feature in Fontlab that my calt features are not available to be applied at the same time. It seems to be either or in the Fontlab preview. Willl it be like that in Indesign or other apps too?

Nothing wrong with also putting this in a stylistic set, but you should certainly do it in 'locl' as well.

T

Will it be like that in Indesign or other apps too?

It certainly shouldn't be. Microsoft's approach, which I hope other layout engine developers will follow, is to apply the 'locl' feature before any other layout feature, thereby setting the localised input glyphs for all subsequent features. Then the 'ccmp' feature is applied, and then the other supported features in the order in which the lookups are ordered in the font (with some exceptions for complex script handling, e.g. for Indic scripts, in which language shaping features are strictly ordered by the shaping engine). Once the 'locl' feature has been applied, you should be able to apply any other features to the results: the 'locl' feature is certainly not supposed to be exclusive.

Paul Nelson showed a demonstration of 'locl' feature support in MS Publisher at the ATypI conference in Rome in 2002 (specifically, substitution of preferred Urdu forms of Persian numeral characters). This has not been released though, and the fact that he demo'd it doesn't necessarily mean it will be in Office 12. MS, like most software companies, won't commit to or comment on functionality of unreleased products. They test a lot of things internally that might not show up in published software for two or three versions, if at all.

On 25 February 2005, Paul noted on the OpenType developer list that APIs for calling language system tags had been added to Uniscribe (the MS Unicode Script Processor), so the back end will be in Windows Vista. But applications will need to take advantage of the new APIs.

Thanks for the clarification John! I have been to the official adobe feature request page to ask for locl support. Is there a MS equivalent? I have no idea if it means anything but I figure I have to try...

I'll note that it would be a wise precaution to order the locl and ccmp lookups in the same order as well, in case one puts the font in some environment that relies strictly on the order of lookups in the font. Microsoft themselves have been making noises about going to that approach in the future.

I can't say when or where Adobe will support 'locl', but it is very reasonable to assume that we will get there eventually.

T

Chester, this is wrong:

feature ss01 { # Polish Localized Forms
language PLK exclude_dflt; # Polish;
sub @loclPLK1 by @loclPLK2;
} ss01;

Maybe not wrong, but doesn't make much sense. You want the "locl" feature to work in the Polish language context but you want the stylistic set work regardless of the language context.

Here is an example how locl, ss01, ss02 and salt could work for Polish and Romanian localized forms.

# START

# Define classes for substitutions
@loclPLK1 = [Cacute Nacute Oacute Sacute Zacute cacute nacute oacute sacute zacute];
@loclPLK2 = [Cacute.PLK Nacute.PLK Oacute.PLK Sacute.PLK Zacute.PLK cacute.PLK nacute.PLK oacute.PLK sacute.PLK zacute.PLK];
@loclROM1 = [Scedilla scedilla];
@loclROM2 = [Scommaaccent scommaaccent];

# Define locl (Localized Forms) feature
feature locl {
# Latin script, this is optional
script latn;
# Next lookup applies to Romanian language context only
language ROM exclude_dflt;
# Define and implement loclROM lookup
lookup loclROM {
sub @loclROM1 by @loclROM2;
} loclROM;
# Next lookup applies to Polish language context only
language PLK exclude_dflt; # Polish;
# Define and implement loclPLK lookup
lookup loclPLK {
sub @loclPLK1 by @loclPLK2;
} loclPLK;

} locl;

# Define ss01 (Stylistic Set 1) feature for Polish localized forms
feature ss01 {
# Next lookup applies to the default language context only
language dflt;
# Refer to the loclPLK lookup defined earlier
lookup loclPLK;
# The lookup above also applies to the Polish language context
language PLK include_dflt; # Polish;
# The lookup above also applies to the Romanian language context
language ROM include_dflt; # Romanian;
} ss01;

# Define ss02 (Stylistic Set 2) feature for Romanian localized forms
feature ss02 {
# Next lookup applies to the default language context only
language dflt;
# Refer to the loclROM lookup defined earlier
lookup loclROM;
# The lookup above also applies to the Polish language context
language PLK include_dflt; # Polish;
# The lookup above also applies to the Romanian language context
language ROM include_dflt; # Romanian;
} ss02;

# Define salt (Stylistic Alternates) feature for all stylistic substitutions
# This feature defines and implements just one lookup
# that applies to all language contexts
feature salt {
sub @loclROM1 by @loclROM2;
sub @loclPLK1 by @loclPLK2;
} salt;

# END

Regards,
Adam

I’ll note that it would be a wise precaution to order the locl and ccmp lookups in the same order as well, in case one puts the font in some environment that relies strictly on the order of lookups in the font.

Yes, absolutely. The original intent of OpenType was that lookups would be applied in the order in which they occur in the font. The only reason why Microsoft decided to overide this for certain features is the some font developers, who shall remain nameless, were getting the ordering wrong for Indic fonts that require very strict feature processing for correct display.