Re: commit (HEAD): bidi work

From: Tomas Frydrych (tomasfrydrych_at_yahoo.co.uk)
Date: Sat Apr 24 2004 - 07:36:46 EDT

  • Next message: Tomas Frydrych: "commit (HEAD)"

    Hi Martin,

    > Putting in the ability to turn off BiDi processing is something
    > decided not to do ages ago since it adds to the complexity of the
    > application. Even thinking about how to do it distracts you from
    > what the rest of the project needs from you.

    Just to explain little bit more. The situation is very different from
    what we used to have with the bidi enabled and not enabled builds in
    the past. The whole of the layout engine remains a fully enabled bidi
    engine, only the built-in shaper does not shape with bidi support
    turned off and calls to fribidi are redirected to dummy functions
    that just classify everything as LTR text. There are only 4 #ifdef's
    outside of the UT_bidi*() funcitons and gr_ContextGlyph class
    (fp_Run::getVisDirection(), fp_TextRun::breakMeAtDirBoundaries(),
    fp_TextRun::breakNeighboursAtDirBoundaries, gr_XPRenderInfo::cut()).
    Thus, the increase in overall complexity is very small. Having said
    that, I should have consulted on this -- I was just to excited
    realising how easy this was.

    > That statement from me sounds really weird in the context of a free
    > software project and I've been guilty of the same behaviour myself. It's
    > partly from my experience that I give the above advice. Of course your
    > time is yours to spend how you wish.

    Point taken.

    Tomas



    This archive was generated by hypermail 2.1.4 : Sat Apr 24 2004 - 10:50:28 EDT