Re: Re: advanced warning: planed removal of stale Pango code

From: msevior_at_physics.unimelb.edu.au
Date: Sun Nov 09 2003 - 20:13:02 EST

  • Next message: ericzen: "AbiWord Weekly News #169 "AbiWord 2.2: Reloaded" Released."

    > If we can design it so that as much as possible is in XP land and that
    > things are made as easy as possible for platform maintainers then we
    > have got a long way. If we don't then we won't get anywhere.
    >
    > If we don't try then we won't get anywhere either.
    >

    Hi Daniel,
              As Tomas's previous experiments have shown using Pango to it's
    fullest extent requires quite a radical reworking of AbiWord's
    core. I'm now rather happy with where AbiWord is at although we
    still have some problems remaining.

    The most difficult issues we face incthe core of our application is
    getting perfect WYSIWYG behaviour at all zooms and for printing. Pango has
    not needed to address these issues. Although we don't have this fuly
    solved (we still have off by one pixel bugs which leads to screen dirt)
    I'm confident that they can be solved.

    >> > Does it seem feasible to make a layout class that would provide the
    >> breaking and other funcs that the rest of AW layout requires? Since
    >> pango only works on a paragraph at a time AW still has to do a lot
    >> around it.
    >>
    >> If it was just a question of replacing the block layout basic block
    >> layout functionality, it would not be too bad. What seems to me to be
    >> the problem is that the classes above block layout and the view class
    >> still make direct access to the classes bellow the block, such as
    >> runs. I think this is a design flaw, ideally, each subsequent layer
    >> in the layout should only have access to and manipulate directly the
    >> layer immediately below. This not being the case, the issue that I
    >> think would prove the real problem is how attach the run classes to
    >> the Pango engine.
    >
    > Martin?
    >

    This is just one of the problems. I think that we would be using pango
    outside it's use-scope and this would quickly come back to bite us. We'd
    have to solve printing issues, zoom issues, breaking issues in Pango
    before we could recover our functionality. At the same time we'd give up
    our own native graphics inetrfaces for platforms other than Unix.

    I stand by what I said earlier. The overlap of interest between us and
    pango is their treatment of complex scripts with overlapping characters
    and their international line breaking rules. What we need to do is to
    expand Tomas's UT_ContextGlyph code to include the knowledge enbedded in
    Pango (and Graphite's) language specific modules. With that we can use our
    own layout engine to place characters where they need to be both on screen
    and on paper.

    I'm very glad you'reinterested in this Daniel. Please investigate the
    pango code-base and our own to see if we can extract this information and
    re-use it.

    Cheers

    Martin

    > Regards,
    > Daniel



    This archive was generated by hypermail 2.1.4 : Sun Nov 09 2003 - 20:12:06 EST