Glyphs' tutorial on #calt code method has problem with Chrome – any workarounds?

Don’t get too worried – code works in Glyphs itself and in apps but unfortunately not on the web, because for some reason Chrome (the most popular browser by far) substitutes all spaces with /nbspace. This makes it so that every word starts with a letter from the default set. Also, if a substitution’s trigger involves space at the start or the end of a word, it gets ignored.

I was thinking – is there some OT workaround for this? I tried creating /nbspace character in the font and adding it to code but that did nothing.

Maybe creating a fake space in your font and using it in your lookups instead? Don’t name it anything in relation with ‘space’. Just name it ‘fake’! Chrome will see it as a normal letter glyph and won’t ignore it.
On second thought, it might not work. That space might have been gone already before the substitution to a fake glyph takes effect.

Chrome does support calt. Try to avoid space in your feature code. Layout engines are not necessarily using the space glyph for displaying word spaces. What are you trying to do?

Font has 3 sets of contextual alternates. Code is written so that /space does not interrupt substitutions, so that it can go salt0-salt1-space-salt2. But because /space does not get recognized, each new word starts with the default set: salt0-salt1-space-salt0. It works properly in Safari but not in Chrome.

Try to avoid space in your feature code.

Well, that’s my point – even Glyphs tutorial on #calt uses /space.

There is nothing you can do if there is a bug in the layout engine.

You can try a different approach. Use some backward substitutions. Have a look at the ‘beowulferiz’ script from Mekkablue how it’s done.

I’m currently in contact with Chrome devs about this bug. Maybe something will be done about it.

beowulferiz script

Search found nothing.

Look for Effects > Beowulferize.

Status: WontFix

Thanks for the report. Chrome currently segments text on space by default for performance reasons.
Adding “text-rendering: optimizeLegibility;” disables that and us render the text as expected.

We’re currently in the process of changing our line layout implementation and that work will fix this without the need for any extra css properties.

Until then though hopefully the workaround suggested above is sufficient for your use case.


1 Like

That is interesting to know, thank you for reporting back, @Eames.