Re: feasible smart quote solution

From: Andrew Dunbar (
Date: Thu Aug 15 2002 - 23:25:34 EDT

  • Next message: Martin Sevior: "commit: Implement insertRow"

     --- Tomas Frydrych <>
    > > 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
    other app.

    > 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
    to me.

    > 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 (:

    Andrew Dunbar.

    > Tomas


    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