Typophile

Class based kerning

Ken Krugh

We have a font we've been using for at least 3 years, developed in FontLab, generated as OTF, primarily for use in InDesign, gets updated from time to time.

Somewhere along the line the class based kerning stopped working in InDesign. I know it WAS working because when we first completed the font (compiled form the client's multiple fonts) we needed to use Karsten Luecke's fabulous "KLTF-MakeKernFeature" Python script to compile the kern feature.

Unfortunately, thus far, I've been unable to determine when the problem began occurring. I only have old FontLab files as back up and NOT the old OTF files, will possibly try generating those to see what comes of it.

So, while I investigate this further, entering panic mode, I thought I'd post asking what would cause this? That is, the class based kerning to not work in InDesign CS6.

Thank you,
Ken

Have you tried opening a support ticket on this at FontLab's site? It seems likely to me that they could give you a good answer.

It is not a FontLab Studio issue nor an issue with my script.

We solved it off the list, but since the issue (in a nutshell: features stopped working in a more recent version of InDesign) has come up a few times recently, it seems worth to remind of adding proper languagesystem statements when defining OTL features:

Defining OTL features is only part one of the job, the other part consists in associating these features with scripts and languages – applications apply only those features that are associated with script and language that match those of a given text.
In AFDKO's OpenType feature file syntax, there are two ways to associate features with scripts and languages.
1) Stating script [script name];, stating language [language name];, followed by the substitution or positioning statements, right in the feature definition.
2) Enumerating all possible script/language combinations in languagesystem statements that precede the feature definitions. (In FLS, their proper place is in the OpenType Panel's bottom right field.) These statements look like this:
languagesystem DFLT dflt;
languagesystem latn dflt;
languagesystem grek dflt;
languagesystem cyrl dflt;

Now, features whose definitions do not mention any script and language will be associated with script/language combinations as mentioned in these languagesystem statements.

If languagesystem statements are missing, AFDKO will silently add one but not all that may be required. As an effect, you may end up generating mal-functioning fonts without even noticing. This is what happened here.

For details, please see the AFDKO's OpenType Feature File Specification. Do not miss the examples.
A more readable version is in Tal Leming's OpenType Cookbook (search for the "Language Systems" section).

Some more background can be found in the OpenType specification (search for the "Table Organization" section).

Jeepers Karsten! Not only are you bailing me out via email but also filling in by posts before I even have a chance to go back and do so!! :o)

As Karsten explains, we went from InD CS3 to CS6. CS3 didn't care about the language, CS6 does.

Thank you again, Karsten.

{.}

So, now I'm wondering about InDesign's "[No language]" setting.
I've now defined the following for the languages:
languagesystem DFLT dflt;
languagesystem latn dflt;
languagesystem grek dflt;
languagesystem copt dflt;
languagesystem cyrl dflt;
languagesystem hebr dflt;
languagesystem math dflt;
languagesystem runr dflt;

I would have thought that languagesystem DFLT dflt; would have taken care of this, but apparently not.

It would be accidental if we had "[No language]" applied in InDesign and it seems crazy that InD will, potentially, ignore all features if "[No language]" is applied.

Does anyone know if there is anything I can do in the font to avoid having InD ignore the features when "[No language]" is applied?

Many thanks,
Ken

EDIT: ACaslonPro goes not have the problem, going to investigate that.
Also, when I compile the font I'm getting the following warning from FontLab:
[WARNING] Use of DFLT tag has been deprecated. It will work, but please use 'dflt' instead. [C:/Users/kenkrugh.TEKNTYPE/Documents/FontLab/Studio5/fontlab.fea 90].
Maybe the line languagesystem DFLT dflt; is not getting implemented even though the warning says it will work?

Maybe the line languagesystem DFLT dflt; is not getting implemented even though the warning says it will work?

That's it.
FLS 5.1.x and later versions know about script DFLT. Old FLS 5.0.4 does not.
To address FLS 5.0.4's trouble with script DFLT, Adam Twardoch has made a nice script. You would add the line languagesystem DFLT dflt;, you'd generate a buggy TTF or OTF from FLS 5.0.4, and finally you would run the font through the script to fix the TTF or OTF. Unfortunately, the download link which Adam provided back then does not seem to work any more.

See also: https://groups.google.com/forum/#!topic/uafdkoml/xqJPfEcSrqk

Downloaded Studio version 5.2.1, it fixed the problem of using "[No Language]" in InDesign.

However, its now displaying a message that it can't sign the font with our certificate because the password doesn't match, but it does. Any insight into THAT one would be much appreciated.

Karsten, I've not yet tried the script as we discussed via email. Will zip you an email when I do.

Thanks again for all the help,
Ken

Captured from web.archive.org on 20 Apr 2015. view this capture