Re: Case mappings

From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Sun Mar 13 2011 - 16:43:43 CST

  • Next message: Doug Ewell: "Re: Case mappings"

    On 3/13/2011 2:47 PM, Philippe Verdy wrote:
    > 2011/2/11 Doug Ewell<doug@ewellic.org>:
    >> QSJN 4 UKR<qsjn4ukr at gmail dot com> wrote:
    >>
    >>> There are several different applications of the letter cases. They
    >>> are used stylistically, for example, the using a capital or title
    >>> letters in the headers, grammatically, when the capital letter
    >>> identifies the beginning of the sentence, the proper name, any name
    >>> in German, and semantically, for example, in SI units or chemical
    >>> symbols.
    >> This is exactly why it is inappropriate to apply case-change operations
    >> indiscriminately to arbitrary snippets of text. ...
    >>
    >>> To support all these cases, it would be nice to use special control
    >>> characters in the text,
    >> Modifying all existing electronic text to include such an invisible
    >> control character,
    > Why « all » texts ? This was not in the proposal.
    >
    >> and requiring all users and processes to enter it
    >> reliably,
    > Why « all » users ?

    And more arguments along the same line.

    The idea of marking up text spans that have particular casing behavior
    (requirements) is not necessarily a bad one. The problem is that this is
    only useful if the text is later subjected to an automatically applied
    case mapping.

    Ordinary text (a random paragraph) is not usually case transformed at
    all. There's little payoff for anyone to mark up text with this
    information, then. (And this is independent of whether the markup
    consists of control characters in the character stream or markup in the
    usual markup level). Not only is there little payoff, but there's little
    chance for users to encounter any bad consequences from having applied
    the *wrong* markup.

    For cases where text must be case-modified on the fly for particular
    styles (headers, whatnot) allowing for this kind of markup on the
    markup level *might* make sense. It's cleanly removable when text needs
    to be exported as plain text, so it doesn't silently sit around and
    cause trouble later.

    But character codes are a bad solution here, especially as they would
    require scoping (faking this by turning all characters into combining
    sequences with individual marks doesn't make the situation any better).

    Finally, the markup needs to be of a way that addresses the transform,
    not the case.

    There are some part of text that definitely get uppercased in UPPERCASE,
    but not uppercased in Tiltecase. Having a markup that says whether text
    may never be transformed, sometimes be transformed etc. is a much more
    complete solution than a "preceding character is lowercase" combining mark.

    A./



    This archive was generated by hypermail 2.1.5 : Sun Mar 13 2011 - 16:46:32 CST