Subject: Re: Bidirectional support
From: WJCarpenter (bill-abisource@carpenter.ORG)
Date: Fri Dec 15 2000 - 15:34:41 CST
lr> Wait? Are you saying that remapGlyphs does NOT change the actual
lr> text in the run (ie. when the user types a regular quote, we don't
lr> put a smart quote into the text)? I'm sorry, but that's WRONG!
lr> The whole point of smart quotes is to generate the correct data -
lr> not to do it dynamically - so that as the document is moved around
lr> (xferred, xlated, etc.) the smart quotes are in there as well.
You're confusing two different features that seem related simply
because the some of the same characters come into play (and because
the were implemented at about the same time by the same person, etc,
etc).
"remapGlpyhs" is a feature which affects only display/print. If you
try to display/print a character which happens to have no glyph on
your platform, the remapGlyphs feature can dynamically map it to
another character which does have a glyph. remapGlpyhs doesn't
permanently alter the text in question; to do so would definitely be
wrong since different platforms have different sets of glyphs. Users
on the same platform types could have different sets of glyphs if they
had different fonts installed.
The canonical example (and probably the one that adds the most to the
confusion) is that on Unix we don't have glyphs for the four Unicode
smart quote characters. remapGlyphs default settings map those
characters to the ASCII "straight" quote equivalents if and only if
there is no glyph for them when they are being drawn/printed. It
would be wrong to change the text to "straight" quotes permanently,
though it would be perfectly fine to replace them in the look-aside
scratch copy of the run text, as you have proposed.
"SmartQuotes" is a feature that does permanently change the text. It
gets changed at the time the text is inserted into the document. (At
design time for this feature, Sam was trying to talk me into
dynamically doing the SmartQuotes substitution at render time, but I
wasn't confident of that approach's fidelity to user intent.) The
implementation of this doesn't consider whether or not any particular
glyph appears in a font you happen to be using (that would add
considerable code complexity to the decision and would probably take
it out of XP land).
As you might guess, confusion sometimes arises because on Unix you can
get SmartQuotes substitution in a document, but there are no smart
quote glyphs. In that case, remapGlyphs will map them back to
"straight" quotes. If you ship the saved document to your
MSWindows-bound friends, they'll see it displayed with smart quote
glyphs because their fonts have the glyphs.
Anyhow, I hope this clarifies things enough that you understand the
decision that remapGlpyhs doesn't permanently change the text.
lr> Correct! In fact, I'm surprised that string width calculation
lr> isn't already extracted out into platform centric code for just
lr> this reason.
The function GR_Graphics::measureString() is the generic XP code that
is defined as the sum of widths of characters. I believe, but have
not actually tried, that platform-specific subclasses could redefine
this function to Do The Right Thing. So far, there hasn't been a
better right thing, as you have explained by example.
>> (I was the one who originally made the string width function into
>> XP and implemented in terms of a platform-specific character width
>> function.
lr> OK, so we blame you ;).
Yeah, I happily accept blame for taking existing logic and abstracting
it into XP code without changing the net effect :-). Seriously,
unless I made a mistake, each platform had its own version of summing
the total of individual characters. At the time I made the code
change (Jun/Jul 2000 time frame), I wouldn't have been bold enough to
change the code if it had the detrimental effect you're talking about.
I'm an old troff guy, so I know all about kerning, ligatures, and
other such typographic magic.
-- bill@carpenter.ORG (WJCarpenter) PGP 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
This archive was generated by hypermail 2b25 : Fri Dec 15 2000 - 15:34:41 CST