Subject: Re: Bidirectional support
From: Leonard Rosenthol (leonardr@lazerware.com)
Date: Fri Dec 15 2000 - 14:42:48 CST
At 11:36 AM -0800 12/15/00, WJCarpenter wrote:
>That could certainly be done. The downsides are (1) storing the text
>another time (since it's really remapGlyphs [not the SmartQuotes
>feature], and that doesn't change the real text, just what is
>displayed),
Wait? Are you saying that remapGlyphs does NOT change the
actual text in the run (ie. when the user types a regular quote, we
don't put a smart quote into the text)? I'm sorry, but that's
WRONG! The whole point of smart quotes is to generate the correct
data - not to do it dynamically - so that as the document is moved
around (xferred, xlated, etc.) the smart quotes are in there as well.
So if we fix remapGlyphs to actually change the source text,
AND only do it once during run coalescing, then we'll finally be
doing the right thing, AND we make some noticeable speed improvements
with a simple change.
>lr> Given that memory is cheap, why not consider adding another field
>lr> to the run structure to (optionally) store the UTF-8 version of
>lr> the stream, so that, again, you only have to do this once?
>
>This could be done per-platform, since some need it and some don't.
Fine, then it's get done by those platforms that can't handle
UCS2? And which are those? I know Windows can draw UCS2 just fine,
so is it just X?
>lr> Why? When you scroll, you don't need to be doing any recalc -
>lr> just repainting already calc'd information.
>
>Currently, I don't think AbiWord remembers the calculated stuff. It
>uses it for immediate rendering and then forgets most of it.
OUCH!! Well that would make for all sorts of major
improvements! In general, the only thing that should ever have to be
calculated is the currently edited paragraph (and potentially
anything from there to the end of the document).
>lr> Not only that, but it prevents proper future handling of kerning
>lr> pairs, ligatures, etc.
>
>AFAIR, all of the platforms has width-calculating code that tallied up
>the widths of all the individual characters and took the total as
>AbiWord's idea of the width of the string. If any platform's renderer
>did kerning, ligatures, etc, that could make that assumption false.
If the width calculator is a simple (for each character,
totalWidth += CharWidth(c)) then you're are right IF and only IF the
renderer did kerning and such. However, I don't believe that any of
our current renderers do use those features, in which case we just
luck out!
The correct thing to do is to actually measure the STRINGS
just as they will be passed to the renderer, so that it could
(potentially) do the right thing. For example, if someone were to
replace the current Windows GDI calls with calls to UniScribe, or the
current X calls with calls to Pango - then we'd need to redo the
width calcing code since those two renderers both handle kerning and
ligatures.
>So, such platforms would have to start having a real string width
>function. Not a big deal, but something to remember.
Correct! In fact, I'm surprised that string width
calculation isn't already extracted out into platform centric code
for just this reason.
>(I was the one who originally made the string width function into XP
>and implemented in terms of a platform-specific character width
>function.
OK, so we blame you ;).
>I think all the platform-specific string width calculators
>that got replaced just iterated over the characters and got a total
>anyhow. Hope I'm not misremembering.)
Again, that may have been the way they worked at the time,
but that is the wrong way to do it and MAY also be the reason we are
now seeing the bugs in drawing vs. selecting.
Anyone want to back up this change?
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 - 14:43:31 CST