[HarfBuzz] Loading Graphite dynamically

[Jonathan Kew]

On 18/5/15 13:50, Martin Hosken wrote:
> Dear All,
>
> A number of people have asked me for a mechanism by which graphite
> may be dynamically loaded only when a Graphite font is used. I've
> struggled with the notion of this, but I think I understand it now. I
> hope that this can help everyone to have what they want for minimal
> cost.
>
> I've submitted a pull request on github for a patch that does the
> above.
>
> This patch adds dynamic loading of graphite support for graphite
> fonts in harfbuzz. The three way configure option is now:
> --with-graphite2=no means no graphite support. --with-graphite2=yes
> means to build and link against an existing graphite library.
> --with-graphite2=auto means to build independently of any graphite
> library but to attempt to dynamically load graphite when a graphite
> font is encountered.
>
> This patch has been built and tested on linux only at the moment.

AFAICS, the patch will leak the graphite2_funcs_t record that's attached 
to the face, as it fails to free it in 
_hb_graphite2_shaper_face_data_destroy.

(It also fails to free it if _hb_graphite2_shaper_face_data_create hits 
an error in gr_make_face, or if hb_graphite2_load_gr fails to find one 
of the expected functions in the library.)

I wonder if it'd be better to ALWAYS do the dynamic-load thing, and 
scrap the HAVE_GRAPHITE2_STATIC option? This would substantially clean 
up the #if-clutter that currently makes things look a bit hairy, and 
probably make it easier to verify that the code paths are all sane.

As for whether to do this in general -- I think that if we can ensure 
the code is clean enough that it won't introduce new leaks (see above) 
or vulnerabilities, it'd provide a crucial feature that's currently 
lacking for most client apps. In Gecko, we don't need this as we have a 
separate Graphite codepath that's independent of harfbuzz (though we 
could consider changing that some day), but for software that uses a 
harfbuzz rendering path exclusively, this could offer a valuable added 
capability.

JK