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 <[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. 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 > _______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
