<div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature">2015-05-12 0:58 GMT+04:00 Louis Semprini <span dir="ltr"><<a href="mailto:lsemprini@hotmail.com" target="_blank">lsemprini@hotmail.com</a>></span>:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div><div dir="ltr"><br><br><div>> Date: Mon, 11 May 2015 19:44:52 +0100<br>> From: <a href="mailto:richard.wordingham@ntlworld.com" target="_blank">richard.wordingham@ntlworld.com</a><br>> To: <a href="mailto:harfbuzz@lists.freedesktop.org" target="_blank">harfbuzz@lists.freedesktop.org</a><span class=""><br>> Subject: Re: [HarfBuzz] how to detect missing glyphs e.g. for font substitition<br>> <br></span><span class="">> On Mon, 11 May 2015 07:56:19 +0000<br>> Louis Semprini <<a href="mailto:lsemprini@hotmail.com" target="_blank">lsemprini@hotmail.com</a>> wrote:<br>> <br>> > What is the most reliable and non-font-dependent way to detect<br>> > whether a string being shaped by hb_shape() has led to any missing<br>> > glyphs, and to identify where those glyphs occur?<br>> > <br>> > When I use the word "missing glyph" here I mean a glyph that is not<br>> > what the user intended for that code point in that context, whether<br>> > that be a little tofu box, a magical hex box, a space glyph (with or<br>> > without zero advance), a diamond, or anything else that has<br>> > substituted for the glyph that the user really wanted.<br>> <br>> In so far as the glyph is not just a function of the Unicode scalar<br>> value, there need not be any indicator.  There are a number of<br>> fallbacks that may occur even in a well-constructed font:<br>> <br>> 1) Optional ligatures may be missing from the font.<br>> <br>> 2) Indic conjuncts may have a fallback form - Devanagari has two levels<br>> of fallback.<br>> <br>> 3) As Konstantin mentioned, the default glyph for the base codepoint may<br>> be returned if the requested variation sequence is not supported by the<br>> font.<br><br></span>Interesting, but I think I can safely say that 1, 2, and 3 would not fall in the category of "missing glyph" for my definition since at least something intelligible that relates to the original code point is presented (not tofu).  Yes it would be better to substitute a font with the capabilities described in 1-3 but that's not the main concern for the current question because at least the user still has a chance of figuring out the meaning.<br><br>The main concern would be cases where what the font presents has no relation to the meaning of the original code point.  Can you think of any cases like that which would generate glyph indexes other than 0?<span class=""><br><br>> Also, how many glyphs a pair of regional indicators should yield is<br>> quite undefined - it may be a choice of the font designer to render<br>> them as letters.<br><br></span>Interesting again, but that would be another case where what the user does see (either flags or letters) is still meaningful and not tofu, so it won't apply to the current question.<br></div></div></div></blockquote><div><br></div><div>Actually, it does.</div><div>Whilst variation selectors are of Default_Ignorable_Code_Point property, regional indicators are not (bug in Unicode? or it was done intentionally?), which means invalid or unsupported VS sequence will be replaced with a non-advancing whitespace, however invalid or unsupported RI sequence will result in a run of .notdef glyphs (no flags, no letters).</div><div><br></div><div>Konstantin<br></div></div></div></div>