--- Tomas Frydrych <[EMAIL PROTECTED]> 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
