Skip to content
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

Enlarge Axis Re-Calibration Brainstorm #71

Open
kenmcd opened this issue Oct 4, 2021 · 1 comment
Open

Enlarge Axis Re-Calibration Brainstorm #71

kenmcd opened this issue Oct 4, 2021 · 1 comment

Comments

@kenmcd
Copy link

kenmcd commented Oct 4, 2021

While finally getting around to playing with the vertical metrics …

I took a look at the new Enlarge axis in the variable font.
And that got me wondering if the ENLA axis range could have a more logical scale.

Recently the GF folks reconfigured a number of their variable fonts to change those with opsz to all be based on point size - some were arbitrary scales like 1-100, etc. (note: there is an ongoing discussion on what those values should be based on the wacko Apple pt vs. px nonsense).

Awhile back both the Roboto-Flex and Amstelvar fonts re-calibrated the GRAD axis to be similar to the OS/2 weight (wght) values. That was thought to be more logical and intuitive to users than an arbitrary scale.

Same thing is happening with the slant axis - arbitrary vs. trying to get close to the actual slant percent, and plus vs. minus for the slant direction.

So this got me thinking about the Enlarge axis and the current 0-1 scale.
Is there something more logical or more intuitive to users?

Normal x-height is 850 which is 63% of X-height (1358), and
Enlarged x-height is 1012 which is 75% of X-height.
So is a scale of 63-75 more logical or intuitive?
Note to users about Enlarge axis: normal x-height is 63% of the cap height,
and the Enlarge axis allows you to increase this up to 75% of the cap height.
Note that this is different than the similar x-height axis in that the character width also increases not just the x-height.

Or should normal x-height 850 = 100%, and since the enlarged 1012 is 119% of that,
should it be 100% to 119%?
Note to users about Enlarge axis: allows you to enlarge lowercase characters by up to approx. 120% of normal size.
Then users can set it to the percent increase they want.
That seems to be the most intuitive to me.

Or some other rational and intuitive scale which makes even more sense?

@psb1558
Copy link
Owner

psb1558 commented Oct 5, 2021

Thanks for thinking about this, @kenmcd!

For anyone who doesn't know the material Junicode is working with, the Medieval Unicode Font Inititive recommendation has a group of characters called "Enlarged Minuscules." In manuscripts, these are generally shaped like lowercase letters but used like capitals, for example at the beginnings of sentences. MUFI encodes these in the Private Use Area, which is suboptimal for all but print-only publications—for reasons I have exhausted myself explaining many times.

Desktop Junicode tries to improve the situation by offering access to these characters through the OpenType feature ss06, but for the variable version it occurred to me that it might work even better to provide access through an "Enlarge" axis, which would provide many improvements: the biggest in accessibility, but also in flexibility and the sheer number of characters that could be handled this way.

In choosing the range 0-1, I had a couple of thoughts. First, because "axis" is a new concept for many users, I wanted to keep it simple. And second, for most texts, use of an enlarged minuscule is a binary choice, even though a range of values is available. A letter is either going to be enlarged or it isn't—so I thought it made sense to use end-point values that could be interpreted as meaning "off" and "on."

But there are other ways to look at this, and I would hope that any users or interested parties might weigh in. Also, it's extremely easy to change the scale for an axis, and I am very glad to experiment with this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants