From: Asmus Freytag (email@example.com)
Date: Thu Dec 20 2007 - 06:20:34 CST
On 12/20/2007 1:58 AM, Karl Pentzlin wrote:
> The characters
> U+203C DOUBLE EXCLAMATION MARK
> U+2017 DOUBLE LOW LINE
> U+203E OVERLINE
> U+21A8 UP DOWN ARROW WITH BASE
> U+221F RIGHT ANGLE
> U+2302 HOUSE
> U+2310 REVERSED NOT SIGN, annotated as "beginning of line"
> are contained in the Unicode subset "collection 282 MES-2"
> (Multilingual European Subset) as specified in ISO/IEC 10646.
> I did not find any information of the history and purpose of MES-2.
> (does anybody have a hint?)
> I suspect that some character sets like IBM PC code page 437 were
> merged in that standard (which contains several characters from the
> list above).
> My questions:
> Is there any need or evidence for usage of U+203C DOUBLE EXCLAMATION
> MARK within Latin script context (e.g. because a specific font design
> is necessary which is different from a sequence of two exclamation
> marks U+0021?
This is a compatibility character for East Asian usage, where the
character cell is so much wider than the mark. In Latin context, using
two exclamation marks makes more sense. Trying to cram this character
onto a keyboard will make it less usable, rather than more usable, I
> Is there any need or evidence for usage of the other characters of the
> list where the context is not terminal or block graphic specific?
> (My question is related to my posting "[OT] character collection for an
> international keyboard layout (ISO/IEC 9995-2 and 9995-3)" from
> I presume that there is no need to include the listed characters in a
> keyboard layout design (even when the attempt succeeds to integrate a
> relative large symbol set in a keyboard layout), but I want to know
> if I am wrong with this.)
Under the assumption that you also remove all the other mathematical
operators, you can safely ignore that list.
Again, when one is thinking about character input, one should design
(the requirements for) a total, integrated solution, not just a keyboard
layout by itself. This is especially important where the set of
characters is to be offered to the user is large. Another example, to
highlight this point: think how limited the texting capabilities would
be on telephone devices, if it was a requirement to have the keypad
function only with traditional shift modes and layers.
Instead, what most people actually use is an input method. The T9 input
method for texting suffers from being tied to a language (and I can't
get the languages I want on my device). Creating a multinlingual
specification for how an input method can augment a more focused
keyboard design, would move things forward. A focused design would allow
easy access to *common* letters and accents and leave all oddball stuff
to the input method.
> Any information is appreciated. Thank you.
> - Karl Pentzlin
This archive was generated by hypermail 2.1.5 : Thu Dec 20 2007 - 06:22:49 CST