<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 30, 2013 at 7:26 PM, Jonathan Kew <span dir="ltr"><<a href="mailto:jfkthame@googlemail.com" target="_blank">jfkthame@googlemail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
There's overlap here with the process of font-matching (choosing the font(s) to be used for a given text sequence), which is clearly out of scope for harfbuzz. If a given Unicode character is not supported (exactly, or via a *canonical* [de]composition) by a given font, there are several possible outcomes: just render the font's .notdef glyph; render some synthetic representation of the codepoint (hexbox); render a compatibility-equivalent character/sequence, if such exists; choose a different font.<br>

</blockquote><div><br></div><div>I agree with this model.  There's a general problem of what you might call "fallback": what to do if the requested font does not have a glyph for the requested character.</div>

<div><br></div><div>This makes me realize that I don't understand the big picture of how this fallback process interacts with harfbuzz. In order to do fallback, you need to do character to glyph mapping. If the application is expected to do fallback before calling harfbuzz, why does harfbuzz expect chars rather than glyphs as input to the shaping process?  I would have expected there to be some application callback that harfbuzz would call when there is a need to do fallback; the application would use this to tell harfbuzz how to handle this situation for this particular character. Some of these harfbuzz could handle by itself, others would require cooperation between the application and harfbuzz.<br>

</div><div><br></div><div>James</div><div><br></div><div><br></div></div></div></div>