Apostrophe kerning by contextual lookup table

I have to fix the kerning of the apostrophe, really important for the Italian (and French) language, as in the case of
L'America l'esempio l'Organizzazione
I tried to change the metric of the apostrophe, but it seems to work properly for the left side (L + '), while the metric of the next font maintains an excessive distance to the right side (' + A).
As a result, I thought not to touch the apostroph metric, but to resort to contextual kerning. I do not understand, however, which strategy should be adopted, as I have to approach the apostrophe both the letter that precedes and the one that follows.
Should I adopt Contextual Positioning? Chaining tables by classes or by coverage? And how can I operate, as written above, approaching the apostrophe both the antecedent and the following glyphs?
Thank you


  • I tried with two kerning classes:
    the first one L+' (quotesinge) and the second one ' (apostrophe) + A, and finally I've the right distance. However, looking some fonts I've, I didn't find a such setting; so I concluded that they adopted a method less direct, but more efficient. But which method??
  • Nick ShinnNick Shinn Posts: 1,532
    An alternative would be a second glyph, which would be substituted by the locl feature.
  • mauro sacchettomauro sacchetto Posts: 261
    edited December 2018
    Please, for I'm a dummy trying this matter for the first time, can be you so kind to be more explicit?
    What do you mean with "a second glyph"?
    Should I create a locl table in GSUB or in GPOS?
    I checked, for instance, ATF Garamond (which produces the kerning I need) and other two or three fonts, but in their locl tables there is nothing relevant to apostrophe kerning... And, moreover, I was unable to find where're the rules that oversee kerning for apostrophe
    Plz, suggest me where I can find those rules, and I'll try to understand...
  • Have a different glyph, with perhaps the same contour, but different sidebearings. You could call it "apostrophe.fr" or something.

    Your 'locl' feature would substitute the default glyph by the new one (GSUB), possibly in a contextual substitution so it only affects the particular combinations you care about. 
    Adobe has used this technique (even on one of my typefaces), and it seems to work well.
  • mauro sacchettomauro sacchetto Posts: 261
    edited December 2018
    Ok thank you! Now here it's 2 a.m., so I'll try tomorrow...
    in any case, where can I find this typical kerning in a known font? I mean FontFolio11 or Google Fonts, or, for instance, EB Garamond? I'd like to see which method they use, but I'm unable to find it

    Regarding the new glyph, have I to create only apostrophe (quotesingle), or even quoteright? And have I to add a new substitution rule?
  • I found a quoteright.fr in GaramondPremierePro; it has more bearing than quoteright.
    So I created a new quoteright.fr with a different bearing adequate for my font.

    Only... I was unable to find a substitution rule in GaramondPremierePro, if I checked well in calt. SO: where is this rule? I need to see how good fonts are made, to learn.

    A last problem: in any case, even if use (once the substitution rule has been created) the new quoteright.fr glyph, in any case I have to use some kerning, for obviously L'A and L'o have different metric and spaces. So, I ask: what is the advantage of creating a new glyph, if I still need in any case to kern?
  • In Garamond Premiere Pro it appears to be in 'calt' (it's there — you must have just missed it) though I personally would have placed it in 'locl'.
  • Unable to find, maybe for I don't know exacly what I must search for... :(
  • @mauro sacchetto Substituting for a glyph with wider sidebearings makes sense for French, but your original post doesn't imply that is what you want. You just state that those pairs are common for French and Italian, not that you want them kerned differently for text set in those languages.
    Are there any pitfalls for simply using contextual kerning?
    feature kern {
    or even a bit lavishly:
    feature kern {
  • mauro sacchettomauro sacchetto Posts: 261
    edited December 2018
    of course, mine was a request, not a mere observation on the presence in French or Italian of special couples.
    My goal is to reduce (and not to increase) the space between < letter + apostrophe + letter > with respect to the font metric I'm trying to work with. Inexperienced, I wonder if the best solution is to reduce the bearing or create a series of kernings. In the first case, however, since reducing kerning of the apostrophe is a general provision, I should in any case then create an appropriate kerning. I would like to understand the method adopted by the experts or in the better constructed fonts
  • mauro sacchettomauro sacchetto Posts: 261
    edited December 2018
    Are you kind enough to indicate me which Lookup and Contextual in Premiere?

    In the first part of your Comment you show me a very good way.
    But, passing from theory to practice:
    1. I create an "apostrophe.fr" with simmetrical sidebearing, and this is not a problem.
    2. I have to create a <Contextual Substitution> or (as I believe) a <Contextual Chaining Substitution>?
    3. Then, I create a subtable, but: by Classes or by Coverage?
    4. If I insert the glyphs, it request me a Lookup too. But have I to create another Lookup before? It's confusing...
    Does it exist a clear guide or manual explaining all this?
    Thank you
  • André G. IsaakAndré G. Isaak Posts: 473
    edited December 2018
    Are you kind enough to indicate me which Lookup and Contextual in Premiere?

    Since I don’t have access to the original source code, I can only tell you what shows up in FontLab's (FLS5) decompilation of the features. (I only looked at the Regular)

    The very last two lines of the 'calt' feature are

     language FRA ; # French
        sub @calt6 quoteright' @calt6 by quoteright.fr;
     language ITA ; # Italian
        sub @calt6 quoteright' @calt6 by quoteright.fr;
    where calt6 appears to be the class of all alphabetic characters.

    This is the only substitution rule in which quoteright.fr appears. In OTMaster this is identified as GSUB lookup #33
  • karstenlueckekarstenluecke Posts: 38
    edited December 2018
    Back to the original question: I think you better get that right with just normal spacing and kerning. If it doesn't work, then something seems to be wrong about your font's spacing and kerning, not only for French but for other languages too.
  • Thank you. I've different lookup numbers, but it's ok.
    Rather, I completely miss the logic of the steps I have to follow, as I wrote in the previous message.
    Do I have to create just a <Calt Lookup> or even another <Single Substitution Lookup> where I say to replace quoteright with quoteright.fr?
    In the first case, insert the glyphs in the List of Coverage Table (the class of all alphabetical characters).
    Should the <Add lookup> entry remain empty? Or have I to insert the <Single Substitution Lookup> over descripted?
    And how do I connect the glyphs inserted in the Coverage Table to the substitution of quoteright with quoteright.fr?
    Since I do not want to abuse this forum, could you indicate an understandable guide that explains the method and steps?
    Thank you
  • mauro sacchettomauro sacchetto Posts: 261
    edited December 2018
    @ kardtesluecke If I use quoteright and class kerning, all seems ok. This is a first solution.

    However, for I saw that in some optimal fonts is adopted the technique of Calt Substitution, and for it's a basic know-how to handle fonts, I'd like to understand how it's possible to apply it. What is wrong / missing in the steps I quoted above?

    PS If I set a Calt substitution only for some languages, how is determined in which language is written the text?
  • I’m not clear on what software you’re using to create your OpenType features. I just compile features from AFDKO source code from within FontLab, but it sounds like you are using something lower level than this. If you compile your code using FontLab/Glyphs/AFDKO/OTMaster etc. you normally don’t have to worry about these sorts of detail.
  • mauro sacchettomauro sacchetto Posts: 261
    edited December 2018
    I'm working with FontForge for I'm a Linux user.
    And hitherto I was not able to activate calt :(
    Plz, be king anough to consider not so much the software, but the steps to produce a working Calt....
  • FontForge is also AFDKO based for OpenType features, like FontLab.
  • Adam JagoszAdam Jagosz Posts: 605
    edited December 2018
    The way FontForge handles OpenType features is really confusing. Luckily you can just ignore (for the most part) the tricky GUI and just write your features in a text file and then import it (File > Merge features). I see it may seem dumb to write kerning in a text file instead of using the GUI that makes kerning a breeze. But if you want contextual kerning, that is the easiest way with FontForge. The same goes for calt, liga, and I'd say all GSUB.
  • mauro sacchettomauro sacchetto Posts: 261
    edited December 2018
    @AdamJagosz Where can I Iearn the relative text sintax?
    PS I understand that obviously in this case I have to write a file to merge, but I was not able to find if, moreover, it's possible to create/export a .fea file of my font with FontForge

    @ThomasPhinney Plz, consider the steps I described above. Is it enough to produce a Coverage Table, or a Substitution Table too? That's one of my great uncertainties...
  • Plz, be king anough to consider not so much the software, but the steps to produce a working Calt....
    The steps needed to produce a 'calt' feature *depend* on the software, so it's not really possible to discuss without also talking about the software.

    I don't normally use FontForge, but opening it up I get the impression that you are looking at the 'Lookups' tab inside the Elements->Font Info dialog. While it may be possible to create features from within this dialog, this is really the place where one goes to look at the low-level details of an existing font.

    To create new features, you really should create a feature file and use the File-Merge Feature Info… command. That way you don't have to worry about low-level details like coverage tables etc. as the compiler will do that for you.

    Where can I Iearn the relative text sintax?
    The official syntax guide is at


    The FontLab manual contains a somewhat more readable intro to the fundamentals. You can download the manual from the following site without purchasing FontLab.


    If I set a Calt substitution only for some languages, how is determined in which language is written the text?

    That depends on the application, but most applications allow you to set the language of a block of text. In some cases language selection may be tied to the spell-checker settings.
  • Thank you!
    A last clarification. For in metadata I have to specify languages, in the lookups is it enough to put:
    DFLT{dflt} cyrl{dflt} grek{dflt} latn{dflt}
    (or even without cyrl for in my case I've no glyphs for Russian language) or must I write all supported laguages explicitly? I mean
    DFLT{dflt} cyrl{dflt} grek{dflt} latn{DEU ,FRA ,ITA ,dflt}
    And why in the fonts I controlled there is never English? Is it the (understood) <dflt> language?
  • André G. IsaakAndré G. Isaak Posts: 473
    edited December 2018
    You normally specify the scripts which are supported by your font, along with the default behaviours for those scripts. You only need to declare specific languages if you define language-specific behaviours.

    There's nothing to prevent you from declaring English (latn ENG), but English typically has no language-specific behaviours, so there's really no need.

    If you use an AFDKO feature file, you won't need to deal with any of this metadata since the languagesystems will be declared within the feature file. As I said, the lookups tab in FontForge is really the wrong place to be doing all this.
  • I'm not a Linux person, but perhaps there's someone reading this thread who can recommend a Linux (or WINE-compatible) application which can decompile features into AFDKO source files, since I think Mauro would benefit from seeing decompiled code alongside the lookup descriptions inside FontForge.
  • Infact I asked just before on FontForge Github if it's possible to generate with FontForge .fea files and so on to have text files with readable information... If not, I'll download for the moment the trial version of FontLab on my Windows partition. For it's not so cheap...
    Thank for your help
  • Adam JagoszAdam Jagosz Posts: 605
    edited December 2018
    @mauro sacchetto You can export your existing features from FontForge. To do so, right-click any of the lookups and select "Save feature file" or something like that. This will save all of your features to a text file with .fea extension, despite clicking just one of the features. This is one way to learn the syntax, since you know what kind of features you managed to "click out" in the GUI, and now you will see how they look as plain text.
    You may keep some of your features in the FontForge project file, and have others in a text file that you only import before exporting the font or for testing, and then you don't save the project to keep the text file features separate. This way you can play around without the pain of removing erroneous features from the project manually.
    What I do is have the mark and mkmk features in the project file (since the anchor system is quite friendly in FontForge), but keep all other features in text files. Perhaps you could consider having regular kerning in FF as well, I don't because the kerning is sometimes incorrectly displayed in FF Metrics window, at least on Windows, and by having kerning in a text file I see all the values immediately without having to click my way through the kerning dialog in FF, which I find buggy (and sometimes it even crashes).
  • Though Adam points out how to make .fea files from FontForge, you might want to download the FontLab trial anyways since you'll likely find that the two decompiled sources look very different (for reasons which Frode has already explained) and having two versions of the source might be informative. 
  • Yes, learning .fea syntax from decompiled FontForge structures is tricky, for instance you might get the impression that everything needs to be explicitly put into lookups or that things need to be repeated for each languagesystem. FontForge outputs its internal structures in a suboptimal way. In addition, I think there are some errors in how FF treats the keyword exclude_dflt, so that needs to be taken into consideration when writing up .fea to be imported in FF.
    for reasons which Frode has already explained
    @André G. Isaak Sounds interesting, care to share a link?
Sign In or Register to comment.