Open Type Localisation or Stylistic Alternates ?
Paul Miller
Posts: 273
Whilst studying many fonts with Cyrillic support it became apparent that many fonts do Localisation for Bulgarian Cyrillic and Macedonian/Serbian Cyrillic by using Stylistic Alternates insead of or as well as Open Type Localisation.
The reason which was stated was that Localisation doesn't work in many circumstances and with a lot of software.
I must admit that when I have produced a font I only test the Localisation features very superficially because it is difficult to test.
Does anyone have any experience or information about the Open Type Localisation not working.
What is the best way to do Localisation ?
What is the best way to test Localisation ?
Any opinion, advice or information would be welcome.
The reason which was stated was that Localisation doesn't work in many circumstances and with a lot of software.
I must admit that when I have produced a font I only test the Localisation features very superficially because it is difficult to test.
Does anyone have any experience or information about the Open Type Localisation not working.
What is the best way to do Localisation ?
What is the best way to test Localisation ?
Any opinion, advice or information would be welcome.
Tagged:
0
Comments
-
“Doesn’t work” = not supported yet.
For example, in InDesign there is no default language option for Serbian (or Macedonian). You can only add it by jumping through a number of hoops:
https://blog.typekit.com/2011/11/04/how-to-enable-more-languages-in-indesign-cs5-5/
I use the hackish Method 1 and keep an .inx file that contains a text block with Serbian language applied, and copying that into another document adds the option. So, that’s what I do to prep a document for testing Serbian/Macedonian localization.
Of course, Serbian is complicated by the fact that Serbia is one of the few (only?) countries that considers both Latin and Cyrillic orthography to be equally official, so you have to be sure you’re adding Serbian Cyrillic.
0 -
Paul Miller This is a huge problem and there is not a single decision to it. My personal opinion is that because of lack of quality support for the local features in the applications every font needs both local features and Style Set features for Cyrillic support of the Bulgarian, Serbian and Macedonian forms. For example: if you have quality written Cyrillic local features in your font these features are absolutely useless for the Word costumer. But at the same time starting from version 5.3 the local features are supported in LibreOffice. And vice verse: if you write Bulgarian, Serbian and Macedonian forms as Style Set 1, Style Set 2, Style Set 3 in your font these languages could be supported in Word but not in the LibreOffice. Indesign does support Bulgarian local features but does not support Serbian or Macedonian local features. To write twice in different ways one and the same thing in your fonts really sounds stupid. But for now this is the only one possible decision for me.
You could test the Cyrillic local features here – http://www.cyreal.org/Font-Testing-Page/index-cyrillic.php
0 -
I don't duplicate localisation forms in stylistic sets, since the latter are not supported everywhere either, and since they require user interaction — unlike the <locl> feature, which should be automatically triggered by document language tagging —, they are actually less robust. There are font interchange issues with stylistic sets, since there is no standardisation of those features: they should only be used for design-specific stylistic variant sets, not for something like language-specific forms.
If I know that I need to provide language-specific forms in environments that might not support <locl> or in which I can't rely on documents having accurate language tagging, I make separate fonts. That's really the only robust way in such situations.0 -
I have verified that the localisation works on Kelvinch but I had a wierd e-mail in very bad english from this guy who said that the Serbian localisation didn't work.
Here was me naïvely thinking that this was a function of the operating system and so it would just work based on the location set in the operating system, it seems it is a function of the individual applications.
From now on I will put Localisation in as Stylistic Alternates as well as Open Type Localisation. After all the look up tables already exist so it wouldn't enlarge the font file by very much to use the same lookups in two features rather than just one. And at some point in the future there will be applications which actually be able to use this feature.
0 -
One of the things I aim to get done in my Copious Free Time is to add language tagging to the various texts on Pablo's type testing page. That's working on the basis that browsers will pass the language tags to the shaper and have your fonts shaped appropriately. (I don't know if they do this. Firefox certainly should do it.) That would enable you do to localisation testing much more easily.2
-
@John Hudson If I know that I need to provide language-specific forms in environments that might not support <locl> or in which I can't rely on documents having accurate language tagging, I make separate fonts. That's really the only robust way in such situations.
Well, that is the other possible decision.
0
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 803 Font Technology
- 1K Technique and Theory
- 618 Type Business
- 444 Type Design Critiques
- 542 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 499 Announcements
- 80 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports