From: Andrew Dunbar (firstname.lastname@example.org)
Date: Thu Aug 15 2002 - 23:25:34 EDT
--- Tomas Frydrych <email@example.com>
> > The main reason we have smart quotes turned off
> > right now is not because we weren't getting the
> > context right or anything like that. The problem
> > was that we have smart quote code sprinkled all
> > over the place trying to do the same kind of
> > guessing under various conditions. In some cases
> > this proved so difficult that we had crashes or
> > endless loops. Undo was the main problem.
> > Various attempts were made to fix it but it was so
> > hairy it kept cropping up.
> Also, the present engine is anglo-centric (the code
> commited yesterday handles Czech and Slovak, to add
> any other language just a couple of lines of code
> are needed).
I'm so in favour of "smart quotes for the world" you
wouldn't believe it (:
> The reason why I suggested using the shapping engine
> is precisely because it gets rid of the undo
> problems because the remapping is happening in the
> view space, not in the document space.
It's great that it fixes the undo problem but as
somebody else mentioned, I think users will be
when they make a document with round quotes in Abiword
and find them missing (or perhaps different) in every
> I have been thinking about the two stage remapping
> you suggested in the other posting: remaping in the
> document space to the nice quote and further
> remapping in the view space if the nice glyph is
> not available. At first, I thought that was a good
> way to go, but I foresee one rather serious problem
> with the following scenario:
> (1) the user presses single straight quote
> (2) our algorithm remaps it to a single left quote
> in the document
> (3) single left quote is not present in the font, so
> in the second stage
> we remap back to single straight quote in the view.
> The problem arises if a keen Linux user wanted a
> single straight quote in the first place; she will
> see the straight quote, but will have no indication
> that actually the document now contains a left quote
> instead. She will then pass it onto her pal, a
> die-hard Windows man, he will open the document and
> get a single left quote.
It's my serious opinion in this case that a user
wanting to create documents with a nice quality mix
of curved and straight quotes that they should have
their fonts set up to handle it. With Xft this is
going to be the norm in no time. It's also possible
to set up TrueType fonts I believe, and it would even
be possible (though I can't guarantee it) that you
can set your locale to something like en_US.cp1252 and
make 8-bit fonts with the curvy quotes in if you
really really wanted to avoid Xft.
In fact now that you've got me thinking about it, it
makes a whole lot of sense to put up a warning dialog
when a user tries to enable smart-quotes on a system
that can't physically display them.
My advice would be that the keen Linux user be keen
enough to update to the cool modern typography systems
that Linux can finally do, or be keen enough to
understand the trickiness of trying to use curved
quotes on a box that can't display them.
When such a keen user does take on such a task, she
can use the "Show paragraphs" or "show remapped
characters" feature that we're going to need anyway.
> Even worse if we map the straight to a left quote
> when really right qoute would have been required,
> for instance if the Linux user used the straight
> quote as a soft breathing mark. In that case her
> Greek tutor will get a rough breathing marks instead
> and she will fail her assignment.
This is an even better case for using Xft or setting
up TrueType fonts. Also if you're doing Greek and
is the right way to enter a breathing mark, the
language-specific smart quotes code should know about
> In other words, the two stage mapping makes it
> impossible for the user to know what is in the
> document and what the document will look like for
> another user; this, combined with the fact that the
> "smart" quote algorithm is flawed by definintion,
> means a guaranteed bad presentation of the document
> every so often.
The only way for a user to ever truly know the
difference between character "a" and character "b" no
matter which system we use is to have a font with both
characters in it.
> That is the main reason why I am really not keen on
> the idea of remapping the quotes in the document
> space. If we do the remapping purely in the view
> space, the user always knows that the character in
> the document is the character input.
But how will they know this? The user will think the
document looks like the text on the screen. If they
have a font with both characters, they will be wrong!
> She can choose at any stage to view what the
> document will look like on a computer that does not
> have the smart quote glyphs (by turning off the
> enable smart quotes preference), since the smart
> quote translation is non-destructive.
> In this scenario we would have an extra preference
> 'export smart quotes' and if the smart quotes were
> enabled, exporters into formats such as Word or rtf
> would translate the quotes on export in a manner
> identical to that used by the view or leave the doc
> as it is, depending on the 'export smart quotes
> value'. This would give the user ultimate control
> over the presentation of the document.
It just all sounds more complicated than "just
> Instead of using the non-breaking-zero-width space
> to allow override of shaping algorithm, we could
> define two special characters in the user part of
> the Unicode space, one to simulate a separator and
> one to simulate a part of a word; naturally, we
> not draw nor export these into non-AW formats.
As a separate issue I'm against special characters
in documents. I think any special stuff should be
done in the format, not in the content. If such
things needed to be saved, they should have XML tags.
Just more opining from me anyway (:
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
This archive was generated by hypermail 2.1.4 : Thu Aug 15 2002 - 23:28:23 EDT