Frank -- I reviewed the latest draft and have more comments...
> ... All proposed characters have Combining Class 0 (although
> some of the characters are designed to "combine" (connect) with other
> characters in adjacent cells).
You might re-word the above a bit:
... (although some of the corresponding glyphs must be designed to
"combine" (connect) with other glyphs in adjacent display cells).
> Digital VT220 and higher terminals, as well as Televideo, Wyse, HP, Perkin
> Elmer, and other models, allow the user to select whether control characters
> are acted upon or displayed graphically. Unicode itself includes its own
Well, to my mind that indicates that these aren't NEEDED to be encoded at
all! Just set the terminal emulator into the "display controls" mode and let
it display the glyphs that the emulator has for the control codes. They
should not need to be encoded, since they're merely a variant representation
that the terminal does internally. It's unfortunate that my argument is
weakend by the fact that we already have a bunch of control pix encoded...
I do have a problem generally with adding "picture" characters to correspond
to existing things that are Unicode-specific. For instance, I see it as
just pointless to add "Symbol for En Quad" or "Symbol for Right-to-Left
Override" or other such things, unless you can show that this and other such
codes are absolutely necessary for supporting the emulation of these Actual
Physical Terminals. Of course you say:
> (1) There is no known need for these symbols when emulating current
> terminals. In the future, if/when terminals are based on Unicode, they
> might be useful in that context. In the meantime, makers of word
> processors, Web browsers, etc, might have a use for these glyphs.
So, it's my opinion that we should note the possible use, and move on.
I.e., don't propose adding them now on the off chance the *someone* might
have a user for them. Wait for a use. It's perfectly possible in
implementations to have a "show control" mode that shows controls as glyphs,
without having the pictures for them encoded as characters. So if characters
aren't in support of the graphical requirements for Actual Physical
Terminals, they should not be proposed. Or should be proposed separately.
((Here's a little side-bar... It's sometimes desirable to separate things
into independent proposals so that characters which appear to be
"non-controversial" or less controversial can be put into one proposal and
the controversial stuff in another. That way, when committees look at them
"formally" and vote, things move more quickly. In practice, this can lead to
forward progress in pieces rather than multiple rounds back into the draft
stage for an entire set of stuff. This happened recently with Tibetan
extensions that were recently approved for addition. The ad-hoc group of
experts removed everything controversial and quickly came to consensus on an
agreed set for immediate proposal. If they had waited until the last bit of
controversy were resolved for a few items, they would still not have a
I guess it would be nice to see this document broken into two really major
sections -- one is an analysis of the existing controls, with recommendations
about usage and mappings to character sets for popular Actual Physical
Terminals, as best you're able to determine. The other section would be
> Table 5.2: C1 Control Characters
Table 5.2 is particularly valuable information of the "here's what exists"
variety... and given the widespread use of ISO-6249 controls, it is probably
worth adding these. You also say in the notes "ISO-6428". Is that different
from 6429? Or just a typo?
> 5.3. EBCDIC Control Pictures
Likewise, this is valuable information. It would be good to somehow call
out the proposed additions, perhaps by putting an asterisk before or after
the names. Because they're in EBCDIC order I found it a bit hard to discern
precisely which are proposed additions.
Someone from IBM should look at the 3270 stuff... I suppose someone will do so.
Another thing that should be discussed is when adding "symbol for foo" one
should also add "foo" itself. For instance, there is no "Start of Field"
control character; but a picture of it is being proposed. Probably UTC needs
to hash through *that* issue...
> Table 6.1: Math Symbols for Terminals
You should look at the glyph pieces in the Adobe Symbol font, which is a
widely used font. Many of these are contained in the Symbol font (0xE6 to
I believe the following two characters are just masculine and feminine
ordinal indicators, and are already encoded between 0x80 and 0xFF, as part of
ISO Latin 1. They are probably just variant glyphs... unless the
documentation distinguishes them and they occur in pairs with lower-case. Do
you mean "small" or "capital"? Or are they really different?
> E0B3 Latin small letter a with underbar SNI Math 04/04 (2)
> E0B4 Latin capital letter O with underbar SNI Math 04/09 (2)
By the way, I'm opposed quite strongly to adding the 256 "hex bytes" under
any circumstances. Good thing they're an indepenedent proposal. The total
proposed, including Hex Bytes is 448. Without Hex Bytes, it's a modest 192,
and I think it could be reduced with a little more unification. Of course
reduction will offset the expected increase due to other terminals clamoring
to be included...
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:42 EDT