Ok, based on your feedback and some help from Ehsan, I've pushed out a bunch
of fixes and cleanup to master now. Some macros are replaced by templates.
Notably, the int type definitions. More below.
On 04/16/2010 02:19 AM, John Daggett wrote:
> Hmm, if by decoupling you mean that it's possible
> No, I'm not suggesting a different serialization format, I'm saying
> that instead of caching the full GSUB/GPOS tables it might be better
> to cache some data structure that's been distilled for a given purpose.
>
> For a lot of documents, hb_shape will be called repeatedly with the
> same font
Behdad Esfahbod wrote:
> >> You seem to drastically under-estimate the headaches of
> >> lifecycle-management in a library. Mozilla also disables cairo's
> >> mutex use. So I don't think Mozilla is the perfect use case of
> >> those features. When you are dealing with FT_Face and hb_face_t
> >>
On 04/15/2010 02:20 AM, John Daggett wrote:
>> It's definitely more complex than the code it's replacing (which was
>> plain C). However, it's very carefully designed, easier to audit,
>> and I'm much more confident in it than in the code it replaces.
>
> Complex code for dealing with complex dat
Based on feedback from Behdad, I made a few additional comments, included below.
Original post here:
https://bugzilla.mozilla.org/show_bug.cgi?id=449292#c55
> It's definitely more complex than the code it's replacing (which was
> plain C). However, it's very carefully designed, easier to audit,
>
As part of ongoing work at Mozilla I was asked to review the new
harfbuzz-ng code for inclusion in Firefox. I realize there are other
projects with differing constraints involved but I'm concerned about
the structure of the current code. Given the relative complexity of
OpenType layout and the stru
