On 14-09-03 07:43 PM, Lóránt Pintér wrote: > Hi Behdad, > > On Wednesday, Sep 3, 2014 at 4:01 pm, Behdad Esfahbod <beh...@behdad.org > <mailto:beh...@behdad.org>>, wrote: > > > I’m not sure what the glib dependency means for us. Can you explain why > it > > would be a problem? > > It's just one more library you need to cross-compile. And glib comes with > lots of things that Pango doesn't need and I suppose you wouldn't need, so > there's some work trimming it down there. > @behdad.org> > > I see. Is there any work planned to do this trimming?
There's nothing to do on the upstream side. It's only about how much of glib you want to get in your javascript. On most other platforms compiling the whole library is not a big deal. > Do you plan to remove this dependency? No. That's not really feasible, given that Pango is a core part of GNOME. That said, there's a need for a layout engine implementation that is more flexible than Pango for using in other projects. So that's something I've been thinking about in the back of my head. Nothing concrete right now. > Does emscripten or the rest of your toolchain already know how to remove > unused library code? > @behdad.org> > > Emscripten, being based on LLVM, has some level of dead code elimination, but > I haven’t yet looked into it in more depth. As far as I know, it’s supposed to > be pretty clever.Obviously, the best for us would be if Pango didn’t depend > on GLib at all. :) > > > > Current versions of pango use a convoluted module system to choose > shapers. I > > have a branch that removes most of that: > > > > https://github.com/behdad/pango/tree/kill-modules > > > > Cool. Is there a plan to merge this into the main line? > > Yes. It's very close to being mergable. I just need to do the same (ie > hardcode) language modules the same way I did for shaper modules. I'm away > for vacation and conferences for multiple weeks though, but expect this to > definitely land later this year. > @behdad.org> > > > That sounds good. So we can basically start working with this branch, and > start using master when you merge back. Sounds good. > > After that, you need to implement a set of PangoFontMap / > PangoFontFamily / > > PangoFontFace / PangoFont subclasses since you don't want to use > PangoFc. > > This is rather straightforward, if you don't want much font > fallback. > > > > Sounds workable. We already have similar classes in our own > implementation > > that I want to replace with Pango. > > > > For the shaper part, modify pangofc-shape.c. You just need access > to the > > hb_face and you can do the rest from there. > > > > I’m looking for a solution where (eventually) I won't need to keep a > separate > > branch of Pango. Would it be possible to do this without modifying > existing code? > > You don't need to modify anything. libpangofc itself uses libpango's > public > API only. You will be doing the same. Right now that involves copying > pangofc-shape.c and modifying it. Some time in the future I'll hardcode > HarfBuzz as the only shaper Pango supports, and at that time the logic in > pangofc-shape.c will be shared across all backends and you can remove your > copy. > @behdad.org> > > > That sounds promising. Do you know when this “some time in the future” would > happen? I'm hoping for later this year or early next year. > Let me know if you have any other questions. I'm really curious to see > this > in action. > @behdad.org> > > > Great. :) I’d be very excited to see it myself as well. That said, this is > going to be a side-project for me. I’m not too experienced with C++ either, so > I might need to recruit someone to help me with the details, too. But if it is > at all possible, I’d like to get it working before the end of the year. With > your help it seems doable. Given what you have already done with HarfBuzz before, I think you are in a great position to get this working. -- behdad http://behdad.org/ _______________________________________________ gtk-i18n-list mailing list gtk-i18n-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
