[HarfBuzz] Why harfbuzz isn't/couldn't/shouldn't provide separate [optional] API for glyph/positioning?

[Nikolay Sivov]

On 2/26/2018 5:28 AM, Behdad Esfahbod wrote:
> 
> Two things stand out:
> 
>   - There's a lot of duplicate info going into both calls,
> 
>   - There's also a lot data coming out of the first call just to go
> directly into the second; namely pCharPropsand pGlyphProps.
> 
> Those two very strongly suggest that the two calls are part of the same
> larger operation and rather forcefully separated.

One example of such larger operation is ScriptStringAnalyse(), except
that it's pre-*OpenType() and thus does not have feature ranges support.

If not to justify but to understand better this separation, does it make
sense if the idea was to have an ability to change font size? Or toggle
GPOS features without re-running all deal of reprocessing input text
buffer, because resulting glyph array won't change anyway at this point.

DirectWrite call is cleaner in that sense, because of separate size
argument GetGlyphPlacements() takes, as opposed to just current font in
HDC (or cache).

...

> 
> Separating the calls also means that some things, like which OpenType
> feature applies to what range, needs to be recalculated. Guess that's
> not a huge deal. The biggest problem with separating the calls in a way
> that is useful for Wine implementing the Uniscribe API on top is that we
> have to expose the buffer-internal bit allocations. And we don't want to
> do that, because that is an implementation detail and changes over time.

Actually I have looked again last year at using hb_buffer for
DirectWrite in Wine, and after I didn't find any way to fill buffer with
resulting glyphs as opposed to text, I realized that it won't be easy if
possible at all.

P.S. Behdad, how do you test things? Do you have large set of texts +
fonts you run against, more than what's in /test of hb tree I mean.
Since hb-shape can also use Uniscribe or DirectWrite, that would be
helpful to have such data to test Wine on.