Subject: Re: Bidirectional support
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Fri Dec 15 2000 - 07:24:59 CST
On Fri, 15 Dec 2000, Mike Nordell wrote:
> Tomas Frydrych wrote:
> > and it does impact the drawing performance at least a bit. What do
> > you guys think?
>
> The drawing performance is already horrible. Not to mention the quality. At
> least in Win32 the next line overwrites the bottom pixels from the previous
> line.
The Win32 version of abi is substantially faster in scrolling than the gtk
version. On my laptop if I hold down the down arrow key abi keeps pace
scrolling. On gtk it gets badly behind.
This is most easily tested with spell checking turned on, writing
> jibberish that does get "squiggle", starting writing on a new line and watch
> those squiggles get partially overwritten. You can also find these errors by
> just typing "spell-legal" words, but where the glyphs overlap. The last one
> just writes over the previous one.
Something was changed a little while ago that changed the yoffsets by one
pixel. A side effect of this was that sometimes moving the cursor up or
down by one line with the arrow keys didn't work. I put in a quick work
around to fix this but I think it reflects this other problem that I
haven't got around to investiagting yet.
> I think this displays a more serios problem we have, when displaying a line
> with a string (1 or more) characters of the same type (font and so on) we
> should bunch this together as a "writeText" operation, not write every char
> ourselves. That makes AW dog-slow (I know, I've been doing some performance
> tests).
Abi definately does write out several characters at a time provided
they're all the same run. During text entry they're intially single
character runs but after a bit of manipulation, (I'm not sure when exactly
this happens), the piecetable coalesces them into a single span and they
become contiguous text runs.
>
> Could be that Win32 is especially bad, but somehow I think this is the norm.
> :-(
>
> I think that supporting top-down-first instead of left-right-first would
> take some effort. Also, top-down vs. left-right doesn't (AFAIK) follow the
> same convetions regarding breaking of "lines". Am I wrong?
You're right Mike. The line breaking code would have to be substantially
modified. I think the whole idea of "lines" would have to change too. For
top down, a line and a run would have to be drawn vertically. The line
"height" would have to be calculated as the maximim "width" of the
character.
The other option would be to make each page consist of a large number of
narrow columns, filled from right to left. I haven't tested abi
performance on number of columns > 3 but the column layout code appears to
work very well. I've created documents with a combination of 1, 2 and 3
column sections on a single page. Abi appearded did a great job of layout
for that. It be that we could enable a 50 column/right left mode for
Chinese at least. This would be easier that orienting "lines" vertically.
> Looking at the size and difference between "western" and "asian" language
> editions of S/W, I'd say we try to keep these changes in separate source
> files.
>
I might be that that the many column approach could be implemented rather
easily.
I agree with Tomas though that at least initially we want bidi to be a
compile time option.
My $0.02
Martin
This archive was generated by hypermail 2b25 : Fri Dec 15 2000 - 07:25:07 CST