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?
0
Comments
There are also typefaces where the /space glyph contains outlines for underlining, or a solid black block. Nitti Typewriter is such an example.
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.
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?
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.
In case you refer to my post, it is good to know Zila only contains liga.
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?
I have done this on a number of occasions now.
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.