Re: feasible smart quote solution

From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Thu Aug 15 2002 - 05:46:04 EDT

  • Next message: Alan Horkan: "Re: commit head: quotes handling in the shaping engine"

    > 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). 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.

    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.

    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.

    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.

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

    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 would not draw nor export
    these into non-AW formats.

    Tomas



    This archive was generated by hypermail 2.1.4 : Thu Aug 15 2002 - 05:51:45 EDT