Subject: Re: Bidirectional support
From: ha shao (hashao@chinese.com)
Date: Fri Dec 15 2000 - 22:18:45 CST
On Fri, Dec 15, 2000 at 10:54:26AM -0500, thomasf@qnx.com wrote:
> 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. 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.
>
> There are several things at work here. As Martin has already indicated,
> we do in fact draw strings of text. The problem is that those strings
> of text have to be converted for the "smart quote replacement" dohicky
> thingamabob. So we pass in a buffer of UCS2 characters, then we have
> to allocate a temporary buffer to to the translation of the characters
> (with the remapGlyph stuff), then most of us end up having to convert
> the UCS2 characters to a multibyte stream of UTF-8 characters. This
> is all _just_ in the drawing code.
>
> Moving up a level and taking a look at the whole "what happens when
> you scroll" we have to iterate through almost the entire document even
> if we are only looking at a page of the document. This "looking at
> the document" involves running through and getting character width
> calculations for the whole thing. The problem of course here is that
> the character width information comes in two formats on _most_
> platforms. There is the width of the actual glyph and then there
> is the width which should be used for cursor positioning. We don't
> discriminate between the two and this causes problems 1) In jitter
> 2) In the fact that our highlights clip chars.
>
> Don't understand what I'm getting at ... take a look at:
> http://qdn.qnx.com/support/docs/photon20/prog_guide/fonts.html
> and more importantly:
> http://qdn.qnx.com/support/docs/photon20/lib_ref/pf/pfextenttextcharpositions.html
>
> One way to solve this problem (well I was only looking at the
> clipping problem) would be to indicate in the drawChars
> function return code whether the first and last characters
> cause us to draw outside of the "width" of the string we
> are asked to display.
>
But how much of all there are gtk+ specific issues? It's mentioned
that the win32 version is much more clippy than the gkt+ version.
It's better to identify the problem on gtk+ side for short term
solution.
-- Best regard hashao
This archive was generated by hypermail 2b25 : Fri Dec 15 2000 - 22:18:08 CST