[HarfBuzz] Further splitting libharfbuzz.so

[Behdad Esfahbod]

On 13-05-30 05:09 AM, Shriramana Sharma wrote:
> But if the FT module is small, I guess you can avoid splitting it to a
> separate SO unless it's important to be able to switch off the
> dependency on that (I don't think so, since most environments use FT
> anyway).

There's also another reason that I prefer to keep hb-ft separate: the ABI
guarantees on hb-ft may not be as strong as harfbuzz proper.  Right now the
hb-ft API needs major work to address load_flags issues.  I don't want that to
hold back the main library.  I can always call hb-ft API unstable and subject
to change...

On 13-05-30 04:37 AM, Cosmin Apreutesei wrote:>>   * hb-ft is a very small
piece; convenience code you can even call it.  Most
>> "serious" users of harfbuzz don't use hb-ft, but small users all use it.
>
> I see pango uses ft too to implement the callbacks for

Pango uses ft, but not hb-ft.  Same is true about all other major users of
HarfBuzz.


>>     - As the default Unicode callback provider.  If glib is disabled, harfbuzz
>> builds an internal piece of code called UCDN that provides the same data.  It
>> results in an extra 100kb of binary as well as duplicated data.  I like to
>> avoid that, but don't want it to affect my ABI.
>
> I have the opposite use case - I would like to avoid the much bigger
> glib dependency.

You sure can build without glib.  I don't see how using it if it's available
has any down sides.


> I am curious why hb_unicode_funcs_get_default()
> chooses icu and glib with priority over ucdn when they are both
> available. Are there any downsides (other than the 100kb) to using it
> in place of icu or glib?

At this point that doesn't matter anymore.  I disabled the icu one, and if
glib is enabled UCDN gets disabled and vice versa.

But to answer your question: I hate Unicode data duplication.  Every
framework, every browser, every language runtime, each duplicate this data.  I
just hate it to do it in HarfBuzz again.  But then again, for convenience we
included UCDN already...

Anyway.  I think I'll go ahead and create separate harfbuzz-ft and
harfbuzz-glib then...

Oh, and the WebkitGtk build is fixed upstream.

-- 
behdad
http://behdad.org/