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. _______________________________________________ HarfBuzz mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/harfbuzz
