Add X Align [ XALN ] axis

[davelab6]

Requirements

Similar to the Vertical Alignment [YALN] axis discussed in #106 and added in #125 there ought to be a similar design

• I have inspected the current Axis Registry and there is not a registered custom axis that could be used for the variation purpose on the upcoming font project.
• The metadata fields of the proposed axis meet the Axis Requirements as specified in the Protocol (linked above).

Font project(s) using the axis

Google Sans Clock is a proprietary font made by Font Bureau for Google Pixel phone lockscreen clock faces, and so has not been needed in the fonts CSS API. It has a similar axis to YALN with a different name, "Swing" (SWNG). We may use this kind of variation in another upcoming font that will be needed in the CSS API, so I am filing this issue following my approval of YALN to flesh out the system of axes that it implies.

Swing was ranged -50 to +50 with default 0, but I think using 100 values as percent is better, so I'm starting with that, and hope @dberlow can comment :)

Short description of what the axis does

"Align glyphs horizontally from their default position to the left (-100%) with zero left sidebearing, or to the right (100%) with zero right sidebearing."

Image

Why is the axis needed

When laying out a clock like this, it is useful to be able to customize the exact horizontal position of the glyphs so they are perfectly balanced visually. An axis allows this fine configuration of the layout within the glyph boxes, with no reflow, or overly complex code at the document level.

HH
MM

Axis metadata fields

(Remove this line and fill out the mock of the data structure of the axis)

#XALN based on Google Sans Clock
tag: "XALN"
display_name: "X Alignment"
min_value: -100
default_value: 0
max_value: 100
precision: 0
fallback {
  name: "Default"
  value: 0
}
fallback_only: false
description:
  "Align glyphs horizontally from their default position"
  " to the left (-100%) with zero left sidebearing, or"
  " to the right (100%) with zero right sidebearing."

[dberlow]

Thanks for your proposal.

Swing was ranged -50 to +50 with default 0, but I think using 100 values as percent is better.

While a upm value, like Swing’s, can be used as a percent, like 50/2000ths is 2.5% of the em, and this can be used in association with other values that are percents of the em, like tracking, kerning and even per em stem thickness, any value that is a percent to begin with is local to a font, and in variations, to the percent of one style, and in your example to the percent of a glyph, and thus is less useable in programs. Also, keeping mind the steps in the clock’s origin: 1. Google chose an extra-bold, somewhat-condensed style. 2. FB kerned its figures. 3. Google tracked the required pairs, 01 to 59, much tighter, to near illegibility. 4. FB applied swing only to the lower pair of an `MM/HH` layout. So that is of concern related to this comment:

Align glyphs horizontally from their default position to the left (-100%) with zero left side bearing, or to the right (100%) with zero right side bearing.

If correctly spaced, glyphs that are then are shifted in unison left or right according to proportional changes to their default side bearings, will not remain correctly spaced. Take “10” and “01”: * 1 has zero side bearing on the left and 40 on the right * 0 has 20 side bearing on each side. Thus: * The default space between 1 and 0 is 60 * The default space between 0 and 1 is 20 At -50% on the proposed axis, 1 has nowhere to shift, its lsb=0, 0 shifts 10 units left. * The space between 1 and 0 is now 50 * The space between 0 and 1 is now 30 At 50% on your axis, 1 shifts 20 right, 0 shifts 10 right. * The space between 1 and 0 is now 50 * The space between 0 and 1 is now 10 Forgetting about whether both cliffs have positive side bearings in essence, even if they do proportional changes to large and small values, changes the inter glyph spacing. I don’t know how the kerning, tracking and swinging we did didn’t work for your needs, but I’d be interested in seeing how proportional shifting of a 3-axis variation, as this would need to work with opsz, wght, wdth and ital could work.  Cheers, David

[davelab6]

I was basing the % range off the YALN, and I forgot that SWNG was per-mille. The justification of per-mille being better here to allow programmability is a good one, and also that one can derive a per-cent from a per-mille value but not the other way around. Should YALN also be per-mille? See #106

[davelab6]

@vv-monsalve suggested an axis name of [XALN] Horizontal Glyph Alignment for this per-mille version of the [XELA] Horizontal Element Alignment per-cent axis.

[vv-monsalve]

Perhaps the tag will need to reflect the "Glyph" portion of the name.
XGAL XGPA?

[davelab6]

Because it allies globally to all glyphs, and all parts of all glyphs, it seems fine to elide :)

[vv-monsalve]

Last agreed definitions for this axis.

Axis metadata fields

#XALN based on a private project
tag: "XALN"
display_name: "Horizontal Alignment"
min_value: -100
default_value: 0
max_value: 100
precision: -1
fallback {
  name: "Default"
  value: 0
}
fallback_only: false
description:
  "Align glyphs horizontally from their default position"
  " to the left (-100%) with zero left sidebearing, or"
  " to the right (100%) with zero right sidebearing."

[dberlow]

If this is the former "swing" axis, I think some mention should be made, that while it is true that the axis moves glyphs back and forth horizontally, the purpose is optically centering figures composed vertically.

…

On Fri, Jan 26, 2024 at 1:56 PM Viviana Monsalve ***@***.***> wrote: Last agreed definitions for this axis. Axis metadata fields #XGAL based on Google Sans Clock tag: "XALN" display_name: "Horizontal Alignment" min_value: -100 default_value: 0 max_value: 100 precision: -1 fallback { name: "Default" value: 0 } fallback_only: false description: "Align glyphs horizontally from their default position" " to the left (-100%) with zero left sidebearing, or" " to the right (100%) with zero right sidebearing." — Reply to this email directly, view it on GitHub <#126 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAO5VDTSTKP3TGR3TFQ4UJ3YQP35PAVCNFSM6AAAAAAV7C2LYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJSGUZTQMZVGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[davelab6]

@dberlow yes we can mention it on the glossary page :)

[vv-monsalve]

At the last Axis Registry meeting, XALN was marked as approved. However, following the standard workflow, we waited for the final implementation in the font introducing the axis to be ready before opening and merging the PR.