[HarfBuzz] The purpose of hb-unicode and more flexible builds
behdad at behdad.org
Mon Jan 16 13:50:44 PST 2012
On 01/04/2012 09:23 AM, Petr Kobalíček wrote:
> Hi Behdad
> sorry for long delay here.
Same here :).
> On Fri, Oct 21, 2011 at 6:46 PM, Behdad Esfahbod <behdad at behdad.org> wrote:
>> On 10/17/2011 12:11 PM, Petr Kobalíček wrote:
>>> Hello list,
>>> I'd like to ask what is real purpose/advantage to have hb_unicode_funcs_t?
>> More flexible builds!
> Okay, but If I understand the situation correctly, each
> library/toolkit which need to use text layouting (for example Pango,
> Qt, Chromium, etc...) contains its own private copy of harfbuzz.
That is the case right now, but going to change. The main reason we started
harfbuzz-ng was to get to a point that we can all use it as a shared system
> I can live with it, but for me it's unnecessary abstraction, because
> in most cases only single implementation is always used.
>>> I know that this is a wrapper to the real implementation, but is there
>>> another use-case to switch unicode functions on the fly and per
>> There are many reasons:
>> - This lets you compile HarfBuzz with no default implementation and hook
>> yours at runtime.
> This is reasonable, but helper libraries are already needed by
> harfbuzz (glib/icu/etc) so there is already runtime dependency.
I don't understand. Neither glib nor ICU are required. We provide glue code
for when you want to use HarfBuzz with those, but they are not required. And
I'm going to figure out a way to avoid linking to all of them to begin with.
>> - Even if there is an internal implementation already, you may want to hook
>> yours. For example, a Python user may want to hookup Python's Unicode
>> Character Database instead. Same for Perl, etc.
> Also good reason, but do you think that the database is different? As
> I know that it comes from unicode tables, so only the version of
> tables can be different.
Right. But reusing the Python data from Python improves memory cache behavior
as you wouldn't have to load two sets.
>> - It's also useful for developing new scripts for Unicode. This is a small
>> audience, but since I regularly work with these people, I wanted to
>> accommodate their needs.
> Okay, no problem here:)
>> - Having it per-buffer enables comparison against different implementations.
>> - Having it per-buffer instead of global is simply an artifact of HarfBuzz
>> being a shared library. Ie. no global settable state. The buffer simply was
>> the best place to put this.
>> What's your concern, if any?
> I'm trying to use harfbuzz with Fog-Framework so I wanted the best
> possible integration. My solution is to compile harfbuzz statically,
> it's private part of library, so it's not exported and I can do
> hardcoding. This means that I don't need abstraction or mechanism to
> add unicode-api at runtime, etc...
> My thinking is that many projects use harfbuzz in such way
Well, we hope to change that.
> so these
> features are in most cases not used. But your explanation is
>>> Petr Kobalicek
> Best regards
> Petr Kobalicek
More information about the HarfBuzz