Proposal for a "Spacing" axis ('spac') has been submitted. Please discuss in this thread.

[PeterCon]

[miguelsousa]

@PeterCon having a link to the proposal would help, I think
https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/blob/master/Proposals/Spacing_Axis/ProposalSummary.md

[PeterCon]

Yes, that's the link. Thanks for adding.

[twardoch]

This proposal has the additional benefit that it should implement "functional spacing" or control the "perceived effects of spacing", i.e. as an optical axis, it could, depending on design, employ additional tricks:

If certain glyphs clash unpleasantly at tighter spacing, then some glyphs could either vary slightly (for example an overhanging terminal if an "f" might be shortened).

Also, with feature variations, the creator could explicitly decide at what point to enable or disable certain ligatures.

This axis could employ width adjustment of certain glyphs, for example marks that range over several glyphs.

As a result, the user would get correctly "respaced" text (tightened or loosened) with all kinds of corrections that are necessary to make the result "look good".

[twardoch]

Also, if a design is multi-script or non-Latin, the designer could specify that only certain glyphs are subject to spacing while others aren't (because it is not desired).

For connected designs (e.g. calligraphic scripts or Arabic), the font could implement the functional notion of "spacing" differently — similar to how Arabic justification works.

[twardoch]

For Indic scripts that use a topline, as the distance between the distinctive changes, the topline could also scale accordingly so it never gets interrupted.

For color fonts or fonts that have a "reversed body" or a "background" (a visible "black" rectangle box and "white" letterforms inside), that background could also stretch so that it remains continuous.

Generally, any types of connections between the glyphs where it is desired that these connections remain connected when spacing is changed, could vary in width of the ink so that they indeed remain connected, while the distinctive or constituting parts of letterforms could change their distance between them.

This is different from the width axis where the constituting parts of the letterforms change their width, including counters.

[mashabow]

In vertical typesetting, can we use this axis to adjust the vertical spacing?

[twardoch]

I think it might be safer to consider a separate axis "vspc".

[twardoch]

Even only because the "spac" axis might likely interact with the "kern" feature but the "vspc" axis could interact with the "vkrn" feature. Since the same glyphs would need different aspects changed if we are changing horizontal vs. vertical spacing, it might be better to consider two separate axes.

(I know: I think it's a bit annoying that so many things related to vertical typesetting get a "v" prefix while things for horizontal typesetting get away with no prefix. That's pure directionism and a clear sign of discrimination.)

[PeterCon]

Potentially, if the implementation of a spacing axis in a font only affects glyph metrics but not outlines or glyph selection (GSUB), then it could be used for both vertical and horizontal layout: both metrics would be affected by the setting for that axis, but only one or the other will get used in a given layout.

But I suspect many would like to make changes to outlines or glyph selection in ways that assume one direction or the other. So, Adam's suggestion of a separate vertical spacing axis may be preferable.

Btw, one important thing to note: when talking about "vertical" layout, the thing that matters is not the orientation of the baseline relative to a frame or page, but rather the layout mode used for individual runs of text along that baseline. For example, if connected Arabic or Devanagari text appears within a vertical line of CJK text, such that the Arabic/Devanagari has expected horizontal-layout appearance if the page is rotated 90 degrees CCW, then that Arabic or Devanagari run is using a horizontal layout mode. An alternative layout mode for Arabic or Devanagari might be to stack characters or clusters with the glyphs rotated 90 degrees relative to the baseline.

[dberlow]

The name of this axis is too broad for all scripts and designs.

Whether it is vertical or horizontal, proportional or monospace is important to the name and definition.

Thanks.

[mashabow]

Btw, one important thing to note: when talking about "vertical" layout, the thing that matters is not the orientation of the baseline relative to a frame or page, but rather the layout mode used for individual runs of text along that baseline.

Ah, it's important to distinguish upright and sideways (for those unfamiliar, please refer CSS Writing Modes or UAX #50). I agree with @twardoch on the "vspc" axis, and in vertical typesetting, smart applications may adjust "vspc" for upright glyphs and "spac" for sideways glyphs.

Instead of "spac"/"vspc", it would be clearer to call them "xspc"/"yspc" based on the glyph coordinate system, but we have many "v"s in the OpenType world already.

[SergeyMalkin]

This is nice axis that may enable very interesting scenarios, but spec is not at the point that is sufficient to start using it. Spacing support from the font requires more complex definition than just (sorry for speaking bluntly from perspective of layout engine) "increasing/decreasing width of glyphs with potential adjustments in context of neighbor glyphs".

Tracking or spacing is applied between glyphs. This means that first or last glyph in the run doesn't get width increase. This means variable font should somehow be aware of context surrounding particular run of text inside paragraph. More complex scenario involves tracking between runs of different scripts, fonts, or layout direction. CSS letter-spacing doesn't provide a lot of typographic freedom, but it allows layout engine to control this kind of scenarios. We need similar control for spacing, but at the same time enable full potential of proposed axis.

Current proposal doesn't cover this. In fact, I don't know of any existing mechanism to support necessary functionality by simply creating another instance with different values of 'spac' axis and let font to the work. But we may be able to invent one, probably by using combination of variation axis, layout features, and/or protocol for interaction between font and layout engine.