From: Dennis Heuer (firstname.lastname@example.org)
Date: Mon Apr 13 2009 - 20:06:28 CDT
Many thanks for the quick answers, and for the links. btw. i get all
emails three times. does this mailing list obey to this weird
however, i didn't understand the ISO-2022 standard in full in this
short time. but this is also just underlining my proposal. ISO-2022
tries to do some many things at once a very dominating way. this is not
what i mean or what i ever wanted to use. what i mean is that there
should be a simple switch key, possibly defining how many characers in
follow specify the new character space (16bit is enough, i think.)
that's it. and, for the character set recognition, one could even use a
more flexible algorithm that doesn't recognize by size but by content.
the character-space key should not be the escape key for 'good
reasons' (i prefer hints or links instead of those comments, btw.).
it's always the escape key! i think the escape key dreams of escaping
its special role every night. the escape key is used most ambiguously
of all common characters.
escape codes are ambiguous too because of the many existing. this is
why unicode specifies that 'if' ISO-2022 is used (...). this is not
what i mean. i mean a special character that, in all cases, states that
now another character set is used and the program will not be capable
of printing senseful text if it doesn't support character spaces. this
shall be clear and always valid up to eternity and by no means
relativated by an 'if'. the character is not to be used otherwise, and
the program may print an error. escape sequences, instead, are
generally just filtered out.
also, and i wrote that already, i doubt that unicode will ever be the
only character set in use. this target, specifically considering all the
fancy characters, is fully illusionary. and, as i already wrote,
unicode itself would profit from keeping new code blocks outside the
official character set until some years of critique have passed them.
this makes sense if you think a bit longer about it.
This archive was generated by hypermail 2.1.5 : Mon Apr 13 2009 - 20:08:31 CDT