Dear Behdad, > For the curious, this is the PR: > > https://github.com/behdad/harfbuzz/pull/107 > > This basically uses dlopen to open libgraphite2. > > I need to understand better what you are trying to address with this. "A > number of people have asked" does not quite justify it. Why do people care? > > Years ago I thought about doing this, specially since with all the > integrations (FreeType, glib, gobject, icu, graphite2, more to come later), > dynamic loading sounds very attractive. But decided not to pursue that as it > adds unnecessary complexity. We just removed support for dynamic modules from > Pango and I'm so glad we did... I don't want to add those back to HarfBuzz > unless we absolutely have to. > > So, what are you trying to fix?
In case my previous answer wasn't as helpful as it might be. I think this is a different case to the idea of dynamic modules. Dynamically loading the graphite library will lessen harfbuzz's relation to Graphite. It means that harfbuzz can support graphite without having to know anything about it. If the library happens to be on the system, it'll get loaded otherwise it won't. So harfbuzz doesn't need to manage anything. It's not a module in that harfbuzz has to manage it, locate it, handle registration, etc. The filename and lack of path is hardwired to improve security (graphite must be a true library in that respect), and an application can always dlopen the graphite library itself if it wants to load it from somewhere else. If this patch is accepted and enabled on say, android, then there is no need for android to consider including graphite on the system. Instead applications can include the graphite library if they want, and only if they include the graphite library, will it get used. This is far more preferable for such applications than having to bundle a 50MB browser with every app. Remember for minorities that might mean a keyboard app, an sms app, a document reader, etc. In the case of chromium.org the patch allows them to ship chromium without graphite and allow the application to include the library or not. The difficulty we face at the moment, is that the support of graphite in an application is an all or nothing choice. Either the complete stack has to be built with graphite in or it is locked out. If graphite is not supported by the stack, then any application that wants to support graphite has to copy the entire stack with the slight difference of enabling graphite. As the stack grows, this burden only increases and becomes more ridiculous. This patch breaks that deadlock and allows the decision of whether graphite is supported, to be made by the application rather than the framework on which the application is based. Yours, Martin > > > Thanks, > behdad > > On 15-05-18 05:50 AM, Martin Hosken wrote: > > Dear All, > > > > A number of people have asked me for a mechanism by which graphite may be > > dynamically loaded only when a Graphite font is used. I've struggled with > > the notion of this, but I think I understand it now. I hope that this can > > help everyone to have what they want for minimal cost. > > > > I've submitted a pull request on github for a patch that does the above. > > > > This patch adds dynamic loading of graphite support for graphite fonts in > > harfbuzz. The three way configure option is now: --with-graphite2=no means > > no graphite support. --with-graphite2=yes means to build and link against > > an existing graphite library. --with-graphite2=auto means to build > > independently of any graphite library but to attempt to dynamically load > > graphite when a graphite font is encountered. > > > > This patch has been built and tested on linux only at the moment. > > > > Yours, > > Martin > > _______________________________________________ > > HarfBuzz mailing list > > [email protected] > > http://lists.freedesktop.org/mailman/listinfo/harfbuzz > > _______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
