> As far as I know, the Unicode standard does not specify the writing
> direction or actual representation of [control pictures]. I would think that
> the two or three character forms are just variations of the same glyph.
This seems to be the consensus, and the most prominent reaction to the
proposal. Still, if I were a font maker working from the Unicode book, I'd
probably copy the pictures in it, so again, I'd suggest the next edition
show the characters diagonally within the cell, and the accompanying text
(which if I can overlook, so can a font maker :-) point out the importance
of visually preserving the character-cell boundaries by some means. The
diagonal arrangement is used on all terminals I have seen that support
display controls, so this would be the most obvious method.
> If all octet values (00 .. FF) are also going to be displayed, there might
> be some ambiguity with some of the two letter codes, e.g. FF, D1, D2, D3,
> D4, EB and EC, which should be noted in the actual font design.
Good point. One path to disambiguation would be to show hex digits A-F in
lower case. Sounds OK?
> >C1 Control characters are specified in ISO-6429 and used in the VT220
> >family of terminals  and the Wyse 370 , where they are represented
> >in the right half of the "display controls" font as shown in Table 4.3 (DEC
> >terminals use the full name, Wyse terminals use the 2X name). As with C0
> >controls, the "name" is displayed diagonally within the character cell.
> >Unicode presently includes no C1 control pictures.
> Looking through various EBCDIC code pages (e.g. IBM278, IBM880) and other
> unnumbered sets it appears that these control codes are all also available
> in EBCDIC, but of course at different positions (e.g. IND at 0x24). Some
> references to these sets are "IBM NLS RM Vol2 SE09-8002-01, March 1990" and
> "IBM 3270 Char Set Ref Ch 10, GA27-2837-9, April 1987".
Thanks for pointing this out -- I'll be sure to unify all duplicates in the
> In ISO 8859-1 these are listed as
> 80 PADDING CHARACTER (PAD)
> 81 HIGH OCTET PRESET (HOP)
> 99 SINGLE GRAPHIC CHARACTER INTRODUCER (SGCI)
I suppose that's a good enough source, though I wonder why they are not
named in ISO 6429!
> >Table 4.4 shows the names of control characters unique to EBCDIC (that
> >is, the ones it does not share with ASCII).
> There seems to be different names for the same EBCDIC control characters
> and some of these names are equivalent to the ASCII names. Just wondering
> what should be done to these control pictures ? Some examples below.
In the spirit of unification, I would venture that if two different control
characters have the same name, only one control picture is needed.
> > (1) The reverse question is essential in VT terminal emulation...
> Even ISO-Latin1 contains the reverse question mark at 0xBF, so it is no
> need to re-invent it.
But that one is upside down. The one I'm talking about is upright but
flipped on its vertical axis.
Clearly an important component of this proposal, before it reaches its final
stage, is a collection of pictures of the proposed characters. I'll do my
best to scan in the relevant pages from the many terminal manuals, for what
it's worth -- many of them are crude and unclear to begin with, some of them
are even hand-drawn. Others are wedded to dot matrices of specific
dimensions and, in fact, are shown as large tty graphics.
I wonder how one proceeds from such elusive sources to create a definitive
picture of each character, and then to translate this into the style of a
particular font. Oh well, not my problem :-)
> All in all a very interesting proposal. By using as much existing characters
> from current Unicode standard, i guess there would be a greater likelyhood
> of getting thing officially approved.
And of course, many characters in many of these sets are indeed well covered
by existing Unicode characters and so never appeared in the proposal in the
first place. I considered fully enumerating each character set and noting
which characters already did and did not have suitable Unicode equivalents,
but that would have made the proposal much too long.
Thanks to you and everyone else for the helpful and supportive comments. I
think the next step will be to run a new draft (updated according to comments
from this list) past the broad constituencies of some of the terminals it
treats, for which there are several well-suited newsgroups.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:42 EDT