Opentype Registered Features

So I've been trying to learn about opentype features you can add.
(https://www.microsoft.com/typography/otspec/features_ae.htm)

Most of fonts I looked through have their own kerning and metric #s but in opentype feature, I also see "kern" but not a full list of kerning adjustment I see from metric/kerning window in FL.

example:

feature kern { # Kerning
 # DEFAULT
lookup kern1 {
    pos space Alphatonos -50;
    pos space Omicrontonos -12;

So why are there two different places dealing with kerning and why is this one not a 100% same as ones I see in FL's kerning window.

Comments

  • The "kern" table is a legacy from the pre-OpenType days and is more or less deprecated, along with things like separate Mac and PC font formats and lack of Unicode support. The "kern" OpenType feature is a more flexible and "modern" way to do it.
  • The "kern" table is a legacy from the pre-OpenType days and is more or less deprecated, along with things like separate Mac and PC font formats and lack of Unicode support. The "kern" OpenType feature is a more flexible and "modern" way to do it.
    So do you recommend still doing both?
  • Also, I don't want Standard Ligatures enabled by default, but want to have "

    liga" option, is that possible?

  • Ray Larabie
    Ray Larabie Posts: 1,436
    Maybe use discretionary ligatures. <dlig> Unlike liga, they're off by default. Standard ligatures are automatically turned on in many applications.
  • Kent Lew
    Kent Lew Posts: 944
    Also, I don't want Standard Ligatures enabled by default
    Whether a feature is on or off by default is not something that a font dictates. This is up to the font interpreter and text rendering system.

    The OpenType spec makes recommendations to app developers [not rules] for each registered feature about whether it should be implemented by default and how the UI should handle it. In some cases, the app makers follow these and in some cases not. Over time, certain conventional behaviors have solidified, like Standard Ligatures being on by default (which happens also to be the recommendation).

    Font makers work with the constraints of what is or is not implemented in the anticipated end-use environment(s). In the case of OpenType Layout features, we provide, but we cannot dictate.

    If you have ligatures that you don’t want enabled by default, then you are best off not putting them in a feature that most environments enable by default. Like Ray said.
  • attar
    attar Posts: 209
    edited October 2015
    Well in terms of semantics, I would say if you put something in liga then you are essentially saying that it is "required" ligature for proper display of the font (e.g. fi ligature in serif typefaces to clear collisions). Using dlig is really what you should be doing if you have quaint ligatures.
  • Maybe use discretionary ligatures. <dlig> Unlike liga, they're off by default. Standard ligatures are automatically turned on in many applications.
    Ah, excellent idea!

  • The "kern" table is a legacy from the pre-OpenType days and is more or less deprecated, along with things like separate Mac and PC font formats and lack of Unicode support. The "kern" OpenType feature is a more flexible and "modern" way to do it.
    So, do you recommending adjusting kerning on both?
  • If you are working in FontLab, you can include both, and there are some who recommend it. I don't since modern software, if it supports kerning at all, will do it using the kern feature. The only reason I know for including the old style kern table is for supporting old software that lacks OpenType support.

    If you do your kerning in FontLab, the data is stored internally and can be included in the generated fonts either as an old style kern table, a kern feature (using "update kern feature"), or both.

    Note that the old style kern table is more limited in size and is "flat". It's just a simple list of character pairs and kerning offsets. As I recall the limit is around 5000 pairs.

    The kern feature allows you to kern classes of characters. This both reduces the amount of data needed and in effect allows many more pairs to be included by an order of magnitude.

    If you "flatten" class kerning, you can easily exceed the limits of the old style kern table. For this reason, if you include both types of kerning in your font, it's likely that the old style kern table will need to be limited to a subset of pairs. FontLab offers to do this for you if it happens.
  • I think old style table can work similarly by grouping glyphs into classes
  • It is a convenience for working in FontLab only. Old style kern tables do not support classes. The classes are flattened into individual character pairs when generating the font. Only the OpenType kern feature supports classes.
  • Got it, I'll do classes to go with opentype features and do kern table afterward
  • John Hudson
    John Hudson Posts: 3,230
    Note that there are support issues around the size of the old format kern table — more than a few thousand pairs won't be processed —, and also discrepancies between software in support for unencoded glyphs in that format.
  • Jens, which is best/ideal way to do kerning then? (Mine is geometric so I won't need to do much kerning compare to others)
  • I would generate only the GPOS kern feature, unless specifcally ordered by a customer to include an old-style kern table.
  • Is the old-school 'kern' table needed for MS Word?
  • Is the old-school 'kern' table needed for MS Word?
    For some versions (anything before 2010?) and some font styles (TT), yes. But that only affects some people (just me, as far as I can tell  :) ).