-
Notifications
You must be signed in to change notification settings - Fork 15
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
Scale in Type Network parametric axes #23
Comments
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. |
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. |
Peter: "If one font developer decides," 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. |
@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"? |
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'. |
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?
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, |
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>
.
|
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,
, 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 |
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.
The text was updated successfully, but these errors were encountered: