From: msevior@physics.unimelb.edu.au
Date: Sat Oct 25 2003 - 21:20:47 EDT
> 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/
This archive was generated by hypermail 2.1.4 : Sat Oct 25 2003 - 21:21:57 EDT