Space kerning and OpenType Layout

Simon Cozens

I have this layout engine, which works on the standard TeX-like principle: text is in boxes and sent to a shaper, spaces are intercepted and replaced by flexible glue nodes, on the assumption that a font's space width is constant.

SIL's Awami font makes heavy use of space kerning, and so breaks that assumption. It expects text including spaces to be sent to the shaper, which will return a kerned (context-sensitive) space width. I could make this happen but it makes line breaking much more complex as I will need to look into and break up shaped text runs.

I don't really like the idea of changing the shaping system for one font, but I might need to if my assumptions about how layout works are incorrect.

i seem to remember a recent discussion somewhere about this sort of thing in the context of OpenType Layout, but I can't put my hands on it right now.

So some questions:
Is this kind of space kerning "a thing" that I need to worry about?
Does it affect other systems than Nastaliq?
Should I stop intercepting spaces and move to a "shape everything" model?

Paul van der Laan

I know plenty of typefaces – made by professionals – that have kerning with the /space glyph. Some typefaces in our library have it too.

There are also typefaces where the /space glyph contains outlines for underlining, or a solid black block. Nitti Typewriter is such an example. 

Also consider the fact that there are plenty of typefaces out there with OpenType features that do substitutions with /space.

Erwin Denissen

Please don't divide text at the space characters. It is incorrect and might break OpenType layout feature code.

I know some of our customers design cursive fonts and make use of contextual substitutions which depend on the space character. Some still use init, isol, medi, and fina but those are now deprecated for Latin script.

Khaled Hosny

There is also the question what to do with kerned space when justifying text? should it be expanded by the same amount as un-kerned spaces, by a n amount relative the the difference with un-kerned space, no expansion at all?

Simon Cozens

Hah. I've actually discovered that my layout engine was better written than I thought. It does send entire runs to the OpenType layout engine. But then it digs through the shaped item list and replaces space characters with fixed-width glue nodes. If I just tell it to accept the shaper's understanding of the width of the space rather than use a fixed width, it all works.

Dave Crossland

To add a little more detail to Paul's comment, a libre example of this is https://fonts.google.com/specimen/Zilla+Slab+Highlight

There's also https://fonts.google.com/specimen/Libre+Barcode+39 and friends, which have meaningful ink in their space glyphs.

I assume your layout engine won't render them as intended (for Zilla) and required (for barcodes) even with this, unless your glue nodes are filled with the ink in the glyph?

Simon Cozens

Oh wow. I get that these are display fonts but I wonder what the intended rendering is for, say, Zilla Slab in a full-justified context. Ideally you'd have a flexible-width black space, but I can't see how a layout engine would be expected to know that. Pages and LibreOffice display the (inked) space character and then add flexible (white) glue afterwards, which is probably the least bad solution.

As for Libre Barcode... ouch, my head.

Khaled Hosny

Having ink in the space glyph is a bad idea in general. Layout engines often replace control characters (e.g. ZWNJ, ZWJ, RLM, SHY, etc.) with space glyph and set its width to zero, so in such fonts you will get an overlapping glyph outline. It should be OK for display or specialized typefaces, but otherwise I don’t think one needs to be be more clever than what Pages and LibreOffice are doing here.

Erwin Denissen

Dave Crossland said:

To add a little more detail to Paul's comment, a libre example of this is https://fonts.google.com/specimen/Zilla+Slab+Highlight

There's also https://fonts.google.com/specimen/Libre+Barcode+39 and friends, which have meaningful ink in their space glyphs.

I assume your layout engine won't render them as intended (for Zilla) and required (for barcodes) even with this, unless your glue nodes are filled with the ink in the glyph?

FontCreator renders them just fine. It even revealed an issue with Zilla Slab Highlight and fractions.



It also seems to have some issues with white space between lines of text (see above) or overlapping text (see below where "g" is not fully visible).

And inconsistent OpenType layout behaviour between web browsers.


Firefox works correctly imho.


Chrome seems to use the Default script instead of Latin.

Nick Shinn

<dlig>, <liga> and <rlig> are a quite specific hierarchy of implementation, which should be determined by the font, not over-ridden by the ‘cleverness’ of a layout application.

Erwin Denissen

Nick Shinn said:

<dlig>, <liga> and <rlig> are a quite specific hierarchy of implementation, which should be determined by the font, not over-ridden by the ‘cleverness’ of a layout application.

What you prefer is not what actually happens.

In case you refer to my post, it is good to know Zila only contains liga.

Nick Shinn

What you prefer is not what actually happens.

It’s not what I “prefer”, it’s the specification in the OpenType Layout Tag Registry!

<dlig> : off by default, may be turned on at the user’s discretion.
<liga> : on by default, may be turned off at the user‘s discretion.
<rlig> : on by default, cannot be turned off by the user.

Isn’t this what should actually happen?

Erwin Denissen

Almost, as most shaping engines will first process liga and rlig, processing their lookups in the order as specific within the font, and after those are processed it will process dlig (if turned on).

Thomas Phinney

When font size and coding time permit, it can be safer for the designer or font coder to implement “defensive coding” practices: whenever possible, code all features so that they will work as desired, no matter what order the features/lookups are actually processed.

I have done this on a number of occasions now.

Adam Twardoch

The support for "rlig" for European scripts is rather inconsistent. The Microsoft spec doesn't include it in the list of the features that are applied by default: https://www.microsoft.com/typography/OpenTypeDev/standard/intro.htm

Nick Shinn

<rlig> is nonetheless very useful for European scripts—because unlike <calt> it doesn’t fail when tracking is applied.

So, I have been using it in my recent pseudo-random fonts.

It’s supported by InDesign and the like, which is where typographers may vary tracking.

Erwin Denissen

Support is pretty good. Web browsers support rlig by default. Word will apply both liga and rlig when Standard Ligatures are enabled. It will also apply rlig when you enable contextual alternates.