Re: RFC: bug 5619

From: Dom Lachowicz (domlachowicz@yahoo.com)
Date: Sun Oct 26 2003 - 10:04:47 EST

  • Next message: Marc Maurer: "Re: commit (HEAD): gr_Caret.cpp"

    I was just giving this a bit more thought. I don't
    know if this is the same problem or not, but...

    So, when the latin ligatures were enabled, things like
    "ff" and "fi" would combine into a ligature. It looked
    like we would measure the width of "fi" instead of the
    "fi ligature". The result was that it would look like
    "fi sh".

    So, are we measuring and laying out "fi" or the "fi
    ligature"?

    Just curious,
    Dom

    --- msevior@physics.unimelb.edu.au wrote:
    > > I know that I've said this before, but I will be
    > > looking into this next week hopefully. 2.0.1
    > should
    > > still go out regardless - we can release 2.0.2 as
    > soon
    > > as this bit of work gets done. Please feel free to
    > > help out or beat me to this.
    > >
    > > I believe that the "right" solution is to have
    > tdu/tlu
    > > consistently round in one direction (down) PLUS
    > > working inside of the layout classes to do all of
    > the
    > > math bits in a numerically stable way.
    > >
    >
    > Hi Tomas and Dom,
    > Getting pixel perfect placement at
    > all zooms and for
    > printing while maintaining a single set of layout
    > units
    > will be a significant challenge. I'm personally not
    > sure
    > how to do it so I'm both of you have ideas.
    >
    > You have to make sure you can map a logical location
    > in layout units to a
    > physical location in device units in a consistent
    > and correct mannor.
    >
    > Tomas's suggestion for example would end up putting
    > the cursor at slightly
    > ahead of where it should be in each word until
    > corrected at the space
    > boundaries. This is a watered down version one of
    > the bugs in the windows
    > graphics class recently fixed by me, Dom and Marc.
    >
    > When you tackle this remember this and also
    > carefully look at issues with
    > linebreaking. I spent a lot of time to get the
    > linebreaking code to where
    > is now, which is not perfect but a whole lot better
    > than it used to be.
    >
    > With the new instant zoom verfiying linebreaking
    > works at all zooms is a
    > bit harder. I suggest you simply open a new window
    > to build a new view of
    > the current document to make sure linebreaking
    > doesn't change at different
    > zooms and resolutions.
    >
    > Good Luck!
    >
    > Martin
    >
    > > Dom
    > >
    > > --- Tomas Frydrych <tomasfrydrych@yahoo.co.uk>
    > wrote:
    > >>
    > >> Bug 5619 (and several duplicates) concerns
    > >> non-joining of Arabic
    > >> letters: where in the script letters are supposed
    > to
    > >> be joined
    > >> without a gap, we now have small white gaps
    > between
    > >> them; this did
    > >> not use to be the case up to 1.99.1, and is
    > caused
    > >> by rounding errors
    > >> in the graphics classes. It is a fairly serious
    > >> problem, which I
    > >> think needs to be addressed, but that will
    > require
    > >> revisiting some of
    > >> the old issues.
    > >>
    > >> I think the only solution to this particular
    > problem
    > >> is to ensure
    > >> that the lu->du conversion rounds down. This
    > would
    > >> not affect zooming
    > >> as long as the zoom factor is applied _after_ the
    > >> rounding, not
    > >> before it, but unfortunately, systematic
    > truncation
    > >> of character
    > >> widths leads to serious cumulative errors over
    > the
    > >> width of a line,
    > >> which we are well familiar with from the past,
    > and
    > >> which need to be
    > >> avoided.
    > >>
    > >> So I have the following suggestion: we
    > >> systematically truncate
    > >> character widths and then compensate for the
    > >> cumulative error by
    > >> inflating spaces on the line. We basically have
    > the
    > >> mechanism in
    > >> place, since that is how we do justification, and
    > so
    > >> relatively
    > >> little code should be needed for this.
    > >>
    > >> (The only other solution I can think of is to
    > avoid
    > >> upwards rounding
    > >> selectivly for such characters with which it
    > >> matters. While it would
    > >> be doable, it would me much more messy and
    > >> computationally
    > >> intensive.)
    > >>
    > >> Anyway, I would appreciate some comments or
    > >> alternative solutions.
    > >>
    > >> Tomas
    > >
    > >
    > > __________________________________
    > > Do you Yahoo!?
    > > Exclusive Video Premiere - Britney Spears
    > > http://launch.yahoo.com/promos/britneyspears/
    >
    >
    >

    __________________________________
    Do you Yahoo!?
    Exclusive Video Premiere - Britney Spears
    http://launch.yahoo.com/promos/britneyspears/



    This archive was generated by hypermail 2.1.4 : Sun Oct 26 2003 - 10:05:50 EST