Calt feature interrupted by line breaks

i’m working on a font with a calt feature including 3 cycling classes, everything works fine so far. But i realised that in adobe apps (indesign, illustrator) cycling is interrupted not only by paragraph returns, but also by forced line breaks, automatical line breaks and even when resizing the text frame.
This leads to the situation, that when you have the same word as first word in a new line it always looks identically. It seems the cycling process always restarts on the beginning of a new line.
How can i avoid this unaestehtic phenomenon?
(In Mac apps like TextEdit it’s the same situation with the difference that resizing the window does not harm the cycling.)

I know i could manage a manual workaround by changing the stylistic sets for this first word’s characters, but i’m afraid some future users won’t do that.
Can i do something about this by adding something »magic« to the feature code?:slight_smile:
Any ideas on solving this problem would be highly appreciated.

You could add some backward looking substitution. I believe the Beowulferize script from @mekkablue is generating code that could give you some hints.

But you won’t get around line starts. This is where Adobe apps rest their feature context. I don’t think there’s anything you can do in a font to circumvent it.

What I have done once is add a hardly used character as zero width glyph (I used micro) and out that one in all cycles. So at the beginning of the line, you could insert a few of these to advance the cycles.

But you’ll mess up your text, of course.

Thanks for your replies @GeorgSeifert and @mekkablue!

So that means, if I try to manage the zero width glyph »trick«, users still need to take some manual action to avoid the cycling-interruption, but it would be more comfortable (just press a key on the keyboard once or twice at the very beginning of the new line) than fiddling around in the app’s OpenType settings or manually changing the stylistic sets for each character of the first word via aalt, right?

Yes. But you can still solve it. Your code only looks at what comes before each glyph. But you can also look at the following ones. That means that if you type, everything is jumping around a bit but that is not a problem.

thanks @GeorgSeifert, i’ll think about this!

I have one more question which is somehow related to the topic above:

I wrote some calt code that replaces the space (0020) between two exact defined words and substitutes it by a thinspace (2009) which is part of my font file.
Again, works fine, but:
In InDesign the thinspace generated by the feature shares the same width, but does not share the same hidden character as the default inDesign thin space, althoug it refers to the exact same unicode 2009 in the glyphs palette. Instead it shows the same hidden character as a regular space.
This alone would not be a big thing, but usually the inDesign thin space also has a nonbreaking fuction, which does not work with my feature generated thinspace, seems as if the nonbreaking function disappears.

I already had a look into the glyphs window in glyphs app, but could not find any nonbreaking thinspace or similar which i could generate and implement into the feature code.

Anyone got a clue what I’m doing wrong?