Variable height axis font

Art Grootfontein

Hey there !
I’m working on a variable height font.
As variable height axis is not really something the variable font format is made for, I’m facing some issues and I have some questions I’d love to share with those who had this weird idea too ! 😅
https://www.youtube.com/watch?v=MG3T7bruJLg

Has anybody else tried to work on variable height font ?

Aaron Bell

One thing to note is that the MVAR table is not really well supported right now. Not to say you shouldn't make this (as you definitely should!) but you may have some odd results in testing. 

Hrant Հրանդ Փափազեան Papazian

@Art Grootfontein Wouldn't it be more robust to make a width axis and vary the point size?

Art Grootfontein

Thanks for your answers !

I have to say I don't know much about the MVAR table, @Aaron Bell but I hope it won't bother me too much…😰

It could make sense, @Hrant H. Papazian, but my goal is to play on both axis like in this example to allow designers to create rich typographic compositions.

But varying the point size would not allow that option, would it ?

https://youtu.be/PHXFMMb5JHs

Thomas Phinney

@Hrant H. Papazian It would need to be a width-LIKE axis to have a predictable relationship with point size. As in, the needed relationship to get the desired effect would be non-linear.

That is, for double the size you want half the width. For triple the size you want 1/3 the width. This needs to be a very non-linear axis, if it is expressed in units that will enable the use the designer has in mind.

Nick Shinn

Variable x-height small caps font. 

Thomas Phinney

I believe @Aaron Bell is right. Which means that, in the near term, the way to do this to best avoid problems might be to simply set the NOMINAL cap height to the same as the maximum cap height of the axis. Set the other ascent/descent values to equivalent maximums.

That may have its own consequences, possibly causing damn big line spacing in some apps, but should work and avoid collisions.

Art Grootfontein

Thanks @Thomas Phinney I've indeed chosen the maximum cap height of the axis, so it doesn't overlapp, but the default size of the characters seems really small then…

And the selection of text is a little bit uneasy as the height of the clickable zone does not match the letter height.

@Nick Shinn i don't understand what you mean exactly. Could you please explain what you have in mind ?

Thomas Phinney

Hey Art,

Those are both unsurprising issues. The overall machinery here really isn’t set up to deal with this, so the cost of being able to cope well with the extreme is, the regular-height glyphs will be small.  

Art Grootfontein

You're right, @Thomas Phinney I have to set as default size something medium so users don't feel uncomfortable … at least before playing with sliders ! 😄

Another thing now : as I want this font to be fully functionnal, I've tried the Monotype validator to see if something goes wrong, and guess what ? EVERYTHING goes wrong ! 😱

I think I got the whole pack of errors… Do the variable fonts format can cause some of them ? Do you guys already have tested variable fonts with that kind of validator ?

Thomas Phinney

There are a variety of validation and checking tools out there. Font bakery is one I use daily integrated into the build process. Partly because I am doing work for Google, but regular testing is a good thing.

Adobe’s AFDKO CompareFamily and Microsoft’s Font Validator can also be helpful. Although knowing which errors NOT to worry about is the tricky part.

For these particular errors:

self-intersection: might be an error on your part, depending on what you have. Would need to see some specific glyph contours to judge.

Correct winding directions: usually can be fixed automatically, most font editors can do this.

Vertical metrics: yes, probably an issue. Details needed.

Install on Mac? This is a symptom of something unspecified, need more details

Spacing: sounds like an issue. Again, details and examination needed.

Mark Simonson

Self-intersecting glyph contours are flagged by the Monotype validator since they are not allowed in non-variable fonts, but are not necessarily a problem with variable fonts since they can have overlapping contours. Pretty sure I had the same warning when I submitted a variable font for the first time and the font was still accepted.

The icons indicate warnings, not errors. They may or may not be problems. You can open the disclosure chevrons to see more detail.

Art Grootfontein

I'm always surprised and grateful to those like you, @Thomas Phinney & @Mark Simonson  that give their time and share their knowledge with so much generosity…

Thank you for your help, I really appreciate

I didn't know those font testers, I'm going to look at all that stuff right now !

Regarding to the monotype validator errors, I already faced some of these issues with my previous fonts, and I think I can handle them (self intersection, vertical metrics, spacing)

But I don't know what to do with the incorrect winding directions as the usual method doesn't work (I work with Glyphs 3 and usually it can be solved thaks to the Correct Path direction function)

But what I'm afraid of is the problem with Mac OSX that seems really bad… I don't understand what is the problem ! Here are the details :

Mark Simonson

I would recommend contacting foundry support at Monotype about this. They don't always answer right away, but you should be able to get more helpful explanations for the warnings.

Thomas Phinney

Yes, an error like “failed to parse table” that does not even tell you WHICH table it failed to parse is… not entirely helpful. 

It is a fine idea to contact Monotype as Mark suggests! That said, I will also add that… the wording of that check and error suggests to me that perhaps Monotype is running Apple’s ftxvalidator. If you are running Glyphs, you are on a Mac, and could also run that Apple tool directly and see if you get more specific information from it, directly.

And: you’re welcome. We all get out of our current depth sometimes and need help. Still happens to me, too. 

Art Grootfontein

Thanks again both of you, guys.

I will try to clean everything I can in the font before contacting monotype support.

I have to see how to install/use ftxvalidator, but I'm not really comfortable with this github thing  

In the meanwhile, I tested the font with the FontBook validator on my Mac and everything seems OK !

Michael Rafailyk

@Art Grootfontein

But I don't know what to do with the incorrect winding directions as the usual method doesn't work (I work with Glyphs 3 and usually it can be solved thaks to the Correct Path direction function)

Make sure you select all characters in the font before using Correct Path direction.

Here's an answer for FontLab, but it might help you understand the basic principles of winding directions in PostScript and TrueType outlines. Read all the comments below:
https://typedrawers.com/discussion/comment/52835#Comment_46391

Art Grootfontein

Thanks @"Michael Rafailyk" > I tried with the Glyphs option (Correct path direction) but the Monotype validator still talks about winding directions…

Mark Simonson

You can also manually check. It's possible for the automatic correction to fail in some cases. 

Art Grootfontein

How can I check the correct direction manually, @Mark Simonson ?

Michael Rafailyk

Art Grootfontein said:

How can I check the correct direction manually, @Mark Simonson ?

Art Grootfontein

OK I was afraid of that kind of answer !

Thanks @Michael Rafailyk

Mark Simonson

To simplify this task in Glyphs, you can create a filter that only shows glyphs that contain paths:



... and then hold down the shift key in the edit view as you move through the glyphs to only show the filtered glyphs.

Erwin Denissen

Maybe you have a self-intersecting contour.

Michael Rafailyk

Just found out some strange things about wending directions. In this test I work with PostScript outlines with PostScript contour direction in FontLab 7 and checked the files after export (one Master and multiple Masters).

Export OpenType TT (ttf) + All curves to TrueType = TrueType direction (as expected).
Export Variable TT (ttf) + All curves to TrueType = PostScript direction (hasn't changed).

I wonder why the contour direction hasn't changed for the variable font? Sure I can convert direction manually before the export and will have correct result, but very interesting why it happens.

Dave Crossland

Hrant H. Papazian said:

@Art Grootfontein Wouldn't it be more robust to make a width axis and vary the point size?

Yes! 

The width slider could be used to create the same effect as the height slider, if the "Tall" master was repositioned in the design space as the width-min. 

So, the height axis is not adding unneeded data to the font file, but the MVAR complications suggest to me this is not worth while. I would reject such a design space if submitted to Google Fonts on this basis.

I would like to see more design apps with VF support allow convenient height scaling using the OpenType-registered Width axis.