Scale in Type Network parametric axes

[PeterCon]

The descriptions for all 11 axes in the Type Network proposal all specify the following for scale:

Scale interpretation: Values should be interpreted as per-mille-of-em.

That defines the units of measure, but they don't fully define a scale because they don't specify what is actually being measured. It could refer to anything for which per-mille-of-em could possibly make sense; e.g., the distance across the widest opening of ink traps in glyph 72.

The details for each axis should specify not just the scale but also give some indication as to what is assumed to be measured.

[dberlow]

Hey Peter,

I'm not sure I understand, but thanks for taking the time to read through this.

Values are given in ıoooths. The scale is ıoooths and the value may be interpreted as a per mille along with all the other per mille values, or it can be converted to a % of the default.

Then I get lost. Referring to "anything for which per-mille-of-em could possibly make sense" to whom or what? Are we talking for developers again?

Unlike most of the registered axes, and those others proposed so far, our proposed names alone are pretty descriptive of the Kind of Measure they refer to. So, the details proposed for each axis already specify not just the scale but give an indication of what is to be measured. E.G. X direction, opaque, ad a value representing a script, a character group, or the whole font, is good for everyone.

In Latin Y, this is particularly true, down to the kind of feature e.g. the Latin l.c. has historical and conventional need for variation of descenders. But I am hesitant to assume which descender to specify. In X I'm not even sure what to say, as XTRA and XOPQ, by convention, must reflect the whole glyph repertoire, i.e. one value is expected for the weight of all the glyphs of 1 instance, even if said font contains all of unicode. There, the Latin Designer has no business assuming anything in the world.

Or, do you mean, not just the documentation, you want registered parametric axes to refer to particular glyphs, point indices and projection vectors via specification-change? We could demo this if you'd like., but I think that's perhaps in a different scope, and a different version.

Let me know Thanks.

[PeterCon]

We need to know in each case what is being measured, not just what the units of measurement are.

Yes, for xopq what is being measured is the x-direction size of some opaque thing, but what opaque thing?

If one font developer decides, "I'll make it the horizontal thickness of the stem of T", but another font developer decides, "I'll make it the average of horizontal thicknesses of the left and right stems of U" (in a contrasty font like TNR), and yet another font developer decides "I'll make it the horizontal serif-tip-to-serif-tip at the bottom of stems", then everyone is measuring something entirely different, and there is little gained by defining units so specifically as per-mille-of-em.

I can understand being hesitant to specify a particular letter. But there needs to be some kind of indication as to what is intended. Otherwise, we can't expect any consistency, in which case there are limited interop benefits --- we're still in the OS/2.usWeightClass situation.

[dberlow]

Peter: "If one font developer decides,"
Re the examples, if there is a registered axis called x opaque in a variable font, it is documented, valued and demoed as it is; as control of the x opacity of each instance in the font, and a developer decides:
a. to measure one thing while varying another.
b. to measure and vary anything that is not in the class of x opacity.
c. or to give an inaccurate value to that which is being varied
...how is what you are suggesting going to stop them?

But there is a larger issues way below, anyway.

"we're still in the OS/2.usWeightClass situation."

I disagree, and we have demonstrated that there is a lot to be gained from this framework and it's values, without explicit reference to a glyph id and point index, or a particular glyph alignment via its point index. When we complete demonstrations of parametric width and weight vs. wght and wdth, this will be cleared, I hope.

And finally, if we document exactly which glyph and which points, or shapes in general, are being measured, that would take a very long time as it must be done in xopq (and xtra), for each of the scripts in the world. This is because any script can be the dominant script of a variable font, and the other scripts have to follow along with visually compatible xopq values.

And that is dictated by conventions that apply to weight, width and optical size, where the user, all users everywhere, expect any given instance's weight, width and optical size, to apply to every single glyph of that instance. There is one xopq, one xtra and one opsz per instance, regardless of how many scripts the variable font contains.

[PeterCon]

@dberlow : I'm not thinking of someone disregarding the spec --- "It says one thing but I'm going to do another." I'm thinking of someone wanting to follow the intent of the spec and trying to figure out how. In the case of x opaque, how do I determine if I'm following the intent of "x opacity of an instance"? I know it refers to horizontal measures of ink, but which ink?

Perhaps you could explain how this is done in Amstelvar: the default instance has an x opaque value of 88. What can I expect to find will be .088 em?

Or, perhaps this would be helpful (not for the spec but just for understanding in this discussion):, could you tell me how I would measure the x opacity of a single glyph in the case of, say, Amstelvar "l", "s", "d" and "m"?

[dberlow]

Peter,

Thanks for the simpler task.

"... in Amstelvar: What can I expect to find will be .088 em?"
The H stem. It looks in the image as if it measures around 2 x 88 because of the measuring tool, overlapping contours and that the measure is on a 2048 em. Per mille, it's 88.

(If some images show up above, they are named for the parametric axis they show the measurements of the Amstelvar Default H, where the values come from.)

"...how I would measure the x opacity of [...] Amstelvar "l", "s", "d" and "m"?"

I measure where shown in the images (I hope appear below). Any stem of a glyph, an average those stems, or a a total of a glyphs stems, may be useful under different circumstances.

I relate all the Cap stems to the H. Then relate the n to the H. Then relate all the lowercase stems to the n, after checking that the lc o stem works with to the H-derived uppercase O stem.

[tiroj]

I'm sympathetic to David's point about the difficulty — impossibility — of identifying key glyph dimensions across all the world's scripts. Further, the challenge to interoperability between fonts is compounded by multiscript fonts: if a font supports both Latin and Devanagari, in some nicely balanced weight design, and has opaque parametric axes with a scale based on the Latin letter measurements, it is hardly likely to be interoperable with a Devanagari-only font whose axis scales are based on measurements of Devanagari letters.

This is a similar problem to the — still unsolved — one of extending the CSS type-size-adjust property to be meaningful for scripts without Latin-like x-height. I came to the conclusion in that case that it's only possible with an external, standard measure against which individual fonts have a relative measure. I suspect the same might apply in the case of per mille parametric variation axes.

Yes, this implies something like a standard design: perhaps even a single glyph with a set of topographic features representing a default value on the associated parametric axes? So instead of having variable font parametric masters plotted on a scale that corresponds to measurements of their own features, we would assign the masters scalar values relative to that external standard, in such a way that the topographical features of the font at the default value (with possible avar intervention if a font developer wants to use a font-specific scale for development) balance with those of the standard model.

Yes, this means defining the standard model, and including it somewhere in the font format specification, but I don't see another way except, perhaps, picking some font — Amstelvar? — and saying 'This is the standard'.

[PeterCon]

I'm not expecting some universally-adopted key glyph dimensions, exact comparability between fonts, or even precise consistency between fonts. Just some clearer guidance, perhaps, "Scale: horizontal thickness of a typical vertical stem, in per-mille of em" with elaboration in the Add'l Info field to say that it's not expected that all stems will have this thickness, or even that any stem will be exactly this thick.

@dberlow : Would that be in line with what you have in mind in the case of xopq?

Any stem of a glyph, an average those stems, or a a total of a glyphs stems, may be useful under different circumstances.

Spec'ing in terms of any stem or an average of stems seem fine. But I think it could be problematic to describe the measure saying it could be a total of a glyph's stems: I think that could lead to different fonts applying the scale in very different ways, unless there is some guidance as to when that would be appropriate,

[dberlow]

So I think we've got some work cut out for us at TN. Based on the accumulation of both progress and questions raised to both support ad extend that progress: 1. is over on the other thread. 2. we need a complete set of recommendations for measurement a. of Latin Y alignment values, according to the description of Y in number 1. b. of Latin X values, an YOPQ for use in Latin World-Script measurement?

…

On Wed, Dec 20, 2017 at 1:20 PM, Peter Constable ***@***.***> wrote: I'm not expecting some universally-adopted key glyph dimensions, exact comparability between fonts, or even precise consistency between fonts. Just some clearer guidance, perhaps, "Scale: horizontal thickness of a typical vertical stem, in per-mille of em" with elaboration in the Add'l Info field to say that it's not expected that all stems will have this thickness, or even that any stem will be exactly this thick. @dberlow <https://github.com/dberlow> : Would that be in line with what you have in mind in the case of xopq? Any stem of a glyph, an average those stems, or a a total of a glyphs stems, may be useful under different circumstances. Spec'ing in terms of any stem or an average of stems seem fine. But I think it could be problematic to describe the measure saying it could be a *total* of a glyph's stems: I think that could lead to different fonts applying the scale in very different ways, unless there is some guidance as to when that would be appropriate, — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB3ajkOVPb1kf-xSHChcAVu2wqqDCA9zks5tCU_tgaJpZM4RGHmj> .

[davelab6]

I realise this thread is what I was just referring to, and what @tiroj had been referring to at lunch yesterday.

I had a call with @dberlow this afternoon and his answer, to the question @PeterCon poses above,

they [ TN axis proposals ] don't specify what is actually being measured.

, as I understood it, and which makes sense to me, is that what is actually being measured is relative.

That is to say, internally coherent to the "total" typeface (I could easily say "the 🤯 typeface" haha) but not anything actual such that direct drop in replacement interoperability makes sense.

If I got that right, then while strict interoperability is limited, Registration is still useful and desirable because it gives the concepts a central definition and builds up social knowledge about what they are and what they do.

But maybe we don't need Microsoft to be the Registrar for that