Re: Bidirectional support


Subject: Re: Bidirectional support
From: Leonard Rosenthol (leonardr@lazerware.com)
Date: Fri Dec 15 2000 - 10:42:34 CST


At 10:54 AM -0500 12/15/00, Thomas Fletcher wrote:
>There are several things at work here. As Martin has already indicated,
>we do in fact draw strings of text.

        That's good!

>The problem is that those strings
>of text have to be converted for the "smart quote replacement" dohicky
>thingamabob.

        This happens EVERY TIME we draw?? Why isn't this just done
once, during the "run coalescer" (as Martin called it). If the run
isn't changing, there is no reason to constantly "smart quote
replace" it.

>then most of us end up having to convert
>the UCS2 characters to a multibyte stream of UTF-8 characters.

        Given that memory is cheap, why not consider adding another
field to the run structure to (optionally) store the UTF-8 version of
the stream, so that, again, you only have to do this once?

>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.

        I'm not sure I understand why, but I'll take your word for it.

>This "looking at
>the document" involves running through and getting character width
>calculations for the whole thing.

        Why? When you scroll, you don't need to be doing any recalc
- just repainting already calc'd information.

>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.

        Not only that, but it prevents proper future handling of
kerning pairs, ligatures, etc.

>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.

        I think that is trying to solve a symptom rather than the real problem.

Leonard

-- 
----------------------------------------------------------------------------
                   You've got a SmartFriend in Pennsylvania
----------------------------------------------------------------------------
Leonard Rosenthol      			Internet:       leonardr@lazerware.com
					America Online: MACgician
Web Site: <http://www.lazerware.com/>
FTP Site: <ftp://ftp.lazerware.com/>
PGP Fingerprint: C76E 0497 C459 182D 0C6B  AB6B CA10 B4DF 8067 5E65



This archive was generated by hypermail 2b25 : Fri Dec 15 2000 - 10:42:52 CST