From: Asmus Freytag (firstname.lastname@example.org)
Date: Sun Mar 13 2011 - 16:43:43 CST
On 3/13/2011 2:47 PM, Philippe Verdy wrote:
> 2011/2/11 Doug Ewell<email@example.com>:
>> 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
>> 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
> 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
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.
This archive was generated by hypermail 2.1.5 : Sun Mar 13 2011 - 16:46:32 CST