Features in edit window doesn't respect placeholders


#1

With the bottom left selector you can tell Glyphs to show the effect of OpenType features in the edit window. But I’ve found contextual features like calt don’t take into account placeholders (created with Cmd-Opt-Shift-P).

For example, I have an /f that has an /f.short contextual alternate, it would be nice to be able to put a placeholder after an f and then step the cursor through a bunch of letters to verify the substitutions.


#2

Hmmm. Not sure about it. Then there’s a discrepancy between user selection and display. Will think about it though.


#3

I don’t follow what you mean by discrepancy between user selection and display.

Here’s a screencap which shows what I’m talking about.
Top row is typed in as /f/space/f/i/space/f/[placeholder]

Since “calt” is selected as a feature, the second /f becomes /f.short. But the third /f before the placeholder isn’t changed by the feature though the placeholder is picking up the i that the cursor is on in the second row.


#4

Ah, I see. Now I get it, sorry. Yes, that appears to be a bug.


#5

That is not a bug. The placeholder is supposed to show the current glyph. And mostly you are interested in the glyph that you are actually editing. That can be changed by the features. So the placeholder is set after the features are applied.


#6

Do you not think my use-case example is a useful employment of the placeholder feature (or would be if it worked the way I’m expecting it to)? The whole point of a placeholder is to easily test various letter combinations, and in my view there’s no reason to assume that the “variable” letter would always be the one that you’d want to edit from those combinations.


#7

I would also consider this a bug. If the calt feature is switched on, the user clearly wants to test the alternates. Even if you’re interested in the ‘i’, you still need to see whether it’s going to crash into other letters.