Typophile

OT features problem

Vít Šmejkal

Hello everybody,
I'm working on a new font and I would like to make few non-standard OT features. But I cannot figure out how to make them work:

The First one should make a special underline or strikethrough effect. It would be most probably Stylistic set. I want it to insert a special zero-with "underline" character I made after every single glyph in my font except for space (and maybe few more glyphs). I have made a huge class including all characters but space, and tried to make some substitutions, but no success yet.

The second feature should make quite simple substitution for letter pairs like "oo" "ee" "ll" "gg". It would not be problem if there wasn't so many combinations to list them all individually. Let's suppose two classes are defined: @class01 (o e l g) and @class02 (o.alt e.alt l.alt g.alt). I thought something like sub @class1 @class1 by @class1 @class2 but this kind of substitution does not work.

This feature could also work in two ways:
- substitute just the same letter pairs like "o-o" to "o-o.alt" (and ignore "o-g"), or
- substitute all combinations from defined classes, e.g also "o-g" to "o-g.alt"
I would put this in Calt feature, but it also does not work yet :(

Could anyone help, please?

instead of
sub @class1 @class1 by @class1 @class2
you should use
sub @class1 @class1' by @class2

The tick (') indicates the piece that should be substituted for.
That should work whereas your "many-to-many" substitution won't.

Thank you for the tip! It works :)
This feature substitutes all the combinations (not just two identical characters one after another) which works quite well for me.

Any suggestions for the first Feature?
What I want is actually to change the string like "abcd" to "aXbXcXdX" only with exception for space (or few more characters).

I have been trying something like sub @All by @All X and few more, but still no success...

Also is there any command which can "invert" current class to its opposite? This could help to avoid creating very huge classes. For instance my class @All would contain hundreds of glyphs while its negative only one or two. This could be very useful.

Any suggestions for the first Feature?
What I want is actually to change the string like "abcd" to "aXbXcXdX" only with exception for space (or few more characters).

One to many substitutions can only be applied to individual glyphs, not to glyph classes, so you'd need something like:

sub a by a X;
sub b by b X;
etc.

You might want to look at the adobe feature file syntax guide

As for 'inverting' classes, that's best done using the ignore keyword, also described in the above guide.

André

Thank you André,
this should definitely work but in my specific case there would be hundreds of substitutions. I'm still hoping there could be a more sophisticated way to do this... ?

(v)

Unfortunately, there's no shorter way of doing this of which I am aware.

Also, be advised that a number of major applications (including the Adobe CS applications) don't actually support one-to-many substitutions so if you do go this route your font will not work for all users.

You might achieve better results by simply including underlined variants of all applicable glyphs.

André

Also is there any command which can "invert" current class to its opposite?

Take a look at how “ignore” is used to substitute initial and final alternates, after or before a space/punctuation; this is primarily in script fonts.

(It’s in the Fontlab manual.)

Vit, this topic should be in the BUILD forum.

Thanks for you explanation.

I think I will do it in slightly different way, however it wouldn't be as user friendly as I wanted. But it is not that principal "feature" to make so many alternates.

To achieve the desired "underline" effect, the source string should be a_b_c_ and then simple substitution will change the underscore to its special.alt version.

Although it would be quite tedious for the user to write down all those underscores. It would be much pleasant just to select desired portion of text and then apply Stylistic set. On the other hand it would be mostly applicable just to one or few word, so it's not that big deal.

Thank you anyway :)

I'm sorry Nick, I will be more careful next time.

(v)

The simplest thing to do is to create alternate glyphs that include the underscore, for every character. “Sophistication” would be needless complexity—featuritis—in this instance.

If you’re working in FontLab, the “new glyph” command will make your alternate glyphs with the original glyph vector paths and width, which is a huge timesaver.

Class size is not an issue: if the end users have access to software that supports OpenType features, then their hardware is powerful enough to blast through fonts with large numbers of glyphs. That’s digitech synergy.
I’ve made fonts with multiple alternates of every character (for pseudo-randomization), and they work just fine.

The worst that happens is that documents with many pages and much text take a fraction longer to open, but that fraction is marginal, compared to, for instance, the lag caused by image files.

I think I will do it in slightly different way, however it wouldn't be as user friendly as I wanted. But it is not that principal "feature" to make so many alternates.

To achieve the desired "underline" effect, the source string should be a_b_c_ and then simple substitution will change the underscore to its special.alt version.

This seems like a misguided approach. Requiring the user to enter underscores will not only add extra work for them, but it will interfere with spellchecking, hyphenation, etc.

Adding underlined alternates would require very little time or effort on your part since its a purely mechanical procedure which doesn't involve drawing any new glyphs -- just copying the old ones and then adding the underline.

André

Thank you both.

May I have one more question? If class size is not a big issue, do also features with lot of substitutions (let's say 400) work fine? It still seems to me better to solve this problem via features than add so many new glyphs for no "real" reason (even if the "auto-generation" would be quite easy)

My humble opinion is : simplicity is best. A new glyph is the simpliest solution to 99% of problems, and you can propose a single substitution feature with it, like calt, salt or clig, supported by the largest panel of softwares. More simple will be your font encoding, more easy (and enjoyed) will be your font to be used.

Vit, it seems you are concerned over font file size vs. processing speed. Remember that each of the characters in the user's text in your font has to be processed. It takes only one step in the feature table to swap a glyph for an underlined one, or it takes a dozen steps to coax precisely the right "underline" character into position.

Swapping one glyph for another is an extremely efficient operation due to the way Opentype feature tables are internally represented. One could say it's the cornerstone of the entire features idea.

Thank you all for you advices!
I'll keep it on mind.

André: what is your

[..] be advised that a number of major applications (including the Adobe CS applications) don't actually support one-to-many substitutions so if you do go this route your font will not work for all users

based on? InDesign CS4 seems to support this; a ligature 'fi', when put in small caps, changes to "small cap f, small cap i", not a single "f_i.smcap" character. It appears as a single selectable character inside InDesign but on exporting to PDF one can select each single character.

Theunis,

I'm actually still using CS3, so things may have changed. But in CS3 one-to-many substitutions are *definitely* not supported, as can be confirmed by simply adding random stylistic sets to a font which involve such substitutions and noting that they don't work.

Even in CS3, though, hardcoded fi will be rendered as FI regardless of whether this glyph is included in any opentype feature. This is because InDesign does some preprocessing before applying a font's features. fi (UFB01) will be converted to either fi (U0066+U0069) or FI (U0045+U0049) before any case-related GSUB features are applied to this sequence. This conversion is done by InDesign's type engine, not by any type-2 lookup defined by the font.

André

Captured from web.archive.org on 20 Jul 2012. view this capture