[HarfBuzz] HarfBuzz 1.0 API; the message you were hoping would never come

[Behdad Esfahbod]

I reached some interesting ideas about this tonight.  Will write up soon.
On Jan 3, 2014 8:25 PM, "Jonathan Kew" <jfkthame at googlemail.com> 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 <jfkthame at googlemail.com
>>>> <mailto:jfkthame at googlemail.com>> 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
> HarfBuzz at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20140103/b5667061/attachment.html>