1

(I'm new to both Arabic, and doing things related to Unicode, so I might be overlooking some glaring detail.)

So, I'm using the SIL font Lateef, and want to access the BEH initial form glyph, in HTML. (Because, in MSA, "with/through" is translated to the prefix ﺑِ, so I want to include it in initial form to make clear that it is a prefix, and not a word on itself.)

The BEH initial form glyph has Unicode code U+FE91. However, Lateef does not include the glyph at this 'location' (not entirely sure what to call it), and instead includes the glyph at U+1016F ("Greek Acrophonic Carystian Five Hundred"), and then uses a substitution table to use it. (The substitution table usage is logical, but I don't get why Lateef puts the glyph in this weird place.)

As my app definitively uses Lateef, included as a webfont, I decided to then just reference it as U+1016F in javascript (\u{1016F}) or HTML (𐅯 or 𐅯) --- ugly, I know, because non-semantic, but I couldn't decide upon a better way. However, even though the element in question was indeed using Lateef as font, Chrome displayed the "Greek Acrophonic Carystian Five Hundred" instead:

This is not the BEH initial form glyph!

My questions then, are:

  • How come Chrome displays the "Greek Acrophonic Carystian Five Hundred" glyph, when the HTML element is clearly using Lateef, and the unicode character is correctly referenced, and Lateef indeed includes the BEH initial form glyph at U+1016F?
  • Is it at all possible, to display Lateef's initial BEH? (Other than editing the font to include the glyph at the correct location, as well.)
  • Is this an error/misunderstanding on my part, or an actual weirdness on behalf of Chrome, Ubuntu/Chrome, Unicode, or HTML?
Improve this question
9
  • Can you inspect the element in Chrome to check whether it’s actually using Lateef or a fallback font to render that particular glyph? Perhaps there’s something in the substitution table that makes Chrome believe Lateef does not actually include the code point U+1016F. And yes, very odd place to put it—quite unlike SIL, I would have thought.
    – Janus Bahs Jacquet
    Oct 20, 2017 at 16:37
  • Inspecting the element in Chrome to verify Lateef is specified: i.imgur.com/yN26bvG.png. But I really don't know how browsers work with fonts, maybe it is indeed the case that Chrome, for some reason, simply doesn't know/think Lateef has a character there, and thus uses a different font? Something of this form basically must be the case, I guess..
    – Kelley van Evert
    Oct 20, 2017 at 22:31
  • Try scrolling down to the bottom of the lower right part of the developer tools there (the one with the graphic box model in it). At the very bottom, it tells you which font is actually rendered; here’s an example from a random site. That should give you the actual font that’s being rendered, rather than the CSS rule, which may entail fallback fonts being used, in this case “serif”.
    – Janus Bahs Jacquet
    Oct 20, 2017 at 23:35
  • Ah, excellent. I didn't know to find that info before. It indeed falls back to another font (Symbola). But I wonder why, as the glyph is actually present in Lateef. Maybe this has something to do with how Unicode works, and it disallows direct use of the glyph?
    – Kelley van Evert
    Oct 21, 2017 at 8:58
  • 1
    I don't have InDesign, so I couldn't test this. However, I did make an interesting discovery, playing around with FontForge: in the "View" > "Label glyph by..." menu, I chose "Unicode" instead of "Glyph image", and suddenly I noticed that, in some technical sense which I don't know more of, the gylph, although 'located' at 0x1016f, wasn't 'assigned' the unicode point U+1016f. So, I assigned it myself (setting "Glyph info" > "Unicode" > "Unicode Value" to "U+1016f"), and now the access works. So yes, you're right, it's a Lateef thing, in (not) assigning these Unicode values...
    – Kelley van Evert
    Oct 21, 2017 at 12:30

1 Answer 1

Reset to default
1

The reason why the glyph was not accessible

Apparently, although the BEH initial form glyph was 'stored' at location 0x1016f, is wasn't 'assigned' the Unicode value U+1016f. As far as I understand, the glyph will then not show up in the cmap table, which is the go-to place for the rendering engine's character -> glyph selection process.

I discovered this when messing around in Fontforge. In FontForge, to view the characters labelled by Unicode value instead of glyph image, select "View" > "Label Glyph By" > "Unicode"; and to set the Unicode value for the glyph in question, select the glyph, right-click, then set "Glyph Info..." > "Unicode" > "Unicode Value" appropriately.

I imagine this is a bug on behalf of the Lateef font; the 'correct' way to go would have been to make the glyph accessible in the cmap table, but also put it at 0xfe91 in the first place, instead of 0x1016f (where it doesn't semantically belong).

How to access the glyph anyway

EASY: Just use U+0640: بـ.

OLD / COMPLICATED:

Apart from modifying the font, as is suggested from the solution of the problem above, I came up with another, funky way of accessing the glyph, without modifying the font.

<div style="direction: rtl;">ب&zwj;<span style="color:#fff; width: 0px; display: inline-block;">ن</span></div>

As the glyph can be accessed implicitly, when combined with subsequent letters, one can simply hide those subsequent letters, and end up with just the BEH initial form glyph. However, an additional trick must be employed: adding a zero-width joiner &zwj;, in order to let the characters connect through the interspersed <span> element.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.