[HarfBuzz] Loading Graphite dynamically [2]

[Martin Hosken]

Dear Behdad,
> 
> > 3. Why stop at Graphite?  Why not use this for ICU, FreeType, glib, gobject,
> > fontconfig, as well as others?  That way I can have one libharfbuzz.so with
> > all the bits and pieces without pulling in 100MB worth of libraries; and we
> > can fold libharfbuzz-icu.so back into libharfbuzz.so...

I think the difference lies in the needs of the framework layers that call harfbuzz. Harfbuzz is rarely called directly by applications, but by intermediate layers like qt, gtk, chromium (the browser is the new OS), etc. And those intermediate layers are currently having to make support choices for their applications regarding which backends to support.

There are two kinds of library decisions that integrators of harfbuzz need to make. The first is the choice of libraries necessary to have harfbuzz work in the direct calling environment. These include things like unicode support, freetype/font querying support; in effect everything that harfbuzz calls back to the application for. The second is what backends harfbuzz supports. For the most part the intermediate layers don't care what backends harfbuzz supports. Clearly they want OT support otherwise they wouldn't be using harfbuzz, but others are of less value to them. They are caught between pressure to support applications needs for backends and the desire to keep the intermediate layer itself, as thin a possible. So they would prefer not to ship with a niche backend like graphite, forcing all applications to support it. But they would like to allow applications to support graphite if they so desire. The same would apply to, say, someone producing a cross platform AAT backend. Currently, we have two types of backends: all platform and single platform. uniscribe and coretext are single platform, and therefore their support by an intermediate layer is chosen based on what platform the layer is being built for (along with that support being near zero cost, since the supporting libraries are part of the platform). Of the cross platform backends, there are 3: OT (required), FALLBACK (required), GRAPHITE2 (not required, but desired). Therefore Graphite2 is currently, the only backend that would benefit from being dynamically loaded, allowing the intermediate layer to leave this backend support question to the application.

Sorry, I forgot to expand my first point in that paragraph. The first class of libraries, the ones necessary to have harfbuzz work in the direct calling environment, gain nothing from being dynamically loaded (like graphite) because their choice is a static one based on their direct call environment. The calling environment does not want to change those library choices on the fly or in response to application choice. The choice is made by the programmer of the intermediate layer, at the time they integrate harfbuzz, once.

HTH,
Yours,
Martin