From: Andrew Dunbar (hippietrail@yahoo.com)
Date: Tue Aug 20 2002 - 04:18:20 EDT
--- Tomas Frydrych <tomas@frydrych.uklinux.net>
wrote:
>
> > 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.
>
> It is worth keeping in mind that the Linux problem
> with typographic quotes is not that of fonts, it is
> one of encoding. AFAIK, Latin1 does not have single
> typographic quotes codepoints (bad for the UK
> user!) and Latin2 does not have either single or
> double; no one is going to be running en_GB.cp1252
> just because AbiWord messes up with quotes.
But surely the only times when the encoding matters
for AbiWord is old-style fonts, and plain-text
import/export. All other major file formats I'm aware
of also support the full Unicode range. AbiWord will
behave the same no matter what encoding you have set
in your locale for all other things. Won't it?
> My point in the original example was that she may
> not want to use curved quotes, but that the double
> remapping obscures from her that she is doing so;
I just don't see this. If she doesn't want curved
quotes, she turns off smart quotes.
I don't see how such a case is more obscure or more
common than seeing the curved quotes while having
straight quotes saved as your current solution does.
> I am not saying that remapping to something more
> meaningfull than the undefined glyph symbol is not a
> good idea, merely that it has to be done in a way
> that the user can always tell that what she is
> seeing has been remapped from a non-existent
> glyph, that What You See Is Not What You Have.
>
> It seems to me that a best way to do this would be
> to have a separate fp_AbsentGlyph class of run which
> would contain a static remapping table for common
> glyphs, such as the typographics quotes, and in
> screen context it would draw in a distinct manner,
> say yellow on dark blue background (it would print
> normally, naturally).
I agree 100%. This is why I proposed the addition to
Show Paragraphs or similar.
I for one would not want to see this all the time.
I would only want to enable it for proofing to make
sure everything is okay. Just as people like to make
sure they haven't used spaces for tabs. Non-breaking
spaces, soft-hyphens, and line-breaks as opposed to
paragraph breaks all fall into a similar category the
way I see it.
> > 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.
>
> This might be a good idea, but it does not address
> the problem I am really concerned about, which is
> that by destructive, non-optional, translation of
> the quote glyphs you are making the document non-
> portable.
I'm certainly not in favour of this. I only want to
be able able to create typographically accurate
documents regardless of how the screen renders them.
I still prefer to have smart-quotes off by default.
There's nothing non-optional about having a
smart-quote
setting.
> > Also if you're doing Greek and this is the right
> > way to enter a breathing mark, the language-
> > specific smart quotes code should know about it.
>
> I was not thinking of her typing in the Greek
> alphabet, I was thinking of her transliterating
> Greek using Latin1 characters, which is fairly
> standard in academia. Our fault here is not that our
> smart quote algorithm will get the translation
> wrong, she is using the quote in a way that makes it
> impossible for us to make the correct choice;
I think the very best solution is the smart-quote GUI:
http://bugzilla.abisource.com/show_bug.cgi?id=3891
and that my other recommendations all solve this
problem better than always writing straight quotes to
files.
> our fault would be that the double remapping would
> hide from her the fact that we made error. I see no
> simple way around this scenario, even if the
> remapped character is displayed differently on
> screen, it would merely indicate that the contents
> of the document are different from the screen, not
> that they are wrong.
There is no simple way. You have to proof your work
if want the very best results. Only the author can
know if it's wrong or not.
I really don't think your soft-remapping dumb-to-smart
quotes is bad, I just think it solves a less likely
set of problems. I was going to suggest including
both
soft dumb-to-smart and smart-to-dumb remapping as
options but I'm worried that such options are going to
confuse most users.
Any way it is done we need to be able to create
documents with arbitrary characters, some of which may
be missing from the keyboard or missing from fonts.
Thus hard-remapping is needed whether or not we have
soft-remapping. It's quite a separate issue.
As usual I'd like to know what the Doms and Hubs think
about all these interrelated problems.
Andrew Dunbar.
=====
http://linguaphile.sourceforge.net/cgi-bin/translator.pl http://www.abisource.com
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
This archive was generated by hypermail 2.1.4 : Tue Aug 20 2002 - 04:21:54 EDT