Strictly speaking, they are language-specific substitutions, which are activated by the language tag. Here's how I'm doing it.

language SRB exclude_dflt; # Serbian
sub afii10066 by be.serb;

Thanks Nick!
It seems not much different than what I did:

feature locl { # Localized Forms
# Latin
language MOL exclude_dflt; # Moldavian
sub [Scedilla scedilla Scedilla.smcp] by [Scommaaccent scommaaccent Scommaaccent.smcp];
language ROM exclude_dflt; # Romanian
sub [Scedilla scedilla Scedilla.smcp] by [Scommaaccent scommaaccent Scommaaccent.smcp];
language SER exclude_dflt; # Serbian
sub @ru2serb by @serbalt;
} locl;

Chris, some of the preferred Serbian forms may also be accepted as stylistic variants for non-Serbian language, including Russian. The Serbian be and italic de are both forms that are found in some Russian typefaces, and could be made available via 'salt' or one of the stylistic set features.

Thanks John! Then having them in both 'locl' and 'salt' would be OK?

Great! I'll do it.

ChrisL

Chris, I believe the language tag is SRB, not SER.
At least that's what was in the online resource I checked; but I didn't keep a record of where it was, and haven't checked back.

AFAIK, in Serbia they would be using a keyboard driver that specified "SRB", and that would activate the features tagged thusly in a font.

Thanks Nick! Glad you caught that! It was a screwup, not a position :-) SER might be an entirely different language.

ChrisL

The keyboard driver is usually unrelated to activating features and does not need to know anything about OT language tags. All it does is pass codepoints in to the OS. The OS or application needs to tag the text with the appopriate language. The OS or app could derive the language from the keyboard selection, but what then about cases where a single keyboard can be used for multiple languages? Or text is imported or copied and pasted from some other source?

Some applications may try to derive the script and/or language from the particular codepoints being used. This is obviously prone to error, particularly if it's language rather than script that is driving the processing.

So the most reliable method is to have the end user needs specify the language. InDesign CS3 relies on this; when the end user specifies the language for spelling and hyphenation purposes, that also serves to tell InDesign what language tag applies.

The downside of InDesign CS3's approach is that currently users can't specify a language they don't have a dictionary for. I hope to see this limitation removed in a future version of InDesign. But for now I'm pretty glad to have language-specific OT feature processing.

Regards,

T

"The downside of InDesign CS3’s approach is that currently users can’t specify a language they don’t have a dictionary for. "

Is a stop-gap measure possible where more dictionairies could be produced? I don't know if it would be quicker to add more dictionaries than to wait for CS4?

ChrisL

So is it a good idea to also produce a "plain" language-specific version of fonts for Serbia or Bulgaria, for users there who aren't using CS3? Such fonts would have the "alternate" glyphs at the standard code points.

Thomas, does CS3 have a Bulgarian dictionary?

language system tag

does CS3 have a Bulgarian dictionary?

or, a better question: can we find a list of what dictionaries DO ship with InD CS3?

My [InDesign CS3] installation lists these. I think that's all.

Is making a dictionary difficult and once made, is it easy to install without recoding InD?
ChrisL

Adding language/hyphenation dictionaries to InDesign

And here's the list for InDesign CS2.

There was a bug in CS2 that made adding the exception dictionary to a document unworkable -- we did send in a bug report, but Adobe doesn't acknowledge them as policy, so we have no way of knowing what the final disposition was. Has this been fixed in CS3? If not, then you can only have an "application" exception dictionary. This means if there are variables for a particular job, you have to change the dictionary, write it off, save it with the job, & reinstall it in the system for each job when proof comes back.

Since the bug occurred with differences in word endings following an apostrophe (OK with one letter following the apostrophe, not OK with more than one letter), this may or may not affect some of these languages.

Thanks Miguel, that's very impressive.

Are there font ramifications for the variants in English, French, Norwegian, German and Portuguese?

I note there is no Moldavian dictionary, despite the Moldavian tags in Adobe Pro fonts.