Re: Pango without FreeType (or fontconfig)

["Lóránt Pintér" <lorant pinter prezi com>]

Hi Behdad,

On Wednesday, Sep 3, 2014 at 4:01 pm, Behdad Esfahbod <behdad 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? Do you plan to remove this dependency?

 

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.

 

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

 

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.