Creating dialect-specific alternates in opentype font?

dezcom's picture

When creating dialect-specific alternates in an opentype font, is the locl feature the only one that needs to be addressed? I have 5 serbian alternates to Cyrillic glyphs. I thought they might also be part of aalt or salt as well. I made a couple of small classes and made subs by class. Is there a “better” way to do this?


Nick Shinn's picture

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;

dezcom's picture

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;

John Hudson's picture

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.

dezcom's picture

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

Great! I'll do it.


Nick Shinn's picture

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.

dezcom's picture

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


Thomas Phinney's picture

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.



dezcom's picture

"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?


Nick Shinn's picture

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?

paul d hunt's picture

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?

Miguel Sousa's picture

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

dezcom's picture

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

Miguel Sousa's picture

And here's the list for InDesign CS2.

charles ellertson's picture

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.

Nick Shinn's picture

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.

Syndicate content Syndicate content