how about trashing your adobefnt files?

Josh,

How do I do that?

ChrisL

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.

Thanks Josh. I am on a Mac as well.

ChrisL

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

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

ChrisL

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

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.

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

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;

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

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

ChrisL

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.

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

Cheers,

T

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...

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

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

ChrisL

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

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

ChrisL

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.

Thanks Christopher, I will give it a try.

ChrisL

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

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

Hereis a PNG of the font menu in CS:

ChrisL

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

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

ChrisL

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

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?

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?

”# 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

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

> 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.

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

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

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

ChrisL

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).

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

> 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.

Thanks for the update Adam!

ChrisL

Adam, what about my question ?

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.

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.

@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

rcc,

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

A.

One of the other slides in Christopher’s presentation shows the “i.dot” solution Adam mentioned.

ChrisL

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.

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

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

Best,
rcc