I reached some interesting ideas about this tonight. Will write up soon. On Jan 3, 2014 8:25 PM, "Jonathan Kew" <[email protected]> wrote:
> On 3/1/14 11:57, Khaled Hosny wrote: > >> On Fri, Jan 03, 2014 at 10:07:50AM +0000, Jonathan Kew wrote: >> >>> On 3/1/14 06:12, James Clark wrote: >>> >>>> On Mon, Dec 30, 2013 at 7:26 PM, Jonathan Kew <[email protected] >>>> <mailto:[email protected]>> 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. >>>> >>> >>> 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. >>> >> >> 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? >> > > 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. > > 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). >> > > 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/harfbuzz >
_______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
