I reached some interesting ideas about this tonight. Will write up soon. <div class="gmail_quote">On Jan 3, 2014 8:25 PM, "Jonathan Kew" <<a href="mailto:jfkthame@googlemail.com">jfkthame@googlemail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 3/1/14 11:57, Khaled Hosny wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Fri, Jan 03, 2014 at 10:07:50AM +0000, Jonathan Kew wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 3/1/14 06:12, James Clark wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Mon, Dec 30, 2013 at 7:26 PM, Jonathan Kew <<a href="mailto:jfkthame@googlemail.com" target="_blank">jfkthame@googlemail.com</a> <mailto:<a href="mailto:jfkthame@googlemail.com" target="_blank">jfkthame@googlemail.com</a>>> wrote: 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. 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. 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. </blockquote> Not necessarily. You need to know the character repertoire supported by the font, but you may not need to actually map to glyphs. In Firefox, for instance, font fallback is done based on a per-font *bit* map of supported Unicode codepoints. So at the font fallback stage, we know whether the character is present, but do not map it to a glyph. </blockquote> One issue with that approach is you lose HarfBuzz’s ability to do Unicode composition/decomposition for unsupported characters, which should generally produce better resulting than font fallback. I wounder HarfBuzz can provide an API to help clients decide whether HarfBuzz can shape a given character with a given font or not? Or would that be too slow for practical use? </blockquote> This is an interesting point, and one that we're still thinking about. Behdad has talked at some point about possibly having such an API, but we've never finalized anything. <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> In LibreOffice we just pass the characters to HarfBuzz, and if returns a 0 glyph id for any character, font fallback is used for that one (some times with some of the surrounding characters to make sure clusters are rendered with the same font). </blockquote> Yes, that's another possibility, though it wouldn't fit very readily into the current Gecko text architecture. It may well be a more natural approach for some other clients, though. JK _______________________________________________ HarfBuzz mailing list <a href="mailto:HarfBuzz@lists.freedesktop.org" target="_blank">HarfBuzz@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/harfbuzz" target="_blank">http://lists.freedesktop.org/mailman/listinfo/harfbuzz</a> </blockquote></div>