[HarfBuzz] Loading Graphite dynamically

Konstantin Ritt ritt.ks at gmail.com
Wed May 20 22:49:14 PDT 2015


2015-05-21 5:54 GMT+04:00 Martin Hosken <mhosken at gmail.com>:

> > 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.
>

Is FALLBACK really required? I don't think it has a value if OT backend
works.

Regards,
Konstantin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20150521/b63194a1/attachment.html>


More information about the HarfBuzz mailing list