-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add X Align [ XALN ] axis #126
Comments
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
|
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 |
@vv-monsalve suggested an axis name of |
Perhaps the tag will need to reflect the "Glyph" portion of the name. |
Because it allies globally to all glyphs, and all parts of all glyphs, it seems fine to elide :) |
Last agreed definitions for this axis. Axis metadata fields
|
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:
***@***.***>
|
@dberlow yes we can mention it on the glossary page :) |
Requirements
Similar to the
Vertical Alignment [YALN]
axis discussed in #106 and added in #125 there ought to be a similar designFont 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.
Axis metadata fields
(Remove this line and fill out the mock of the data structure of the axis)
The text was updated successfully, but these errors were encountered: