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

[Petr Kobalíček]

Hi Behdad

sorry for long delay 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.

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.

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

>  - 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 so these
features are in most cases not used. But your explanation is
sufficient.

> behdad
>
>
>> Thanks!
>> Petr Kobalicek
>

Best regards
Petr Kobalicek