1.4.4  OS X 10.9.5
I’ve almost completed a script font with the lowercase designed to be self-connecting but which also includes an initial and final stroke so one could attach either or both strokes for completeness, as in use before/after a word space. It isn’t totally necessary that the user use these; they’re just there as an enhancement.
The problem is, I’ve now discovered there doesn’t seem to be an effective GSUB Lookup which will handle this enhancement, and I’ve tried several different ones. Reiner’s tutorial on feature coding was very helpful, but it still doesn’t get me there.
I’ve been working on this problem for several days, and other than adding another hundred or so alternate lowercase glyphs to handle this, I’m hoping there may be something I’ve overlooked about advanced GSUB coding.
I found feature code Miguel Sousa posted elsewhere which solved the problem, although imperfectly. While what I wanted to do can be achieved, in this particular font it doesn’t look that good.
A desirable fallback would have been to offer only beginning strokes at the beginning of the word as a stylistic set, but OpenType is too limited to support that properly. What happens is that a compound glyph (or maybe a ligature) of the space and beginning stroke is inserted into the text stream which could be a problem from the standpoint of the end user, for several reasons.
So it appears that manual insertion of the strokes is really the best option for the user, and that’s what I will do. Automation is wonderful when it works but in this case it is not a good solution.
Just like the good old days of hand composition!
Ligating with space is a bad idea. But exchanging .init with .init.ss01 should work nicely. What exactly is the problem? You can send the font to support at this domain.
The problem is given in my first post, above.
There aren’t any .init’s so simple substitution is not an option. I may make one and adapt Miguel’s code to that and see if I can make it work better.
Can you send me the .glyphs file, and maybe a screenshot of what should happen and what it should look like?
Tal Leming posted feature code techniques that he teaches his students on a new site Sept. 4. The url is http://opentypecookbook.com/index.html
But what about your problem, George? I think it could be solved with a one-to-many substitution, but I’d need to see your .glyphs file. You can send it to support (at) (this website without www), or res (at) (this website without www), if you prefer it handled by me alone.
I posted that information about Tal’s site in case anyone is interested. I probably should have made it a separate post.
I’m sending you the files today at the support address.
Thanks, I will have a look.
Was there an answer to this?
The answer was that feature coding as it exists today will not do what I needed it to do without creating a bigger problem.
I could work around the problem by adding another 112 or more alternate glyphs to the set to avoid the coding issue. Time does not permit that on the current project.