Junicode-font icon indicating copy to clipboard operation
Junicode-font copied to clipboard

Enlarge Axis Re-Calibration Brainstorm

Open kenmcd opened this issue 2 years ago • 1 comments

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?

kenmcd avatar Oct 04 '21 23:10 kenmcd

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.

psb1558 avatar Oct 05 '21 11:10 psb1558