Predicate Tokens Compilation Bug

Glyphs
1

Hello, I’m trying to use predicate tokens to generate class members by matching against component names. These all work and opt+click shows a correct preview of all matching exporting glyphs:

@Tails = [$[name == "reh-ar" OR ANY layer0.componentNames LIKE "*reh*"]];

Another one I tried:

@Tails = [$[layer0.componentNames CONTAINS "reh-ar"]];

Or simply:

@Tails = [$[ANY layer0.componentNames LIKE "*reh*"]];

However, after exporting the font, the first example returns only uni0631 in the generated code, and the other 2 examples return empty sets.

I tried defining the class in a prefix, and as part of the classes UI, and also tried inlining it. All attempts to match against layer0.componentNames compile to an empty set despite the UI showing the correct preview.

What the .fea file from the temp folder shows:

### feature:10:calt ###
feature calt {
### open feature 'calt' ###
lookup calt_decompose {
	sub [$[layer0.componentNames CONTAINS "reh-ar"]] yeh-ar.init' lookup decomposeYehInit;
} calt_decompose;

lookup calt_decompose;
### close feature 'calt' ###
} calt;

What shows up under calt in the generated OTF font when I re-open it in Glyphs:

script DFLT;
language dflt;
lookup SUB_13 {
	sub [] uni064A.init' lookup SUB_2;
} SUB_13;
script arab;
language dflt;
lookup SUB_13;

Why are the compiled lists empty VS Glyphs UI?

2

After some additional testing, it compiles successfully only if exported as TTF!

OTF is still buggy as described in the OP.

Aside: for future reference, SUBQUERY also does the job

@Tails = [$[SUBQUERY(layer0.componentNames, $name, $name LIKE "*reh*").@count > 0]];
3

When you mentioned that it works with TT but not with OTF fonts, I thought it might be that the components are already decomposed by the time the features are compiled.

4

Upon checking the generated fonts, you’re right, it doesn’t even compile correctly for TTF, it’s skipping glyphs that end up decomposed.

But this doesn’t make sense from a user perspective, and from reading the tokens tutorials. I thought predicate tokens were like preprocessor directives that act at the source level, easing manual labour of picking and filtering glyphs, regardless of what the final export ends up containing.

It is also doubly confusing because the preview shows something, and the export does something else. Even a simple $[hasComponents == true] ends up skipping those.

I’m sure there are reasons for this, but perhaps there could be a flag to specify the stage at which these tokens get processed?

5

The predicates need to be applied on the final font (if you use anchor or metrics tokens). But before decomposition. I didn’t think about that, yet. I’ll see what I can do.

1 Like