Master-dependent features

Michael Rafailyk

Hello. I recently came across the mark feature and realized that, if generate the feature for one master (such as a Light for example), this positioning may not work for the other master with the different advance width (such as a Black, because it is wider and all the marks will be shifted incorrectly). Of course, it is possible to generate separate versions of the feature for every master, but.. what about instances and variable fonts?
So I am again faced with the question that some OpenType features related to horizontal positioning should not be common to the whole multi-master project, but should be dependent on specific masters.

I want to ask about your experience – how it works in different type design applications? Would Fontmake be useful for such tasks? Do you write your own scripts? Or do you just make precomposed glyphs?

Thank you.

Georg Seifert

In glyphsApp you would not make the make feature manually. You define anchors in each glyph and those will be interpolated for the instances. And from the anchors – on export – the mark feature is generated.

Simon Cozens

This is a really good question.

The mark feature is most often used for connecting two glyphs together, and this is most often does using anchors in the font editor. You stick one anchor on a glyph called the base - if you're doing a Devanagari font, you might put an anchor on something like "ka-deva" - and another anchor on a glyph called the mark - maybe it's "nukta-deva". There's a convention that the anchor on the mark has the same name as the anchor on the base but with an initial underscore, so we have a "nukta" anchor on "ka-deva" and a "_nukta" anchor on "nukta-deva", so the font editor knows which anchor goes with which. When the font is built, with whatever software, these get translated into attachment rules in the font such that when you have "nukta-deva" next to "ka-deva", the mark is moved so that its "_nukta" anchor sits atop the "nukta" anchor on the base.

So in that very common case, your question about doing things across multiple masters does not apply. This is because the font editor knows the positions of each anchor in each master, and can generate code which varies the anchor positions as the glyph shapes vary; it just works - and best of all, there's no coding involved.

People don't often manually write positioning rules, and especially not attachment rules, partly because they're difficult to visualise and partly because the syntax for specifying attachment in Adobe feature language is extremely tricky. However, there are situations when you would want to write feature code for other kinds of positioning, and at that point, your question definitely does apply. How to handle variable layout rules has been a challenge for the past few years.

There are two main solutions. In the Glyphs editor, you can define a number value for each master and use that number value in your positioning. For example, in Noto Naskh Arabic, there are a number of anchor attachment rules used when distributing a string of digits over the year sign. We want to choose a different set of anchors based on whether there's one digit, two digits, three digits or four digits in the string, so we can't use standard "visual" anchor positioning and we have to write our own rules.

One of those rules looks like this:

&nbsp; &nbsp; pos base year-ar <anchor ${year_width*0.275} 100> mark @YEAR_MARKS;<br>

The value of "year_width" is specified for each master in the master's properties, and then it's multiplied by the correction figure to form the anchor position which can vary across the designspace. But that only works for the Glyphs editor.

The other solution is a proposal I made to extend the Adobe feature syntax to enable variable positioning; that instead of writing a number value - for example, 20, to shift the positioning by 20 units - you write a string describing how that number value varies across the designspace. This is implemented in fontTools (and therefore in fontmake) and in Font Creator, but not in other editors.

One day we'll sort it out...

Michael Rafailyk

@Georg Seifert So the idea is to create mark code right on the export process. I didn't even think about it. It's very simple approach for masters and instances, thank you!

@Simon Cozens Yes, I just figured out that the names of base and mark should match. In the case of Latin diacritics, the situation is simpler because most marks are top-centered or bottom-centered, so the names can be class-like, such as top, bottom etc. But what I practice on is Hebrew, and there are more options for marks positioning. So I do naming as you described: base-mark.

Regarding the first solution. As I understand it works like the calc function in CSS. Interesting. So this is the tip for the Glyphs internal language and not a part of the OpenType specification. But we can use it right now in the case when the mark feature should be written manually.

And regarding the second solution. It sounds like percentage system used in a first solution but on the OpenType side. Brilliant. The question is how to make this syntax simple for the developer, because theoretically it can be written in different ways. I hope it will be implementent in a future because it's better to have the standard for all applications. However I understand that it will take years for application support to be broad enough.

Thomas Phinney

Michael Rafailyk said:

And regarding the second solution. It sounds like percentage system used in a first solution but on the OpenType side. Brilliant. The question is how to make this syntax simple for the developer, because theoretically it can be written in different ways. I hope it will be implementent in a future because it's better to have the standard for all applications. However I understand that it will take years for application support to be broad enough.

Unless I misunderstand, it’s not on the OpenType side. It is instead an extension to the Adobe FDKO syntax (and other syntaxes such as that for Font Creator) for describing how the position should vary. That would get compiled into a static value per master which would work in existing environments. The application support is on the font authoring side, not on the font-consumers side. So as soon as the authoring app you use supports it, you could use it.

Michael Rafailyk

Thomas Phinney said:

Unless I misunderstand, it’s not on the OpenType side. It is instead an extension to the Adobe FDKO syntax

Thanks for the clarification, I see the difference now.

The application support is on the font authoring side, not on the font-consumers side.

And it sounds even better if it is!