Recently I proposed to Microsoft the registration of a ‘Spacing axis’ in OpenType Font Variations. Tracking and CSS letterspacing are highly primitive mechanisms and they mess up spacing (for instance with unwanted negative side bearings) and ruin the kerning. Tighter and wider spacing should be controlled by the font producer and hence needs to be recalculated. Kerning pairs should be adapted too IMHO.
In the meantime I exchanged ideas with John Hudson and Peter Constable and this resulted in the axis deﬁnition and additional information below, which will be discussed at the upcoming TYPO Labs conference in Berlin:1. Axis deﬁnition
Description: Used to vary glyph spacing.
Valid numeric range: Any negative, zero or positive value can be used.
Scale interpretation: Values can be interpreted as per-mille-of-em changes in glyph spacing from ‘normal’ spacing.
Recommended ‘normal’ value: 0
Suggested programmatic interactions: Applications may choose to select a spacing variant in connection to user-selected layout settings for ‘tracking’ or ‘character spacing’.2. Additional information
Glyph side-bearing distances are typically the primary aspect of design that varies, though other secondary details such as serifs may also be encompassed in this variation. Variation may also be applied to other font values that are sensitive to glyph metrics, such as kerning distances or mark anchor positioning.
The Spacing axis can be used as a variation axis within a variable font. It can also be used within a ‘STAT’ table in non-variable fonts within a family that has spacing variants to provide a complete characterization of a font in relation to its family within the ‘STAT’ table.
Some applications may use Spacing variants to implement layout features such as ‘tracking’ or ‘character spacing’. This may be limited to variable fonts that implement Spacing as also variable axis. Applications that do this can use the axis values in combination with the font’s head.unitsPerEm value to map between the axis-value scale and physical units such as points. When Spacing variants are selected in this way, applications should assume that the font will provide all of the spacing adjustment, and not apply any additional glyph metric adjustments.3. Demo
I made a screen recording of a prototype font
with a proprietary Spacing axis. 4. Spacing versus tracking
The following image shows on top a version of DTL Haarlemmer of which the spacing has been reduced with a ﬁxed amount and of which the kerning has not been changed (i.e., what happens with tracking) and a version in which the character widths and the kerning have been adapted per character. In case of tracking a couple of characters, such as the /r and the/v, get a negative spacing. In the manually (optically) altered version (bottom) the right side bearing of the /r and both side bearings of the /v have been set to zero.
In the image below the manually altered version is further reﬁned by adapting the length of the serifs to the tighter spacing (top). This is in line with the method of ﬁrst patterning (stem interval) and then adapting details like serifs to obtain equilibrium of space, instead of the approach of ﬁrst designing details and then adapting the patterning to obtain an even distribution of space.5. Notes on the spacing method
For the prototype font I newly calculated the spacing of DTL Haarlemmer using the LS Cadencer tool –which is developed by Lukas Schneider– in RoboFont. The image below shows the ‘standard’ spacing.
The following image shows the tighter spacing.
The LS Cadencer is based on a spacing algorithm I developed based on my investigation of Renaissance archetypal patterning. Lukas will demonstrate his ‘cadencing’ tools at the TYPO Labs 2017 conference on Thursday 6 April.
BTW might this be a better place than the Width axis to incorporate a uniwidth option?
I am especially interested to understand (a) how this axis could work in harmony with other axes that have been included in https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/tree/master/Proposals;
and (b) how this axis can really work for kerning. In the proposal you wrote, "Kerning pairs should be adapted too, of course." but looking at the video it wasn't clear to me if that was implemented. It looks like you simply have 2 masters with 2 sets of sidebearings, and the complexities of using the axis in a retail-ready font are not visibly dealt with.
The idea is that if the axis is present in a font, it is used automatically by applications for tracking, until the tracking value is outside what is deﬁned in the variable font. When it comes to implementation complexities, IIRC, Sergey Malkin noted in the related discussion on GitHub that it should be doable. Unfortunately, I am always a bit lost on GitHub and cannot ﬁnd the discussion anymore. David Berlow mentioned that the naming of the axis is not properly chosen and I think he is right. It should be something with ‘rhythmical’, ‘proportional’, ‘patterning’, and ‘ﬁtting’, I reckon. However, ‘Rhythmical Proportional Patterning Fitting Axis’ is perhaps a bit too long.
The font that I used for the demo, is DTL Haarlemmer. I made a second master in which I adapted the lengths of the serifs and changed a few other details, for example some glyph proportions. These adaptations keep the spacing quite decent if this becomes tighter IMHO. When it comes to kerning, you are correct: I did not do anything with this in the demo.
I think you are referring to Sergey's comment here, https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/issues/11#issuecomment-350907681 (and there's also https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/pull/9 but with much fewer comments)
On https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/issues/11 DB has just posted another comment.
If I have a VF with weight, width, and your proposed tracking axis, and I dial in a bold condensed with tight tracking, all 1970s like, and then vary it to be wide and bold, the tracking axis value will stay the same... but I guess that the actual values for 'tight' would need to be different?
However, please feel free to play around with the ‘RPPF’ axis and to enhance/improve the idea. Of course, this applies to everyone on this forum.