Opentype features take a vacation with one font using FL5 Mac

dezcom's picture

I have been working on a typeface called Tovarich which has several opentype features which used to work fine until a few days ago. I can't figure out what I did to screw it up but I must have done something bone-headed.
From within FontLab 5, my features compile properly without complaint. They show up and work as expected in the preview screen. When I output the font as PostScripot flavored OTF, my features vanish in both InDesign and Illustrator CS. There are brackets around the feature names in the menu indicating "nobody home" and the features don't work. For the past few days, I have been trashing my features and redoing them all to no avail. I trashed them and then imported features from one of my other fonts which is working fine but it still does not work! I have trashed my cashe several times, rebooted, resaved the font under a new name and redone the features again all with the same unpleasant result, terminal frustration! What the heck have I done wrong? Why will the exact same feature code work on one font and not another?
I would be tearing my hair out but that ship has long sailed,

Any help would be appreciated,

ChrisL

scruggsdesign's picture

how about trashing your adobefnt files?

dezcom's picture

Josh,

How do I do that?

ChrisL

scruggsdesign's picture

do a search for “adobefnt” it should bring up a bunch of files ending in .lst
sometimes trashing all these files fixes some problems.
I’m on a Mac… don't know if it’s the same on PC.

dezcom's picture

Thanks Josh. I am on a Mac as well.

ChrisL

paul d hunt's picture

are there cyrillic characters in your font?
This thread may address the same problem?

dezcom's picture

Yes, there is a whole Cyrillic set in it. But no Greek this time.

ChrisL

dezcom's picture

I remembered that thread and set only basic Roman with no help. I then added greek but still no help!
My font has CE Latin extended A, Cyrillic with the extended Cyrilic for Baltic. What I don't get is that all my other fonts that I have designed work just fine. It is only this one that baffles me :-/

ChrisL

Christopher Slye's picture

Do you have the language system(s) declared properly? If you only declare

languagesystem DFLT dflt;

you will see no layout features in InDesign CS2 (and earlier, I presume). The DFLT/dflt language system is relatively new, and should work all by itself someday, but for now, some apps don't know about it. For now, you should always include some other language system declaration (and that usually means latn/dflt).

Of course, if you really did import all features from some other font that works, including the language system declarations, then I guess I am stumped.

dezcom's picture

Do I declare the language system in InD or in FontLab? I assume it must be in the Opentype feature in FontLab because I don't know where to find it in InD.

ChrisL

dezcom's picture

Here is my feature code:

feature tnum { #tabular numbers
sub @num by @TNUM;
} tnum;

feature numr { # Numerators
# Latin
sub @num by @numr2;
language AZE ; # Azeri
language CRT ; # Crimean Tatar
language DEU ; # German
language FRA ; # French
language ITA ; # Italian
language MOL ; # Moldavian
language ROM ; # Romanian
language SRB ; # Serbian
language TRK ; # Turkish
script cyrl; # Cyrillic
sub @num by @numr2;
script grek; # Greek
sub @num by @numr2;
} numr;

feature sups {# superior figures
sub @num by @supnum;
sub @infnum by @supnum;
sub @numr2 by @supnum;
sub @dnom1 by @supnum;
} sups;

feature locl { # Localized Forms
# Latin
language MOL exclude_dflt; # Moldavian
sub [Scedilla scedilla] by [Scommaaccent scommaaccent];
language ROM exclude_dflt; # Romanian
sub [Scedilla scedilla] by [Scommaaccent scommaaccent]; } locl;

feature frac { # Fractions
lookup frac1 {
sub one' [slash fraction]' four' by onequarter;
sub one' [slash fraction]' two' by onehalf;
sub three' [slash fraction]' four' by threequarters;
sub one' [slash fraction]' three' by onethird;
sub two' [slash fraction]' three' by twothirds;
sub one' [slash fraction]' eight' by oneeighth;
sub three' [slash fraction]' eight' by threeeighths;
sub five' [slash fraction]' eight' by fiveeighths;
sub seven' [slash fraction]' eight' by seveneighths; } frac1;
} frac;

feature liga { # Standard Ligatures
# Latin
lookup liga1 {
sub f f i by f_f_i;
sub f i by fi;
} liga1;
lookup liga2 {
sub f f l by f_f_l;
sub t t i by t_t_i;
sub f l by fl;
sub f f by f_f;
sub t t by t_t;
sub t i by t_i;
sub T T by T_T;
} liga2;
language TUR exclude_dflt;
lookup liga2;
} liga;

dezcom's picture

I just checked Apples "Pages" and "Keynote" applications. Liga works fine with them but I don't think they support frac anyway. Liga does not work with Adobe aps though :-/

ChrisL

dezcom's picture

Josh,
I tried trashing “adobefnt” but it didn't help.

ChrisL

Christopher Slye's picture

Ah, here we go:

http://typophile.com/node/28277

There's some discussion about languagesystem in there. I forgot that DFLT/dflt is so new that FontLab doesn't yet recognize it (right?), but perhaps the language system tags in general are your problem.

Thomas Phinney's picture

By the way, only delete AdobeFnt*.lst files, not the AdobeFnt.db file (if you have it).

Cheers,

T

Henyk's picture

Some opentype features for cyrillic script which works in AdobeCS for Windows don't works in AdobeCS for MacOSX 10.4.x, f.ex. liga, howewer calt is working...

dezcom's picture

Thanks Christopher, I assume you meant:
"However, in the FDK 2.0, the default script is “DFLT”, so the effect is saying:
script DFLT;
language ROM;

and the only legal language tag for the DFLT script is the ‘dflt’ language.

To get what you want, you should put the lines:
languagesystem DFLT dflt;
languagesystem latn dflt;
languagesystem latn ROM;

at the beginning of the feature file; all features not registered under a specific language will then be registered under these three script/language pairs.

In features where you specify any language or script, you need to spell out all the script language combinations, and explicitly include the appropriate features under each, e.g
script DFLT;
language dflt;
lookup LOOKUP_1 {
… lots of rules
} LOOKUP_1;

script latn;
language ROM;
lookup LOOKUP_1; # reference to the previously defined LOOKUP_1,
# so that it will be included under latn-ROM as well as DFLT-dflt."

I thought that only applied to the Adobe FDK2 tool? Unless you can tell me I need to put something similar in my FontLab5 features?

What is weird is that it only does wrong on this font, not any of the others I've done the same way.

ChrisL

dezcom's picture

Thanks Thomas, I only deleted the .lst files but to no avail.

ChrisL

dezcom's picture

To further fuel the debate, I just loaded my problematic Tovarich font here at the office. I do all my font development at home on a different computer. At home, I have my personal copy od InDesign CS suite. Here at the office, I have the newer CS2. Both home and office computers are Macs running the same system software Mac OS 10.4.8. Both are pre-Intel G5s.
Although the "OSF" icon does not show up on the Tovarich I loaded here at the office, ALL OF MY OTF FEATURES WORK HERE! Again, the for certain difference is that here I am using CS2 instead of CS at home. There may be more to it than that but that is a start. This would all make sense if all my OTF fonts behaved the same way, but they don't. Every other opentype font on my system at home works on the older Adobe CS just fine EXCEPT Tovarich--go figure.
Has Adobe heard any other CS vs. CS2 font issues with opentype?

ChrisL

dezcom's picture

Here is a PNG file showing working OTF features in CS2.

ChrisL

Christopher Slye's picture

I was hoping a FontLab expert would chime in with some guidance about the languagesystem declarations. I am not sure if FontLab allows you to just put those statements in the OpenType panel, or if FontLab is generating its own language system tags using something in the font info.

Try putting the line
languagesystem latn dflt;
in the "global" part of the OpenType panel.

dezcom's picture

Thanks Christopher, I will give it a try.

ChrisL

dezcom's picture

"I was hoping a FontLab expert would chime in with some guidance about the languagesystem declarations."

Me too. Maybe Adam Twardoch will see this thread and set me straight :-)

ChrisL

PS: Have there been any complaints to Adobe about this kind of thing with CS before?

dezcom's picture

Another issue: Now the font has moved down the list to the foreign script area at the bottom, Even though I don't have anything other than basic Latin checked? Is there a fix for this too?

ChrisL

dezcom's picture

Hereis a PNG of the font menu in CS:

ChrisL

twardoch's picture

Chris,

your OpenType code looks like a result of some wild grab-and-paste action, randomly collected from other people’s fonts. In short, your OpenType code doesn’t make any sense at all.

1. In the lower-right part of the OpenType panel, declare *all* the languagesystems that your OT code uses.

You should at any case declare these two:

languagesystem DFLT dflt;
languagesystem latn dflt;

Then, you should declare all the languages that use the Latin script for which you have some special handling. For the Scedilla->Scommaaccent "locl" behavior, declare Moldavian (MOL) and Romanian (ROM). For the special "i" casing and ligature treatment, declare Azeri (AZE), Crimean Tatar (CRT) and Turkish (TRK, *not* TUR!):

languagesystem latn AZE;
languagesystem latn CRT;
languagesystem latn MOL;
languagesystem latn ROM;
languagesystem latn TRK;

If your font includes any Cyrillic glyphs, you should also declare the Cyrillic script:

languagesystem cyrl dflt;

If you want to include special Serbian glyphs in locl, declare Serbian as well:

languagesystem cyrl SRB;

If your font includes any Greek language glyphs (i.e. not mathematical Greek), you should also declare the Greek script:

languagesystem grek dflt;

So your lower-right part of the OpenType panel may look like this:

languagesystem DFLT dflt;
languagesystem latn dflt;
languagesystem latn AZE;
languagesystem latn CRT;
languagesystem latn MOL;
languagesystem latn ROM;
languagesystem latn TRK;
languagesystem cyrl dflt;
languagesystem cyrl SRB;
languagesystem grek dflt;

This provides a map for all the languagesystems that will be included in your font. If a feature definition does not use any exceptions, it will be automatically assigned to all the languagesystems defined there.

If a feature definition defines any exceptional handling for any of the languagesystems, you must enumerate all of these languagesystems once again, inside of the feature definition, and you must specify for each of them the appropriate action (i.e. "exclude_dflt" or "include_dflt" plus some lookups if necessary).

As for "smcp", "c2sc" and "liga" handling of Turkish "i", I recommend using the new Adobe approach. That is,

feature locl { # Localized Forms
script latn;
# Handling of Turkish i
language TRK exclude_dflt;
lookup locl_TRK {
sub [i I.smcp] by [i.TRK Idotaccent.smcp];
# The "i.TRK" glyph should be an identical copy of "i"
} locl_TRK;
language AZE exclude_dflt;
lookup locl_TRK;
language CRT exclude_dflt;
lookup locl_TRK;
# Handling of Romanian Scommaaccent
language ROM exclude_dflt;
lookup locl_ROM {
sub [Scedilla scedilla] by [Scommaaccent scommaaccent];
sub Scedilla.smcp by Scommaaccent.smcp;
} locl_ROM;
language MOL exclude_dflt;
lookup locl_ROM;
} locl;

(You may also want to include the Serbian glyph handling there).

This way, you will avoid the need to deal with "script" and "language" in ANY other OpenType feature definition.

Simply make sure that in the feature definition of "smcp" (or in the appropriate classes), "i" gets replaced by "I.smcp" and "i.TRK" by "Idotaccent.smcp". Of course "dotlessi" should be replaced by "I.smcp" as well.

Regards,
Adam

dezcom's picture

Thanks Adam! I will try and digest all of that in my feeble way :-)

ChrisL

dezcom's picture

Adam,
I did what you suggested and IT WORKED! I knew I had done something boneheaded!
THANKS for figuring it out!

Now I wonder why it works in CS2 messed up as it was originally? Maybe CS2 has a bonehead debugger built right in :-)

ChrisL

Miguel Sousa's picture

Adam, are you sure that the 'exclude_dflt' statements need to be used inside 'locl', as in your example?

AFAIK they don't, because:
1. In 'locl' we want to define language specific behavior, so neither 'script DFLT;' or 'language dflt;' commands should ever be used there, and
2. Since 'language dflt;' is not used, there's no default behavior specified, so there's no reason for using 'exclude_dflt;'.

Am I missing something?

paul d hunt's picture

You should at any case declare these two:

languagesystem DFLT dflt;
languagesystem latn dflt;

Adam, will the DFLT tag cause any problems with the current version of FLS5?

dezcom's picture

"# The “i.TRK” glyph should be an identical copy of “i”"

Not the dotless i Adam? If it is exactly the same, why not just point to the Latin "i"? I am really missing something here. Itmay be that I just don't understand the contexts in Turkish which need a substitution( or lack there of).

ChrisL

dezcom's picture

I think I see it now Adam. If, in Turkish, I substitute "i.trk" for "i" before I apply the liga feature, then the liga feature will only be applied to the Latin i in non-Turkish usage. This would eliminate the repetition of locl exclusions for multiple ligatures.

ChrisL

twardoch's picture

> If, in Turkish, I substitute “i.trk” for “i”
> before I apply the liga feature, then the liga
> feature will only be applied to the Latin i in
> non-Turkish usage. This would eliminate the
> repetition of locl exclusions for multiple
> ligatures.

Exactly. This is the technique Adobe adopted in Garamond Premier Pro and later releases. In "locl", you chage the "identity" of the letter i without changing its appearance, and then the rest of your code is clean and easy, without the necessity of dealing with various exceptions, and without the need to think about it in all the OpenType features you may think of.

> will the DFLT tag cause any problems with the
> current version of FLS5?

Unfortunately, yes. Inside the font file, a script tag " " (four spaces) rather than "DFLT" will be produced. This is an unregistered tag, so I don’t think it will break anything, but it’s not optimal. As soon as we upgrade FontLab Studio to make use of AFDKO 2, the feature syntax will automatically produce the correct result.

A.

paul d hunt's picture

Unfortunately, yes. Inside the font file, a script tag ” ” (four spaces) rather than “DFLT” will be produced.

is this something can be fixed simply with TTX?

can i just replace the line
<ScriptTag value=" "/>
with
<ScriptTag value="DFLT"/>
?

twardoch's picture

Yes. I’ve just compared the output of AFDKO 2 and FontLab Studio 5, and the GSUB table was the same except for that very difference. You can do the replacement manually. But I have just written a Python script that will perform the fix on an arbitrary number of fonts automatically:

http://www.silesian.com/software/FixDFLTScriptTagSL.zip

From the README.TXT:

FixDFLTScriptTagSL 1.0 (061115)

Changes invalid default OT Layout script tag ' ' to 'DFLT'
in all OpenType fonts found in a folder (current or specified).
Keeps a backup copy of the original font file (.bak extension).

Copyright (c) 2006 by Silesian Letters, http://www.silesian.com/
Written in Python 2.4 by Adam Twardoch. FREEWARE.

usage: python FixDFLTScriptTagSL.py [folder]

Requires the Python source version of FontTools/TTX:
http://www.font.org/software/ttx/

The OpenType Layout feature definition statements such as
'languagesystem DFLT dflt;' or 'script DFLT;' errorneously
produce a script tag ' ' instead of the intended 'DFLT'
inside of the font file when the font is produced using
Adobe FDK for OpenType (AFDKO) version 1.6, FontLab 4.x,
or FontLab Studio version up to 5.0.2. Using AFDKO 2.0
produces correct results. This Python script corrects
the errorneous entries in existing OpenType fonts.

Enjoy,
Adam

dezcom's picture

I am assuming your script is for P{C only, correct Adam?

ChrisL

twardoch's picture

The script runs on both Mac OS X and Windows. I have just uploaded a revised version 1.1 of the script to

http://www.silesian.com/software/FixDFLTScriptTagSL.zip

that can run conveniently inside of FontLab Studio 5 as well as from the commandline.

INSTALLATION

1. Make sure you have Python installed.

On Mac OS X 10.4, Python 2.3 is installed by default. It will work fine, but installing Python 2.4 is recommended. On Windows, install Python 2.4 from http://www.python.org/

2. Install the source Python version of FontTools/TTX.

Download and unzip the file
http://fonttools.sourceforge.net/cvs-snapshots/zip/fonttools-current-sna...

Open the Terminal (Mac OS X) or the command-line window (Windows)

Go to the folder where you unzipped FontTools (using the 'cd' command). If you unzipped the file on your Mac OS X Desktop, you will probably need to type in cd Desktop/fontTools. Then, type in, on Mac OS X:

sudo python setup.py install

or on Windows:

python setup.py install

3. To test if the installation was correct, open FontLab Studio 5, open the Edit Macro panel, type in:

import fontTools.ttLib

and click on "Run macro". If an error message appears, your installation of FontTools/TTX failed. If nothing appears, you have a correct installation of the source Python version of FontTools/TTX.

4. Locate your FontLab Studio 5 data folder using Windows Explorer/Finder.

Go to Options/Preferences / General Options / Folders and paths,
and check the "FontLab Studio 5 files" textfield.
If the textfield is empty, and you're on Mac OS X, go to
%yourusername%/Library/Application Support/FontLab/Studio 5/
Otherwise, go to the folder specified in that textfield. This is your FontLab Studio 5 data folder.

5. Inside of your FontLab Studio 5 data folder, there should be a folder named "Macros". If it is not there, create one.

6. Inside of the Macros folder, create a folder named "Silesian".

7. Unzip FixDFLTScriptTagSL.zip and put the file FixDFLTScriptTagSL.py into the Silesian folder.

8. Restart FontLab Studio and in the Macro toolbar, choose Silesian from the Macro folders list, and then choose Fix DFLT OT Script Tags [SL] from the Macro programs list. Click on the Run button.

(It is also possible to run this macro from the commandline outside of FontLab Studio).

William Berkson's picture

Adam, do you have any idea when the version of FontLab with AFDKO 2 incorporated will be released?

twardoch's picture

> do you have any idea when the version of FontLab
> with AFDKO 2 incorporated will be released

We don’t currently have anything to announce about this.

A.

dezcom's picture

Thanks for the update Adam!

ChrisL

Miguel Sousa's picture

Adam, what about my question ?

twardoch's picture

Miguel,

you are right, it’s not necessary but it doesn’t harm -- the output is identical. I like to include it just to make sure just for the sake of good coding practice and consistency. Whenever I write code, I like to make sure that my snippets are always "cut-and-pastable" without paying attention to modality/context too much. I prefer explicit vs. implied, so I always specify either the "exclude_dflt" or the "include_dlft" statement whenever I do language-specific processing.

Indeed, in "locl", there usually is no "language dflt" statement so the exclude_dflt statement is not required. However, had this kind of processing been done in a different feature, one would need to use exclude_dflt, so I simply include it as a means to make sure that I know where I am.

A.

rcc's picture

Also, for whatever it may be worth, in the PDF of slides used for Christopher Slye's talk on OpenType feature files (at the ATypI 2006 Lisbon conference) one finds this snippet:

Saving the i-dot

feature liga {
script DFLT;
language dflt;
sub f i by f_i;
script latn;
language dflt include_dflt;
language TRK exclude_dflt;
} liga;

Said PDF is available at:
http://blogs.adobe.com/typblography/atypi2006/slye_lisbon-05.pdf

Seems to me it can't hurt.

dezcom's picture

@RC--Thanks for posting that! The pdf of Christopher's presentation is something I wish I had seen before.

@Christopher Slye--Your pdf goes a long way in showing the "why" and "how: of feature code. Prior to this, I was just trying to decipher what I had seen and make some sense of it. As you can see from my code above, I was fishing in the dark and trying to teach myself how to do it (a blind-man fishing in the dark). I also didn't realize until now that you worked for Adobe, the collective pronouns you used now make sense to me :-) a very big THANK YOU for your help! The fog is starting to lift and I can now at least see the water :-)

@Punchcut gang--What a wonderful place Typophile is to get real help and expert Advice from people like Christopher, Adam, Miguel, and Paul. KEEP UP THE GOOD WORK!

ChrisL

twardoch's picture

rcc,

you don’t need to do this kind of treatment if your "locl" feature replaced i with i.TRK for Turkish.

A.

dezcom's picture

One of the other slides in Christopher's presentation shows the "i.dot" solution Adam mentioned.

ChrisL

rcc's picture

you don't need to do this kind of treatment if your "locl" feature replaced i with i.TRK for Turkish.

Adam,

Right... I suspected someone might call me on this bit. (Mere newcomer's angst, that?)

However, being mindful of the current scarcity of 'locl' support and suchlike, I raised the issue for its 'belt-and-braces' potential, reckoning thus: if one as-yet-unimplemented feature doesn't execute the intended substitution, the other one ought to do so, yes? And later, if one projects a few months/years down the chronological road, such coding redundancies ought to be smoothly ignored when applications do in fact support the anticipated feature(s). (Though by that time, one would likely wish to amend and update one's feature code and issue revised versions anyway.)

Or is that dreadfully wrongheaded? What, if one can state them, are 'best practices' on such issues? Wiser counsel won't be disregarded.

Thank you.

twardoch's picture

rcc,

in theory, you’re right. It is possible that an OpenType Layout engine would do language-sensitive OpenType processing (i.e. process OpenType features assigned to languages other than "dflt"), but it would not automatically apply the "locl" feature. But this is *very* unlikely. Currently, major applications do not use the language-sensitive processing. Adobe applications currenly only apply features assigned to "latn dflt" while Microsoft applications apply features for complex scripts assigned to the dflt language in the respective scripts (arab, hebr etc.).

Especially for the non-complex scripts, I think it is safe to assume that if an application processes language-sensitive lookups, it will also apply "locl".

Regards,
Adam

rcc's picture

Thanks for the additional insight, Adam. It's truly appreciated.

Best,
rcc

Arno Enslin's picture

@ Adam

lookup locl_TRK {
sub [i I.smcp] by [i.TRK Idotaccent.smcp];

Even in Turkish it should be allowed to set an dotless I.smcp. Your code requires an additional character "dotlessi.smcp".

In http://typophile.com/node/69063 I propose to either keep the font absolutely symmetrically with regard to dotlessi and i or to break the symmetry of the dotlessi.

E I T H E R
Dotlessi, Dotlessi.smcp, dotlessi, Idotaccent, Idotaccent.smcp, idotaccent, I, I.smcp and i. (Please, symmetrie also with regard to the names – not i.trk and Idotaccent or idotaccent and I.trk!)

O R
same as above, but without Dotlessi and without Dotlessi.smcp

-------------------

Everyone is cooking his own soup there. In Athelas (TypeTogether) only i.smcp is substituted by idotaccent.smcp in the locl feature, but not i by idotaccent.

twardoch's picture

Arno,

“Dotlessi” and “idotaccent” are not PDF-compatible glyphnames. They resolve to an unknown character. Instead of “idotaccent”, Adobe recommends using “i” with any suffix (after a dot), and FontLab recommends “i.TRK”, specifically.

I’m not sure what you mean by “symmetry in glyphnames”. Adobe and FontLab publish extensive guidelines on glyphname naming, and there is nothing in there about symmetry. The fact that the name “Aacute” is used for the glyph which represents the Unicode character U+00C1 (Á, LATIN CAPITAL LETTER A WITH ACUTE), and “aacute” is used for U+00E1 (á, LATIN SMALL LETTER A WITH ACUTE).

As it happens, “Aacute” is the uppercase variant of “aacute” does not mean that all uppercase variants have the same glyphname as the lowercase letters except that the first letter of the glyphname is uppercase. The fact that it works for some glyphnames is just incidental.

The glyphname for the character U+01F5 (ǵ, LATIN SMALL LETTER G WITH ACUTE) is “uni01F5”, but the glyphname for its uppercase counterpart, U+01F4 (Ǵ, LATIN CAPITAL LETTER G WITH ACUTE) is *not* “Uni01F5” but is “uni01F6”.

The glyphname “Idotaccent” is used for the character U+0130 (İ, LATIN CAPITAL LETTER I WITH DOT ABOVE), and the glyphname “I” is used for the character U+0049 (I, LATIN CAPITAL LETTER I). The lowercase variant for both of them is U+0069 (i, LATIN SMALL LETTER I). There is no LATIN SMALL LETTER I WITH DOT ABOVE in Unicode, and the name “idotaccent” doesn’t mean anything. It may look “pretty” according to your symmetry rules, but it doesn’t work.

Same thing for “dotlessi”. It’s a glyphname for U+0131 (ı, LATIN SMALL LETTER DOTLESS I) but its uppercase counterpart is U+0049 (I, LATIN CAPITAL LETTER I). There is no LATIN CAPITAL LETTER DOTLESS I in Unicode, so there is no such thing as “Dotlessi”.

Of course everyone is cooking his own soup. But some people’s soup may contribute to a stomach pain. Font developers are free to use invented, non-PDF-compatible glyphnames — but this will result in less usable fonts. PDFs produced with such glyphnames may not be searchable, and copy-paste may not work properly.

We at Fontlab Ltd. agree with Adobe that it’s a good idea to duplicate the small cap glyphs, though we recommend naming the glyphs “A.c2sc” and “a.smcp”, which makes clear what their purpose is. Since PDF applications often need to parsing glyphnames to recreate the original text string (when searching or copy-pasting), keeping separate glyphname prefixes for glyphs that semantically represent uppercase or lowercase letters allows better text accessibility.

PDF readers will know that “A.c2sc” stands for a smallcap version of the “A” character, while “a.smcp” stands for a smallcap version of the “a” character. This way, copy-paste and searching will still work properly even if the text is set in smallcaps.

This is the code that I recommend using:

# This goes into the lower-right section of the FLS OpenType panel.

languagesystem DFLT dflt;
languagesystem latn dflt;
languagesystem latn AZE;
languagesystem latn TRK;

# This goes into the features list in the FLS OpenType panel.

feature locl {
language TRK;
sub i by i.TRK;
language AZE;
} locl;

feature c2sc {
sub I by I.c2sc;
sub Idotaccent by Idotaccent.smcp;
} c2sc;

feature smcp {
sub i by i.smcp;
sub i.TRK by i.TRK.smcp;
sub dotlessi by dotlessi.smcp;
} smcp;

This requires the following glyphs to be present in the font: “I”, “Idotaccent”, “i”, “i.TRK”, “dotlessi”, “I.c2sc”, “Idotaccent.c2sc”, “i.smcp”, “i.TRK.smcp”, “dotlessi.smcp”.

The feature code above presumes that the “locl” lookups are written before the “smcp” lookups. If you put “locl” after “smcp”, then the “locl” would need to exchange the smallcap glyphs. But this makes less sense: the “locl” lookup for Turkish should be defined early in the font because it should influence other features such as “liga”.

Sure thing however, every font vendor is free to make fonts that don’t work. ;)

A.

Ps. I’m including a link to the related discussion:
http://typophile.com/node/69063#comment-404694

Syndicate content Syndicate content