"Combining comma below" (\u0326) doesn't render on iOS

[c99koder]

We are using the OTF version of Hack in our iOS app, however it doesn't seem to display characters using the "Combining comma below" unicode symbol, for example \u0074\u0326 should display "ț" however the OS falls back to the system font for this glyph. Typing the characters manually using the iOS keyboard (which produces unicode character \u021b instead) renders correctly using the Hack font. See attached screenshot from our app.

[chrissimpkins]

Apologies for the delay. Please let me know if you are still using Hack and if this is still a problem for you by reopening the issue report. Getting back to work on the fonts and attempting an issue report cleanup.

[c99koder]

Yes, we're still using Hack and this is still an issue

[chrissimpkins]

Thank you! Are you able to try the ttf builds in your application? They are the primary font builds and recommended at this stage. We will likely eliminate the otf builds in future releases because of hinting issues.

[c99koder]

Yes, I've just rebuilt the app using the TTF files, however the issue is still present. Attached is a screenshot of the missing ț glyph using the TTF files.

[chrissimpkins]

First time that I've seen it on iOS. Thanks for the SS. Great looking app.

Let me check the character sets. What language / Unicode character set are you trying to support?

[c99koder]

We use UTF-8 encoding. The unicode values are in the original report (\u0074\u0326 doesn't render properly, but \u021b which is visually the same character but without using a combining code works fine)

[c99koder]

Just checked my Android device and the issue is there too. It works fine in Chrome on my Mac, though.

[chrissimpkins]

Understood. I am trying to understand what languages you are attempting to support with the addition of the glyph to the character sets. It looks like this is part of Latin extended B https://unicode-table.com/en/blocks/latin-extended-b/

As for the basis of your question, that is digging into platform specific rendering territory that I am not aware of and do not understand for iOS. This seems to be a paste specific issue on the platform as direct character entry uses the single Unicode codepoint symbol, but the paste seems to use combining characters. Mind trying Latin small letter S with comma below as direct type entry and paste entry to confirm that you see it there too? https://unicode-table.com/en/0219/

[c99koder]

Ah, the original language was Romanian. It came from a PDF that one of our users had copy/pasted some text from, which led to them reporting the bug to us.

The same issue occurs with ș. \u0073\u0326 renders using the system font, but \u0219 renders in Hack.

I'm also not familiar with the specifics of iOS and Android font rendering, just passing the bug report along to you :)

[chrissimpkins]

Great, thank you for letting us know! Yes, I am sure that this is a missing comma below issue and we can consider the addition of these glyphs down the road. Our top priority has always been optimization/extensions for source code associated issues so this will not fall at the top of the priority list for now but should be a reasonably easy addition.

You will know better than I, but as for workarounds do you have access to the Unicode codepoints in pastes so that you can replace combining characters with the available glyphs before they are displayed to the user?

[c99koder]

Yes, I can replace the characters before rendering text to the screen as a workaround in our app in the meantime