[HarfBuzz] The purpose of hb-unicode and more flexible builds

[Behdad Esfahbod]

On 01/04/2012 09:23 AM, Petr Kobalíček wrote:
> Hi Behdad

Hi,

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


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

behdad



> so these
> features are in most cases not used. But your explanation is
> sufficient.
> 
>> behdad
>>
>>
>>> Thanks!
>>> Petr Kobalicek
>>
> 
> Best regards
> Petr Kobalicek
>