From: Dennis Heuer (email@example.com)
Date: Mon Apr 13 2009 - 20:20:15 CDT
On Mon, 13 Apr 2009 17:46:17 -0700
"Tex Texin" <firstname.lastname@example.org> wrote:
> It would also create problems to now have commands in Unicode which would
> potentially interact or conflict with higher level formatting commands.
you show up a deeply rooted logical error. those standards are mainly
existing because there was no alternative (for the initial purpose.)
however, dealing with this hen and egg problem is fairly easy. the HTML
crew can handle the ambiguity itself by insisting on a default
behaviour and providing an attribute the next update. it will spread
fast and widely, as always in the world of HTML.
> More importantly there are international standards for formatting text
> called markup languages, that are much more powerful than a small set of
> control character commands would be, and which coexist quite well with
> Unicode encoding and are portable.
> Given the existence and wide support for HTML, etc., the case for such
> commands in Unicode is extremely weak.
the main problem with 'international standards' (don't understand this
argument. the international character-set standards didn't hinder the
people behind unicode, did they?) is that they are complex, bloated,
many, and not easy to parse. this is especially true in respect to small
editors and ***plain text files***. i was very verbous on this, which
makes me wonder why it wasn't read. what the heck HTML has to do in a
plain text file (say a shell script)?? this is also the reason why
common wiki or blog systems stayed away from including HTML but
'invented' (felt forced to find) an own, short form of writing
formatting rules. as you can imagine, if you think more deeply about
it, HTML is not the solution to the problem, be it a standard or not.
this also relates to ISO-2022 being a dead fish, which doesn't
astonish me a bit.
unicode shall not grow into a meta language. the only formatting rules
(commonly used and most neccessary also in the explained cases where
they are still missing) to be put into unicode are those which stand
for themselves or act as on/off-switches. not more or less. in case of
font size, this means that there are keys for most used sizes and steps
like +1pt, +2pt, +5pt, and +10pt. that's it. no meta-programming
neccessary. or, do you consider ODT to be used instead of this? explain
that to a gnomepad, emacs or wikipedia user.
many thanks for reading,
This archive was generated by hypermail 2.1.5 : Mon Apr 13 2009 - 20:22:17 CDT