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

Eimantas PaškonisEimantas Paškonis Posts: 68
edited August 20 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):

sub @con0 @con0' by @con1;
sub @con1 @con0' by @con2; sub @con0 [@vow0 @vow1 @vow2 @etc] @con0' by @con1; sub @con1 [@vow0 @vow1 @vow2 @etc] @con0' by @con2; sub @con0 [@vow0 @vow1 @vow2 @etc] [@vow0 @vow1 @vow2 @etc] @con0' by @con1; sub @con1 [@vow0 @vow1 @vow2 @etc] [@vow0 @vow1 @vow2 @etc] @con0' by @con2; sub @con0 [@vow0 @vow1 @vow2 @etc] [@vow0 @vow1 @vow2 @etc] [@vow0 @vow1 @vow2 @etc] @con0' by @con1; sub @con1 [@vow0 @vow1 @vow2 @etc] [@vow0 @vow1 @vow2 @etc] [@vow0 @vow1 @vow2 @etc] @con0' by @con2;

  • 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

Comments

  • Which browser(s) did you use?
  • Eimantas PaškonisEimantas Paškonis Posts: 68
    edited August 20
    Chrome. Tested in on Safari and it works as intended...
  • Khaled HosnyKhaled Hosny Posts: 176
    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 JagoszAdam Jagosz Posts: 77
    edited August 20
    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.
  • 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.
  • @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 HosnyKhaled Hosny Posts: 176
    How are you making space ignored during substitution?
  • 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škonisEimantas Paškonis Posts: 68
    edited August 21
    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):

    ignore sub @etc d';
    sub d' @etc by d_old;
    sub @vow0 @con0 d' by d_old;

    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.

  • 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škonisEimantas Paškonis Posts: 68
    edited August 22
    @Thomas Phinney Yes I did, it did not fix it.
  • Erwin DenissenErwin Denissen Posts: 89
    edited August 22

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

    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 HosnyKhaled Hosny Posts: 176
    I'd report the bug in Chrome bug tracker in this case.
  • Nick ShinnNick Shinn Posts: 1,150
    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 HudsonJohn Hudson Posts: 1,172
    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škonisEimantas Paškonis Posts: 68
    edited August 30

    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.

Sign In or Register to comment.