What font is it?

I don’t think it’s a font problem, because it behaves correctly in the CS2 applications.

I suspect that ...

It is a font problem.
The (FLS) font's feature definition lacks (some of) the initial languagesystem statements. But in 'liga' (and possibly in 'smcp') however, certain lookups are registered for specific languages (e.g. 'DEU' and 'TRK'). This has the effect that after feature compilation only 'liga' (and possibly 'smcp') are registered e.g. for the German language ('DEU').
Default numerals in the font are lining numerals.
While InDesign CS2 and earlier ignored script and language tags, InDesign CS3 does read them. If a user applies the German dictionary, InDesign CS3 will look for features registered for German and only find the 'liga' feature: as an effect, 'Ligatures' will work, but 'Proportional Oldstyle' numerals won't have any effect, hence the (default) lining numerals.

Solution:

Adam Twardoch described what to do:
http://typophile.com/node/17787
(See the three "discussion" links, especially the AFDKO thread!)

A must-read is this:
Christopher Slye's presentation for the ATypI Lisbon Conference. Download "OpenType feature files" from Thomas Phinney's Typblography. (Direct link to the PDF.)

If fonts with the additional languagesystem statements in the feature code are generated with AFDKO2, all is fine.
If you generate such fonts in FontLab Studio 5, there will be an error message. You can ignore this, but you need to run the generated .otf fonts through Adam Twardoch's Fix DFLT Script Tag script which can be downloaded here:
http://www.silesian.com/software/FixDFLTScriptTagSL.zip
(Requires TTX, see the README.TXT.)

[My impression is that there are many fonts out there which share the defect described above.]

Karsten

> The (FLS) font’s feature definition lacks
> (some of) the initial languagesystem statements.

I'd like to emphasize the importance of this -- whenever you are using ANY language-specific OpenType substitutions (e.g. in the "liga" or "locl" features) or whenever your font contains letters from more than just the Latin script (e.g. Cyrillic or alphabetic Greek), you need to enumerate all the languagesystems as I explained here. This is not any limitation of FontLab Studio, simply a prerequisite of the format. FontLab Studio does not do it magically for you, but it does not automatically generate any OpenType code either (except the example code for Type 1 Standard-encoded fonts, but that is Latin only, anyway).

Also, I'd like to point out that there is no *obligation* whatsoever to include the DFLT script tag in OpenType fonts. Adobe does this in their newest fonts but did not in the older fonts, and Microsoft does not use the DFLT script tag at all (and as far as I can tell, they have no intention to).

Adam

Thanks, Adam!

ChrisL

Indeed: when i change the dictionary in InDesign CS3 to English, the font behaves as it should. So it must be what Karsten and Adam are pointing out. Thanks for that!

Thanks Karsten -- well understood & described.

If fonts with the additional languagesystem statements in the feature code are generated with AFDKO2, all is fine.
If you generate such fonts in FontLab Studio 5, there will be an error message. You can ignore this, but you need to run the generated .otf fonts through Adam Twardoch’s Fix DFLT Script Tag script

I've built all the feature files as per Adam's instructions, but I don't use AFDKO (I can't install it and don't understand Python, they're a bit beyond my code comprehension limit).

So will the language features in a font work properly without the line:
languagesystem DFLT dflt;

Unless I can figure out how to use AFDKO and Python scripting, would I be better off to make features language-specific the old way, feature, by feature?

> but I don’t use AFDKO (I can’t install it

I've just posted installation instructions on the wiki. Check them out: AFDKO

> Unless I can figure out how to use AFDKO

Once you have the tools installed and running, try building a font using the files contained in the 'ExampleRomanFonts.zip' file, which you can grab from the FDK download page. If you can build this one, you're all set.

I also suggest reading the documentation inside the FDK, particularly the 'MakeOTFUserGuide.pdf' and 'CommandLineHowTo.pdf' files.
And these two other PDFs should help you understand how to use the tools:
http://blogs.adobe.com/typblography/typotechnica2007/TypoTechnica2007_Fo...
http://blogs.adobe.com/typblography/typotechnica2007/TypoTechnica2007_St...

Thanks Miguel, I'll give it another shot.

***

No difference--I just get this, which is completely incomprehensible to me:

[Nicks-iMac:~] nick% /Applications/FontLab\ Studio/FDK.1/FinishInstallOSX

Adding a symbolic link from '/Users/nick/bin' to the FDK directory /Applications/FontLab Studio/FDK.1.

Adding the FDK path to your login file...
I added some lines to the startup file /Users/nick/.login for the tcsh/csh versions of the Terminal program, in order to add the 'FDK/Tools/osx' directory to your PATH environment variable.
I added some lines to the startup file /Users/nick/.profile for the bash/csh/zsh versions of the Terminal program, in order to add the 'FDK/Tools/osx' directory to your PATH environment variable.
If you cannot run the FDK tools by name from the command-line after closing this window, then your
Terminal program may be using a different login file than the ones I modified.
If so, you will need to identify your login file, and then add the same two lines to that file.

Nick,

i am also quite ignorant of the Python thing, but after reading the ’CommandLineHowTo.pdf’i managed to get a step further. Important is the following procedure as described in the PDF:

To change the prompt, you need to edit an obscure file that sets parameters for the Terminal program when it starts up. Unfortunately, the way the Terminal program works depends on which Unix command line program it is setup to use. There are several, and each one uses a different name for its startup file, and requires a different line of text added to change the prompt. To see which one you have, under the Terminal menu option, choose “Preferences…”, and note the line of text in the top text field.
Program name Startup file name Line to add
csh .cshrc set prompt="%c$ "
tcsh .cshrc set prompt="%c$ "
sh .profile PS1='\W $ '
zsh .profile PS1='\W $ '
bash .bash_profile PS1='\W $ '

Notes: the quotes need to be included, and must be either both single or both double quotes. For sh, zsh, and bash, there must be no spaces on either side of the equals sign. You can use any character string you want for the final prompt characters instead of "$ ". I like to have a space at the end of the prompt.
Look in your home directory. Unfortunately, files that begin with a period are hidden in the Finder.
To make them visible, open a Terminal window and type the following command:
defaults write com.apple.finder AppleShowAllFiles TRUE
Close all Finder windows, switch to another program, and then switch back to the Finder, and you will be able to see the hidden files. To hide the files once you are done, enter the command line:
defaults write com.apple.finder AppleShowAllFiles FALSE
If there is no file with the name you need, use a text editor to create it. Add the appropriate line (right column), and save it in your home directory. Close the Terminal window and open a new one.
Now the prompt should just show your current directory and a dollar sign, rather than the full path to the current directory.

After creating a file .bash_profile/PS1='\W $ ' i was able to install AFDKO and it appears in FontLab’s Menue Tools/External Tools.
Hope that helps a bit.

Thanks Juergen, I didn't realise that the "CommandLineHowTo.pdf" would explain how Terminal worked.

I'll give it another go...

Don't really want to hijack this thread even further, but ...

Are there any Windows specific tips/instructions that are clearer & more "task oriented" than the FDK documentation? Sorry, but sometimes it reads like "if you're on Windows do x, but on a Mac do y, then z, and by the way there's this too" and Lord only knows what platform we're talking about after a few more phrases.

Maybe I'm way too dense, but I think some straightforward Jack-hits-the-ball prose would be more beneficial.

Thanks for the assistance.
Rob

P.S. If it matters: using FLS5 on Windows 2000 SP4 with the OS on initial partition, applications on second, data on a third. (Honest. It's weird but it works. And much less fragmentation to fret about as well.) Currently, FLS5 and Python play well together & the previous FDK worked like a charm (miss that GUI, no matter how clunky it looked), but the new edition just falls over dead for me.

> No difference—I just get this

That's the normal output upon installation. What I'd like to know is, what do you get after going through these steps:
1. Open a Terminal window
2. Type autohint -u
3. Hit 'Return'

Do you get something like this below? If so, your installation was successful.

Imported Py23AC v.2.0.1 from /Users/nick/FDK/Tools/osx/FDK.app/Contents/Resources/Python/lib-dynload/Py23AC.so.

autohint AutoHinting program v1.14 Jan 3 2007
autohint -h
autohint -u
autohint [-g ] [-gf ] [-cf path] [-a] [-r] [-q] [-c] [-nf] [-ns] [-nb] [-o ] font-path

Auto-hinting program for PostScript and OpenType/CFF fonts.
Copyright (c) 2006 Adobe Systems Incorporated

Rob, I'm not familiar with using or installing the FDK on Windows, but I can try to put up on the wiki a step-by-step installation guide, if that helps.

Thanks, Miguel. Your assistance is very much appreciated. (BTW, can't wait to put your class kerning script to work.)

Rob

Nick -- So will the language features in a font work properly without the line:
    languagesystem DFLT dflt;

Yes. This is what Adam meant when he wrote this:
Also, I'd like to point out that there is no *obligation* whatsoever to include the DFLT script tag in OpenType fonts. Adobe does this in their newest fonts but did not in the older fonts, and Microsoft does not use the DFLT script tag at all (and as far as I can tell, they have no intention to). [Quote from Adam's post above.]

Nick --Unless I can figure out how to use AFDKO and Python scripting, would I be better off to make features language-specific the old way, feature, by feature?

I am not sure what you mean by "the old way". If you mean: "without using any languagesystem statements", then no since this would produce mal-functioning fonts. If you mean: "as described in Read Roberts' / Adam Twardoch's posts [links in earlier post] but without the DFLT script tag", then yes. With or without 'DFLT', it is important that your feature definitions are preceded by statements like
    languagesystem latn dflt;
Put a bit differently: Go though all your features and pick all script and language tags you have used, and add according languagesystem statements (by this pattern: "languagesystem" + script tag + language tag + ";") at the top of your feature definitions (in FLS: into the bottom right text field in the OT Panel).
You do not need to add scripts/languages that you did not mention in any feature.

    * * *

Mr Davidson: In the AFDKO's installation readme file, it seems that for Windows, only the bulleted paragraph starting "Under Windows, move ..." is of interest. And for installing the FLS Macros, the one starting "To install the FontLab Macros ..."
I am an ignorant when it comes to Windows, but with this description even managed to set the environment variables.  :)

    * * *

I was reminded that the 'Generate Kern Feature' script requires RoboFab. Some updated links: RoboFab

what do you get after going through these steps:

command not found

My problem is that I can't get Terminal to work, despite spending many hours with "CommandLineHowTo.pdf".

For instance, consider what happens when I'm instructed to "save it in your home directory". On the assumption that my "home directory" is the one with the cute icon of a house, I put the file cshrc/set prompt=”%c$ in there, but then when I open Terminal, I get the message tcsh: Missing }. So where should I put this "prompt" file?

With or without ’DFLT’,

This is the thing that confuses me.
In the instructions of both Adam's wiki and Chris Slye's pdf, they say that the first line in the bottom right FLS panel should be:
languagesystem DFLT dflt;

But you say,

If you generate such fonts in FontLab Studio 5, there will be an error message. You can ignore this, but you need to run the generated .otf fonts through Adam Twardoch’s Fix DFLT Script Tag script

If I can ignore this, why do I still need to run the fonts through a "Fix" script?

Well, if you ignore the error, you'll end up with a font that has some substitutions assigned to an unregistered script. It's not tragic but not anywhere near reasonable either.

A.

Ah, I see. Indeed it's a confusing with all these ifs.

When generating fonts directly from FLS, there are these two options:
(1) You completely omit the line "languagesystem DFLT dflt;".
(2) You include this line (and ignore FontLab Studio's error message) and also run the generated font through Adam's script. This means: you accept the error only because you are going to correct it.

When generating fonts via AFDKO 2 (which also means that your features are in external files) you can include this line without any extra work because AFDKO 2 can deal with it.

Karsten

OK, if I omit the line "languagesystem DFLT dflt;", how does that effect the font?
Does it mean I have to specify the scripts for every feature, i.e.

script grek;
script latn;
script cyrl;

...and repeat the feature code under each?

This is my Terminal setup.

Try this:
1. Open a Terminal window

2. Type pwd and hit 'return'. This prints the working directory you're in. If this is not /Users/nick, type cd /Users/nick and hit 'return', otherwise go to the next step.

3. Type ls -al and hit 'return'. This prints the list of files and folders in the current directory. You should see a file named .login and another named .profile . Even if you don't have one or both of these files, proceed to the next step.

4. Type pico .login and hit 'return'. This opens up the .login file in pico, a Unix text editor. You should have 3 lines that look like this:
# Initialization for FDK command line tools.
setenv FDK_EXE "/Users/nick/bin/FDK/Tools/osx"
setenv PATH ${PATH}:"/Users/nick/bin/FDK/Tools/osx"
If you don't, just copy&paste them, WriteOut the file (Ctrl+O) and Exit (Ctrl+W).

5. Type pico .profile and hit 'return'. You should see these lines:
PS1="\W\$ "
set -a # automatically export all variables.
# Initialization for FDK command line tools.
FDK_EXE="/Users/nick/bin/FDK/Tools/osx"
PATH=${PATH}:"/Users/nick/bin/FDK/Tools/osx"
If the .profile file does not have the lines above, paste them in, write out the file and exit pico.

6. Close the Terminal window

That should be it. Let us know if it's finally working.

Nick, if you omit the line languagesystem DFLT dflt; the fonts will still work. The difference is that the DFLT/dflt combo will no longer be the default languagesystem. The default languagesystem will be latn/dflt instead. Below is a portion of code written with and without DFLT/dflt.

#####################
###### NEW WAY ######

languagesystem DFLT dflt;

languagesystem latn dflt;
   languagesystem latn DEU;
   languagesystem latn TRK;

languagesystem cyrl dflt;
   languagesystem cyrl SRB;

languagesystem grek dflt;

feature dlig {
   script DFLT;
      language dflt;
         lookup DLIG_DFLT {
            sub c t by c_t;
            sub s p by s_p;
            sub s t by s_t;
         } DLIG_DFLT;

   script latn;
      language dflt;
         lookup DLIG_DFLT;

      language TRK include_dflt;

      language DEU include_dflt;
         sub c h by c_h;
         sub c k by c_k;

   script cyrl;
      language dflt;
         lookup DLIG_DFLT;

      language SRB include_dflt;

   script grek;
      language dflt;
         lookup DLIG_DFLT;
} dlig;

feature hist {
   sub s by longs;
} hist;

#####################
###### OLD WAY ######

languagesystem latn dflt;
   languagesystem latn DEU;
   languagesystem latn TRK;

languagesystem cyrl dflt;
   languagesystem cyrl SRB;

languagesystem grek dflt;

feature dlig {
   script latn;
      language dflt;
         lookup DLIG_DFLT {
            sub c t by c_t;
            sub s p by s_p;
            sub s t by s_t;
         } DLIG_DFLT;

      language TRK include_dflt;

      language DEU include_dflt;
         sub c h by c_h;
         sub c k by c_k;

   script cyrl;
      language dflt;
         lookup DLIG_DFLT;

      language SRB include_dflt;

   script grek;
      language dflt;
         lookup DLIG_DFLT;
} dlig;

feature hist {
   sub s by longs;
} hist;

> Does it mean I have to specify the scripts for every feature

If you want a feature to have the same behavior in all the scripts and languages, just put plain/naked 'sub' commands in that feature. See 'hist' above.

If you want a language to have a different behavior in particular feature, you'll need to declare which languages do what*. In the example above, all languages have the same behavior in 'dlig' — described in the DLIG_DFLT lookup—, except German. German will inherit all the substitutions from the DLIG_DFLT lookup, but will have 2 additional substitutions.

If you test such font in InDesign CS3 you'll see that the c_h and c_k ligatures will only kick-in when the language is German and Discretionary Ligatures is turned on.

* Big warning: whenever you specify a particular behavior for one language, you'll have to specify the behavior for *all* the other languages declared upstream in the 'languagesystem' lines. Failing to do so will result in a crippled feature where only that one language will have lookups implemented.

/track/

In FontLab Studio, you put the languagesystem declarations in the bottom-right portion of the OpenType panel. The languagesystem declarations apply to all features EXCEPT those that have explicitly defined script and language declarations inside of feature definitions. In other words, the languagesystem list sets up the rules for all features while script and language set up exceptions for single features.

If your font only contains text letters from the Latin alphabet plus analphabetics, and it does not use any language exceptions, then you can omit the languagesystem declaration. If you use any exceptions (e.g. for Turkish f-ligatures) or if your font has Cyrillic or Greek text letters (or letters from other scripts), then you have to specify all necessary languagesystem entries. Otherwise, your font won't work properly in InDesign CS3 (although it may have worked OK in InDesign CS and CS2).

Adam

Thanks, Adam. That makes it clearer to me. It helps because I was doing fine untill the CS3 upgrade and wondered why suddenly, my Russian text would not kern unless I used the English H&J dictionary, it's Greek to me :-)

ChrisL

Rob, I've updated the AFDKO wiki entry to include instructions for Windows XP.
As for the Kern Feature Generator script you'll need to have Robofab installed. I'm planning to remove that dependency in the next version (thanks Karsten!)

If your font only contains text letters from the Latin alphabet plus analphabetics, and it does not use any language exceptions, then you can omit the languagesystem declaration. If you use any exceptions (e.g. for Turkish f-ligatures) or if your font has Cyrillic or Greek text letters (or letters from other scripts), then you have to specify all necessary languagesystem entries. Otherwise, your font won’t work properly in InDesign CS3 (although it may have worked OK in InDesign CS and CS2).

Now I'm getting worried. You mean my OT fonts that include Greek, but no language tags, might not work in CS3? Does CS3 take a look at the Unicode and say "Ah, Ha! those characters are in the Greek range, but there is no Greek declaration in this font. Therefore, I'm not going to set those characters!" or some such?

We don't use language tags, period. But we do occasionally set text with some Greek and Cyrillic. If CS3 requires language tags to honor characters or features (with no language declaration), we're in trouble.

Thanks, Miguel, that really did the trick for me & AFDKO works like a charm (... well, in initial tests anyway). I was puzzled because Python scripts and Robofab were already working fine for me, but the hitch turned out to be some duplicated references and resorting the sequence of the PATH statement. (Seems a Perl interpreter installation scrambled a few registry entries too that I hadn't noticed. Grrrr. I have given myself an appropriate dopeslap for overlooking that potential earlier.)

So, in sum: Thanks again for I am once again "a happy camper," so to speak. And now to test that Kern Feature script during the weekend...

Charles & others,

the OpenType specification prescribes that the text is dissected into "runs", i.e. portions that contain characters in a certain script (writing system, alphabet). OpenType Layout features are always registered in specific scripts (Latin, Cyrillic, Greek, Arabic, Hebrew etc., there is also a more recent "default script" registered by Adobe).

The mechanism has been described by John Hudson in his seminal article "Windows Glyph Processing: an OpenType Primer" as early as seven years ago. It is the first article mentioned in the "Developing fonts" section on the Microsoft Typography website, so it's hard to think of a more prominent placement -- see [1].

In a complete implementation of OpenType Layout, the features registered under the Latin script are applied to Latin letters, the features registered under the Cyrillic script are applied to Cyrillic letters etc. For non-alphabetic characters, the features that are applied to them need to be registered under all scripts that the font supports. In addition, they may be registered under the DFLT script so e.g. oldstyle numbers of a certain font can be used with Arabic text even though the font does not support Arabic.

Microsoft Uniscribe is a quite complete implementation of OpenType Layout, and has been for many years. In Windows Notepad, if complex script processing is enabled on the system, certain OpenType Layout features are applied by default to scripts such as Latin, Cyrillic or Greek (ccmp, liga, clig, mark, mkmk, kern -- see [2] -- also also calt). Cyrillic ligatures will be applied only if they are registered under the cyrl script.

Adobe InDesign CS3 is also a quite complete implementation of OpenType Layout, and follows the same principles. Unlike Uniscribe, it does not offer support for complex scripts, but on the other hand it offers support for non-default languages for the standard scripts (e.g. you can use the Turkish language exclusions for the Latin script), something that Uniscribe only offers in theory (as there are no Microsoft applications that use that for the standard scripts).

Adobe InDesign CS2 and earlier versions had a SIMPLISTIC implementation of OpenType Layout, which did not dissect the text into runs but instead, it blindly applied OpenType Layout features registered to the Latin script on all text, regardless of the actual script of the text. It was unfortunate that Adobe chose this path at the beginning, but this problem has been discussed frequently on Typophile as well as on the OpenType list. Another side-effect of Adobe's simplification policy was that if you don't specify any languagesystems (i.e. scripts and optionally languages) for the OpenType font in the AFDKO feature syntax (used by AFDKO, FontLab Studio and DTL FontMaster), all features will be by default registered under Latin script, default language. This is explicitly specified -- see [3] -- but I guess some people have implied from this that they don't need to worry about languagesystems at all. Well, actually, they DO, if their fonts have any alphabetic characters from scripts other than Latin (I say "alphabetic characters" because there are many fonts that don't have real Greek alphabetic characters but have a handful of Greek symbols -- these do not fall under the considerations described here as they are treated as "common script" analphabetics).

So, if an OpenType font has Cyrillic or Greek letters but its OpenType Layout code registered the features only in the Latin script, then the basic functionality of the font will still work (e.g. you will be able to type letters) but no OpenType Layout features will work (not even kerning).

There are OpenType font technology consultants out there (wink wink ;) ) who are able to help you out in details, you know.

Regards,
Adam

[1] http://www.microsoft.com/typography/DevArticles.mspx
[2] http://www.microsoft.com/typography/OpenType%20Dev/standard/intro.mspx
[3] http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html

Thanks Miguel, I think I have AFDKO installed -- at least, the "autohint" test works OK now.

**

In the above "NEW WAY" code you posted, FontLab tells me that it's a mistake to specify "script latn;" as "script DFLT;" has already determined latin as the script--

feature dlig {
script DFLT;
language dflt;
lookup DLIG_DFLT {
sub c t by c_t;
sub s p by s_p;
sub s t by s_t;
} DLIG_DFLT;

script latn;

> I think I have AFDKO installed — at least, the “autohint” test works OK now.

Glad to hear that, as I was running out of suggestions for your problem.

> FontLab tells me that it’s a mistake to specify “script latn;” as “script DFLT;”

As it was said around here many many times before, FontLab still uses v1.6 of the FDK and therefore it gives an error when script DFLT is used.

I can assure you that the code posted above will compile (and work as expected in InDesign CS3) if you use FDK v2.0, since that's essentially the same code that was used for Arno Pro.

Why VOLT won't accept -- languagesystem DFLT

Adam: Also, I’d like to point out that there is no *obligation* whatsoever to include the DFLT script tag in OpenType fonts. Adobe does this in their newest fonts but did not in the older fonts, and Microsoft does not use the DFLT script tag at all (and as far as I can tell, they have no intention to).

So, why Adobe does this, and MS doesn't?

Microsoft is primarily interested in implementing language support for complex scripts in their applications, and mostly targets office users. So dingbat, agate-numerals-only, fractions-only etc. fonts are not their concern. Adobe is more design-savvy and tries to address the community of graphic designers, typographic designers, publication designers. Here, uses of fonts outside of a strong language context are more likely, so Adobe wanted a solution for that and proposed the DFLT script tag. The DFLT script tag is a "new thing" and Microsoft does not think they need it, since they did not feel a need for it from the beginning.

A.