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

[PeterCon]

No description provided.

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

[dberlow]

Regarding the spacing axis, and Frank’s comments on TypeDrawers, http://typedrawers.com/discussion/2088/otvar-spacing-axis
...the idea of including, what is over the range a given spacing axis, a replacement for tracking, is an example of an axis’ potential conflict with application functionality where “double-transformations” can occur.

E.G., Axis-Praxis ignorance of blended axes, when set off to randomly selecting Amstelvar instances, is a cousin-like example of this. Selecting a random instance among the registered axes far from Amstelvar's default, and then selecting a parametric axis location far from the default, is likely to produce instances with a unintended double-deltas, double-transforming some parts of glyphs. This has been evident for over a year, and should be no surprise to the design audience.

The situation in the Spacing axis’ case, is that a variable font with such an axis needs to inform the OS to tell the app to change the behavior of the tracking, to avoid allowing it twice. This situation has cases everywhere. Variable fonts can contain a wght axis that should not be faux bolded, a wdth axis that should not be horizontally scaled, opsz that should not be zoomed, and a slant axis should not be reslanted by unwitting double-transformation.

If, e.g. an application currently working as Axis-Praxis does, were set loose finding arbitrary instances among the registered axes of a variable font, and among the instances with an application’s faux bolding, skewing, horizontal scaling and zooming, the majority of instances would be more screwed up than instances Amstelvar produces, not for the least of reasons being, that all of Amstelvar’s transformations are controllable in the variations, and thus can be subset out of existence without disturbing any applications.

Many unregistered axes, like variable fonts with stroked contours, underlines, drop shadows or baseline shifts, could be double-transformed as well., which makes the current mode of slowly moving, Particularly on variations that already exist the world, somewhat misguided imho.

And I think a Spacing axis is something that falls directly into this category.

[davelab6]

Axis-Praxis ignorance of blended axes

Here is a GIF snapshot of what knowledge of blended axes looks like :)

[tiroj]

What you're calling blended axes — a good term, by the way — are just one possible implementation of a relationship between parametric and optical axes. They happen to be the implementation that is currently possible within the OT variations architecture, but double-transformation is potentially problematic for any implementation that involves mixing parametric and optical axes within the same architectural space. Even if we come up with an architecture for virtual or meta axes instead of blended axes, there need to be rules and probably technical controls to prevent mixing transformations within the variable design space.

I emphasised that last clause because I think the problem of double transformations from mixing parametric and optical axis adjustments in variable space is different from the problem of double transformation from software applying two different text layout or display mechanisms to the same glyphs. All the currently registered OT variations axes have specifically defined functionality in layout, and constitute new, variable font specific mechanisms to achieve kinds of display that can already be achieved using different mechanisms with static fonts. Indeed, it is the pre-existence of such standard mechanisms — weight class, for example — that made it easy to define the scale and behaviour of the initial five registered axes in ways that would be interoperable with existing display outcomes. This is also why I think some kind of tracking axis looks like it could be a viable candidate for similar treatment, since tracking mechanisms already exist, have some standard scales, and it would be possible to define axis behaviour in these terms. In the same way that the optical weight or width axis replaces the mechanisms of family mapping and weight/width class, I would assume a tracking axis would replace the tracking function as applied to text in non-variable fonts.

That's not to say that some software could easily get it wrong, but that the correct behaviour can be defined in the axis registry without any change being needed to the format; whereas, I am not sure that is the case with regard to the problem of double transformations within the design space from mixing different axis types.

[dberlow]

I’m gonna keep this thread on topic, and I guess now John and Frank should demonstrate deployment of a spacing access.

…

Sent from my iPad

On May 15, 2018, at 8:20 PM, John Hudson ***@***.***> wrote: What you're calling blended axes — a good term, by the way — are just one possible implementation of a relationship between parametric and optical axes. They happen to be the implementation that is currently possible within the OT variations architecture, but double-transformation is potentially problematic for any implementation that involves mixing parametric and optical axes within the same architectural space. Even if we come up with an architecture for virtual or meta axes instead of blended axes, there need to be rules and probably technical controls to prevent mixing transformations within the variable design space. I emphasised that last clause because I think the problem of double transformations from mixing parametric and optical axis adjustments in variable space is different from the problem of double transformation from software applying two different text layout or display mechanisms to the same glyphs. All the currently registered OT variations axes have specifically defined functionality in layout, and constitute new, variable font specific mechanisms to achieve kinds of display that can already be achieved using different mechanisms with static fonts. Indeed, it is the pre-existence of such standard mechanisms — weight class, for example — that made it easy to define the scale and behaviour of the initial five registered axes in ways that would be interoperable with existing display outcomes. This is also why I think some kind of tracking axis looks like it could be a viable candidate for similar treatment, since tracking mechanisms already exist, have some standard scales, and it would be possible to define axis behaviour in these terms. In the same way that the optical weight or width axis replaces the mechanisms of family mapping and weight/width class, I would assume a tracking axis would replace the tracking function as applied to text in non-variable fonts. That's not to say that some software could easily get it wrong, but that the correct behaviour can be defined in the axis registry without any change being needed to the format; whereas, I am not sure that is the case with regard to the problem of double transformations within the design space from mixing different axis types. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.