Hi Behdad sorry for long delay here.
On Fri, Oct 21, 2011 at 6:46 PM, Behdad Esfahbod <[email protected]> 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 _______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
