Opentype Registered Features

Joon Park

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.

Mark Simonson

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.

Joon Park

Mark Simonson said:

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?

Joon Park

Also, I don't want Standard Ligatures enabled by default, but want to have "

liga" option, is that possible?

Ray Larabie

Maybe use discretionary ligatures. <dlig> Unlike liga, they're off by default. Standard ligatures are automatically turned on in many applications.

Kent Lew

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

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.

Joon Park

Ray Larabie said:

Maybe use discretionary ligatures. <dlig> Unlike liga, they're off by default. Standard ligatures are automatically turned on in many applications.

Ah, excellent idea!

Joon Park

Mark Simonson said:

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?

Mark Simonson

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.

Joon Park

I think old style table can work similarly by grouping glyphs into classes

Mark Simonson

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.

Joon Park

Got it, I'll do classes to go with opentype features and do kern table afterward

John Hudson

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 Kutilek

The limit of one old format kern subtable is 10920 pairs.

On a funny side note, if you expand the class-based kerning in FontLab Studio 5 and limit the number of pairs to exactly 10920, FontLab will generate a font with empty kerning table.

No known application looks beyond the first kern subtable, and fonts with more than two kern subtables are flagged as defective in recent Mac OS X versions.

Joon Park

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)

Jens Kutilek

I would generate only the GPOS kern feature, unless specifcally ordered by a customer to include an old-style kern table.

Dave Crossland

Is the old-school 'kern' table needed for MS Word?

Michael Vokits

Dave Crossland said:

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