Need help – #calt works differently in apps and on web

Eimantas Paškonis
Eimantas Paškonis Posts: 91
edited August 2017 in Font Technology
  • Handwriting cursive font with 3 sets of alternates, separated into vowels and consonants.
  • /space is made to be ignored when substituting, so that it can go con0-con1-space-con2 etc.
  • The code (for consonants) looks like this (@etc contains all the non-alternating symbols like /space or /period):

<p><b>sub</b> @con0 @con0' <b>by</b> @con1;</p><p><br></p><p><b>sub</b> @con1 @con0' <b>by</b> @con2;</p>
<p><b>sub</b> @con0 <b>[</b>@vow0 @vow1 @vow2 @etc<b>]</b> @con0' <b>by</b> @con1;</p>
<p><b>sub</b> @con1 <b>[</b>@vow0 @vow1 @vow2 @etc<b>]</b> @con0' <b>by</b> @con2;</p>
<p><b>sub</b> @con0 <b>[</b>@vow0 @vow1 @vow2 @etc<b>]</b> <b>[</b>@vow0 @vow1 @vow2 @etc<b>]</b> @con0' <b>by</b> @con1;</p>
<p><b>sub</b> @con1 <b>[</b>@vow0 @vow1 @vow2 @etc<b>]</b> <b>[</b>@vow0 @vow1 @vow2 @etc<b>]</b> @con0' <b>by</b> @con2;</p>
<p><b>sub</b> @con0 <b>[</b>@vow0 @vow1 @vow2 @etc<b>]</b> <b>[</b>@vow0 @vow1 @vow2 @etc<b>]</b> <b>[</b>@vow0 @vow1 @vow2 @etc<b>]</b> @con0' <b>by</b> @con1;</p>
<p><b>sub</b> @con1 <b>[</b>@vow0 @vow1 @vow2 @etc<b>]</b> <b>[</b>@vow0 @vow1 @vow2 @etc<b>]</b> <b>[</b>@vow0 @vow1 @vow2 @etc<b>]</b> @con0' <b>by</b> @con2;</p>

  • Everything works in apps but not when testing font online. I test it at http://www.impallari.com/testing/index.php. Pinging @pabloimpallari
  • For some reason substitution gets interrupted by /space. So it goes con0-con1-space-con0. Every word starts with the default set (con0/vow0).
  • There's also a substitution for "oldstyle" /d. Don't judge – I have to mimic the handwriting. Most of the time it uses this:
sub d' space by d_old;
  • And once again – it works in apps, but not online. What happens is this:
  1. If string is "@letter /d" – it doesn't change
  2. If string is "@letter /d /space" - it does change
  3. If string is "@letter /d /space @letter" - it does not change
Tagged:

Comments

  • Erwin Denissen
    Erwin Denissen Posts: 302
    Which browser(s) did you use?
  • Eimantas Paškonis
    Eimantas Paškonis Posts: 91
    edited August 2017
    Chrome. Tested in on Safari and it works as intended...
  • Khaled Hosny
    Khaled Hosny Posts: 289
    Try Firefox as well. Both Chrome and Firefox try to speed up text layout bay caching words (split at spaces), but both have logic to disable this when there are lookups involving the space, but there might be a big in Chrome making it to think your font is safe to cache this way.
  • Adam Jagosz
    Adam Jagosz Posts: 689
    edited August 2017
    I also had issues when trying to replace space by uni2009 in Chrome. Firefox and Edge were okay. Might be that Chrome treats whitespace in its own devious ways.
  • Erwin Denissen
    Erwin Denissen Posts: 302
    A year ago Firefox didn't support kern pairs when a space character was involved, but that was fixed at the end of 2016.

    There are many more layout engine differences and/or issues related to OpenType layout features; probably too much to document, but we have some on file here.
  • Eimantas Paškonis
    Eimantas Paškonis Posts: 91
    @Khaled Hosny @Erwin Denissen

    Firefox is weird. It does activate /d substitution but has the "every word starts with default set" problem as Chrome.
  • Khaled Hosny
    Khaled Hosny Posts: 289
    How are you making space ignored during substitution?
  • Eimantas Paškonis
    Eimantas Paškonis Posts: 91
    It's in the code above. Groups in brackets are there to allow consonants to be replaced even if separated by vowels/spaces (or vice versa).
  • Eimantas Paškonis
    Eimantas Paškonis Posts: 91
    edited August 2017
    Found something else. If I paste the space from Safari into unicode checker, it's shown as regular space (U+0020). Meanwhile Chrome's is "no-break space" (U+00A0). It seems Chrome does not recognize space in OT code. If I use any other character from the @etc group (period, comma, hyphen...) the substitutions then work. I tried adding /nbspace glyph to the font and code but it did not fix.

    There's another weird thing. The code for /d substitution lookup (I have it named "d_old" and not "d.old" due to sorting):
     

    <p><b>ignore</b> <b>sub</b> @etc d';</p>
<p><b>sub</b> d' @etc <b>by</b> d_old;</p>
<p><b>sub</b> @vow0 @con0 d' <b>by</b> d_old;</p>

    The /d in "and" gets substituted while /d in "bad" does not. Apparently Chrome processes only the vowel-consonant line. However, if I put non-space character after the "bad", /d gets replaced.

    All in all, there's something weird going on with Chrome's /space character.

  • Thomas Phinney
    Thomas Phinney Posts: 2,896
    Random thought: Did you try also including the non-breaking space in your code alongside the space, to see if that made things work in Chrome?
  • Eimantas Paškonis
    Eimantas Paškonis Posts: 91
    edited August 2017
    @Thomas Phinney Yes I did, it did not fix it.
  • Erwin Denissen
    Erwin Denissen Posts: 302
    edited August 2017
    Eimantas Paškonis said:

    There's another weird thing. The code for /d substitution lookup (I have it named "d_old" and not "d.old" due to sorting):
     
    <b>sub</b> d' @etc <b>by</b> d_old;
    <b>sub</b> @vow0 @con0 d' <b>by</b> d_old;</code><pre class="CodeBlock"><code><b>ignore</b> <b>sub</b> @etc d';<br>

    The /d in "and" gets substituted while /d in "bad" does not. Apparently Chrome processes only the vowel-consonant line.

    Confirmed. Definitely a bug in Chrome (and Vivaldi). Firefox and Edge work just fine.
  • Khaled Hosny
    Khaled Hosny Posts: 289
    I'd report the bug in Chrome bug tracker in this case.
  • Nick Shinn
    Nick Shinn Posts: 2,216
    The <space> character is a real Unicode character, just like letters, punctuation, dingbats and emojis.

    Changing it violates text, why is this practice even contemplated by layout programmers? 
  • John Hudson
    John Hudson Posts: 3,227
    Changing it violates text, why is this practice even contemplated by layout programmers? 

    There's quite a lot of processes in which Unicode characters are replaced, decomposed, or combined in a buffered state as part of layout and display of text. The buffered state means that the underlying text of the document is not being changed, and the character processing is happening only for layout and display purposes. In some cases, Unicode actually expects such processes to be performed, e.g. splitting of two-part vowels signs for Indic scripts.

    Obviously, though, character processing that actually breaks or inhibits correct layout for subsequent glyph processing isn't helpful.
  • Eimantas Paškonis
    Eimantas Paškonis Posts: 91
    edited August 2017

    Update

    This is how it looks in Chrome:


    And this is how it looks in Safari (as intended):
     

    I had filed a bug report and got feedback from Chrome devs:
    Status: Wont Fix

    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.

    It fixes the caps and SS reset but not /d-space substitution.

Categories