Frank da Cruz wrote:
> [debating the merits of hex byte glyphs]
> On the other hand, if we conclude that hex byte pictures are
> not needed at all, then we can not fully emulate the terminals
> that have them.
Since Frank keeps trotting this notion out, I'll repeat that it
is *not* true. [Apologies to spectators disinterested in
terminals.] It may make your job harder if you are insistent
on making some aspects of your emulation identical to a particular
incarnation of vendor hardware, but you can still do it. Of course
you are not manifesting an identical keyboard under your users
finger tips*, nor are you providing them with a device of similar
heft as some of those early 5250's had, but for some reason you are
bound and determined that the contents within the window you are
displaying on someone's GUI desktop have the same layout and
A few days ago at the bank I noticed that the PC being used had a
mouse with a few menu buttons and a graphical background but in
terms of field fill acted an awful lot like a 3270 series terminal.
The colours were not right and instead of padlocks and lightning
bolts there were text messages in the status area like "Please wait"
that actually meant something to the operator.
*I had more trouble with altering keyboard behaviour between
different models of terminal than I had with imperfect or even
incorrect glyphs being displayed.
> > The reductio ad absurdum of the approach taken in this proposal has
> > got to be XX1F SYMBOL FOR NOT A CHARACTER (!!), whose glyphic representation
> > is a dotted box with four "F"'s in it. Does anyone else feel that we've
> > just stepped through the looking glass here?
> When putting together this table, it occurred to me that when debugging
> Unicode data streams (e.g. in a Unicode-based line monitor or protocol
> analyzer), it would be good to be able to show the presence of a character
> that is "guaranteed not be a Unicode character at all". There will be a
> strong temptation to use it as an escape, and debuggers will want to show
We must help them resist this temptation, or at least the expectation
that every single character in the datastream must be represented
in a single glyph. Putting [U+FFFF] in the text stream should be
pretty clear. Use an alternate font/colour if you want to ensure
the don't mistake it for inband text. Or if you are printing the
datastream as a Unicode string, render as if it were Unicode - if
you want to see all the illegal values in the datastream display
it in a hex dump (in the old fashioned ASCII way of using 2
characters and a space per byte.) Many a debug dump has been known
to display the two formats side by side... Dumping all the
features everybody would like in their local implementations into
the standard is not a good idea - as several standards have shown
the hard way.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:42 EDT