Re: Pango without FreeType (or fontconfig)



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 <behdad behdad org
<mailto: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?

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/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]