search

simoncozens / fonts-and-layout

Fonts and Layout for Global Scripts
http://simoncozens.github.io/fonts-and-layout
Other
57 stars 10 forks source link

[OTVar] meaning of axis values #2

Closed PeterCon closed 7 years ago

PeterCon commented 7 years ago

Wrt this: "Where you start and end your axis and put your default is up to you; these values don’t necessarily represent points or percentages or anything else. They’re dimensionless quantities that are only interpreted in relation to each other. In this case, it looks like the width axis represents percentage width. But if you wanted to set up your design space with compressed = 1, regular = 2 and expanded = 3, it’s completely your choice."

That's incorrect. Please see the way that registered axes are defined in OT 1.8 -- it's in the 'fvar' table chapter.

For instance, your example discusses the wdth axis. The scale is defined as follows:

"Values can be interpreted as a percentage of whatever the font designer considers “normal” for that font design. Values must be strictly greater than zero."

There's also this additional note:

"Note: The OS/2.usWidthClass field (and also the CSS font-stretch property) use a scale that is different from the 'wdth' axis scale, but for which there is a defined correspondence using mappings provided with the description of usWidthClass in the OS/2 table documentation. For non-default instances of a variable font, the 'wdth' axis value can be used to derive the OS/2.usWidthClass value for that instance."

So, a wdth value of 200 should represent 2x the width of 100. Of course, applied to overall length of some arbitrary content, this will be a first order approximation. But the scale is essential for interoperability with e.g. CSS or with responsive layout algorithms that would use the value as a first approximation for how to select a wdth value to obtain some line-fitting result.

If people create fonts that don't conform to the scale definitions in OT 1.8, they should anticipate that their fonts will behave in unpredictable ways in different software or, at worst, not be supported at all.

PeterCon commented 7 years ago

This issue also applies to the wdth values in your examples:

<Axis> <AxisTag>wght</AxisTag> <MinValue>26.0</MinValue> <DefaultValue>90.0</DefaultValue> <MaxValue>190.0</MaxValue> <AxisNameID>257</AxisNameID> </Axis>

That's a font with width ranging from super-extra-thin to extra-extra-light. And this named instance, "Condensed ExtraLight"...

<NamedInstance subfamilyNameID="269"> <coord axis="wdth" value="79.0"/> <coord axis="wght" value="39.0"/> </NamedInstance>

Is actually (by the numbers) kinda-super-extra-thin. Not ExtraLight, which should use a wght value of 200.

simoncozens commented 7 years ago

Thanks for the feedback. I'll fix that up but it also sounds like we should file a bug in Noto Sans Khmer which is using those weight values in an unexpected way...

simoncozens commented 7 years ago

Edited to read:

There are two types of axes in the Font Variations specification: registered axes and custom axes. The idea behind a registered axis is that everyone should be able to use the axis in the same way. Weight and width are registered axes, because they're the kind of thing that a lot of fonts are going to use. So the specification also defines some semantics for the values on these axes, so that applications can produce an interface and user experience that is common across fonts. The width axis is defined as a percentage value of compression, with "100" representing the default font neither compressed nor expanded. The weight axis is supposed to work like CSS weights, with a standard regular master having a value of 400. (Noto is being naughty here.)

For custom axes, where you start and end your values and where you put your default is up to you; the numbers on custom axes are dimensionless quantities that are only interpreted in relation to each other.

In both cases, when we come to looking at the deltas, these values get normalized: -1 represents the bottom end of the axis, 1 represents the top end, and 0 represents the default. (not the middle!)

And bug filed with Noto.

PeterCon commented 7 years ago

Much better. Thanks!

From: Simon Cozens [mailto:notifications@github.com] Sent: Thursday, October 27, 2016 4:12 PM To: simoncozens/fonts-and-layout fonts-and-layout@noreply.github.com Cc: Peter Constable petercon@microsoft.com; Author author@noreply.github.com Subject: Re: [simoncozens/fonts-and-layout] [OTVar] meaning of axis values (#2)

Edited to read:

There are two types of axes in the Font Variations specification: registered axes and custom axes. The idea behind a registered axis is that everyone should be able to use the axis in the same way. Weight and width are registered axes, because they're the kind of thing that a lot of fonts are going to use. So the specification also defines some semantics for the values on these axes, so that applications can produce an interface and user experience that is common across fonts. The width axis is defined as a percentage value of compression, with "100" representing the default font neither compressed nor expanded. The weight axis is supposed to work like CSS weights, with a standard regular master having a value of 400. (Noto is being naughty here.)

For custom axes, where you start and end your values and where you put your default is up to you; the numbers on custom axes are dimensionless quantities that are only interpreted in relation to each other.

In both cases, when we come to looking at the deltas, these values get normalized: -1 represents the bottom end of the axis, 1 represents the top end, and 0 represents the default. (not the middle!)

And bug filedhttps://github.com/googlei18n/noto-source/issues/32 with Noto.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/simoncozens/fonts-and-layout/issues/2#issuecomment-256795723, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AMMjFrrIkfnq52TkqoJIDl22j_OOZ3YEks5q4S-pgaJpZM4KipbE.