Slight inelegance or real problem with two calt blocks?

Scriptor Abbatiſſæ's picture

I found myself having to use two different calt blocks, one upstream of a salt block and one downstream from the salt block. This is admittedly inelegant, but can it cause any real problems?

John Hudson's picture

There's nothing wrong with this, and I wouldn't assume it to be inelegant. The OpenType Layout model explicitly allows this, and in some cases it may be the most elegant solution to a layout challenge. I regularly make fonts with staggered lookups.

Scriptor Abbatiſſæ's picture

Thanks John. I feel less inelegant now. Can I get away with an extra liga feature bloc as well?

John Hudson's picture

You can have whatever arrangement of lookups achieves your purpose. You should try to be efficient, bearing in mind that the more lookups you have the greater the processing required during layout, but that doesn't always imply lumping all the lookups for one feature together; sometimes, staggering the lookups gains you efficiencies elsewhere.

twardoch's picture

Damn!

Scriptor, thanks for that. I've spent many years writing feature definitions code, and hit this problem several times, and never realized this simple solution.

I have always assumed that in AFDKO syntax, it's not possible to write:

feature ss01 {
sub A by B;
} ss01;
feature liga {
sub B by C;
} liga;
feature ss01 {
sub C by D;
} ss01;

But actually, your post made me realize that it is possible, and correct. The AFDKO compiler (in FontLab Studio) will issue a warning (feature already defined: ss01) but it'll still compile.

What this code does is, when expressed in AFDKO 2.5 format, which is closer to what happens in the real font, it will produce three lookups:

lookup L1 {
sub A by B;
} L1;
lookup L2 {
sub B by C;
} L2;
lookup L3 {
sub C by D;
} L3;

and will map those lookups to two features:

feature liga {
lookup L2;
} liga;
feature ss01 {
lookup L1;
lookup L3;
} ss01;

Since in the font, the it is the order of lookups that defines the order of processing of the glyph stream, this will have the effect that if only "liga" is active, only the lookup L2 will be executed, if only "ss01" is active, the lookup L1, and then L3, will be executed, and if both features are active, then the lookups will be executed in the order L1, then L2, then L3.

Brilliant. I never thought that this was actually possible to do in the AFDKO 1.6 syntax that FontLab Studio 5 is using. (In AFDKO 2.5, which is used by Fontographer 5 and DTL OTMaster, and will also be used by FontLab Studio 5.5, I assumed that this was only possible by placing the lookup definitions outside of the feature definitions. But I was wrong. The method shown above is also valid, and it works in AFDKO 1.6 already. Cool!)

Best,
Adam

twardoch's picture

Basically, this finding also means that the syntax:

feature ss01 {
lookup L1 {
sub A by B;
} L1;
lookup L2 {
sub B by C;
} L2;
} ss01;

can be equivalently expressed as

feature ss01 {
sub A by B;
} ss01;
feature ss01 {
sub B by C;
} ss01;

Very interesting!

Scriptor Abbatiſſæ's picture

My concern is about the two or three recompilations that might occur before it all comes up on an end user programme. How is one to know that a 'warning' such as you mention does not mean that a subsequent piece of programming might be too clever by half and decide to bring all the 'calt' coding together into one block so that all of it ends up upstream of the 'salt' feature anyway?

twardoch's picture

Scriptor,

there is just one compilation of the code, and what is in the font, gets executed by the OpenType Layout engine. The "blocks" are lookups. I've written about what they are and how they work here:
http://typophile.com/node/29898#comment-171706

Best,
Adam

Syndicate content Syndicate content