From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Thu Feb 17 2005 - 12:49:57 CST
At 07:19 AM 2/17/2005, Patrick Andries wrote:
>PREßBURG is the equivalent of small caps for me of Preßburg. I believe
>Unicode does not regulate small caps forms...
Unicode does not regulate small caps forms, but I disagree with your
analogy. There is a well-established typographical style called 'small
caps' and that is supported by software with a small caps style in rich
text, which is supported by high quality software / fonts in a
typographically proper manner, and simulated by other software.
The PREßBURG example is foremost a case of a non-standard orthography,
which has, secondarily, led to the need for a glyph variant. In contrast to
the small caps, which is a common feature of Latin typography, this is a
variant for an isolated character, used in a single language.
Therefore, an approach that uses a standardized variant is potentially
appropriate and should be formally considered. A standardized variant
exists when some subset of users need to make a glyphic distinction that
can safely be ignored by software when not supported. By its nature, it
affects an isolated character.
In contrast, rich text styles are typically on the level of a span of text
or longer. In the PREßBURG example, it is not clear where the natural
length of that span would be. Is it a style that applies only to the ß, or
does it apply to the entire word?
For titles, there are often styles that transform the spelling of the text
as well as set style attributes. For example, the document may contain
"Preßburg", but a title style would transform this to ALL UPPERCASE and
then apply a specific font.
Since the default casing does not work in this context, you would need a
specific
transform, one that does not change ß to SS. Given that, creating a
specific transform that changes ß to FE00 followed by ß is not any more
difficult.
If Unicode were to adopt a special alternative casing rule for ß to FE00
followed by ß (to be used based on user discretion) and define such a
standardized variant, then the rules of the game would be clear for any
software that wanted to support that feature and any user trying to create
documents for that software.
The effect on existing software would be limited to having to ignore any
uninterpreted FE00, something that is (in theory at least) already a
requirement,
even though in practice, the occurrence of FE00 is very limited.
A./
This archive was generated by hypermail 2.1.5 : Thu Feb 17 2005 - 13:08:39 CST