Re: UCS Terminal Emulation Draft

From: Frank da Cruz (fdc@watsun.cc.columbia.edu)
Date: Mon Nov 23 1998 - 13:32:09 EST


Hi Markus.

> A few questions/suggestions on
>
> ftp://kermit.columbia.edu/kermit/ucsterminal/ucsterminal.txt
>
> which I am implementing at the moment.
>
> > * E0A6 Extensible UR or LL brace section IBM SS240000
> > * E0A7 Extensible LR or UL brace section IBM SS250000
>
> I don't understand why there are not four of these. How can UR and LL be
> unified?
>
Because they look exactly the same :-) (IBM being clever...)

> > * E0AE Right ceiling corner DEC Tech 03/05
> > * E0AF Right floor corner DEC Tech 03/06
>
> What are these good for? Big floor-ceiling operators can already be
> constructed using the bracket segments. And why are there only right
> versions of these?
>
They're not centered vertically or horizontally. Do you have a DEC terminal
manual? They look about like this:

+------------------+ +------------------+
| | | |
| -------------+ | | |
| | | | | |
| | | | | |
| | | -------------+ |
| | | |
+------------------+ +------------------+
       03/05 03/06

> > E0EF Box drawing double dash H DGL 03/12 (5)
> > (5) Similar to U+2504 but double rather than triple.
>
> What is the difference to U+254c (BOX DRAWINGS LIGHT DOUBLE DASH
> HORIZONTAL)? Michael's glyph in
>
> ftp://kermit.columbia.edu/kermit/ucsterminal/terminal-emulation.pdf
>
> doesn't seem to fit the description here. This character is still a bit
> confusing.
>
I might have missed the glyph at U+254C -- I think this one might be a
candidate for unification. The DG character, however, has wider spacing
between the dashes (for what it's worth).

> > E0D8 H line - Scan 5 DSG 07/01, Wyse ANSI 02/02 (2)
>
> I think, this one should be unified with U+2500.
>
I think I commented on this in the proposal. Yes, they should be unified,
but only if it can be guaranteed that the unified character works in both
contexts (PC-style box drawing and VT-style box drawing). I don't see any
reason why it shouldn't, but I'm not a font designer.

> The E0D6-E0DA
> characters should also be renamed, as a scan line count is ambiguous and
> resolution dependent. Something like
>
> E0D6 BOX DRAWINGS LIGHT HORIZONTAL UPPER ONE SIXTH
> E0D7 BOX DRAWINGS LIGHT HORIZONTAL UPPER TWO SIXTH
> E0D9 BOX DRAWINGS LIGHT HORIZONTAL LOWER TWO SIXTH
> E0DA BOX DRAWINGS LIGHT HORIZONTAL UPPER ONE SIXTH
>
> and together with 2500 we would then have all the required lines.
>
I'm certainly not averse to this.

> An implementation of these characters is now available in
>
> http://www.cl.cam.ac.uk/~mgk25/download/ucs-fonts.tar.gz
>
> in the file 6x13-future.bdf, in which I collect proposed implementations
> of post-Unicode 2.1 characters for my 6x13 font.
>
You've encoded them in the private-use area, right? Hopefully final resting
places will be designated for them in the U+2xxx region, and the repertoire
and/or sequencing might be altered. For that matter the entire proposal might
be rejected. In the latter case, of course, we can just keep these characters
where they are.

> It would be nice if you
> could have a look at these characters. [BTW: The 6x13.bdf file is now
> complete and will be added to various Linux distributions in a few days.
> This is your last chance to send me bug reports and suggestions for this
> free Unicode xterm font before wide distribution.]
>
I don't have a way to look at BDF files at the moment so can't comment --
let's take this offline...

Thanks!

- Frank



This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:43 EDT