Subject: port-i386/5219: pcvt font maps
To: None <>
From: Chris Jones <>
List: netbsd-bugs
Date: 03/27/1998 12:18:22
>Number:         5219
>Category:       port-i386
>Synopsis:       pcvt font maps
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 27 11:20:01 1998
>Originator:     Chris Jones
Chris Jones                            
           Mad scientist in training...
"Is this going to be a stand-up programming session, sir, or another bug hunt?"
>Release:        tested with 1.3 and -current as of a few days ago
System: NetBSD 1.3 NetBSD 1.3 (CAESAR) #0: Tue Feb 10 11:29:43 MST 1998 i386

Depending on how you look at it, this could be a change-request
instead of a sw-bug.

Anyway, as I posted on current-users recently, the font mapping of
pcvt is non-intuitive.  Specifically, pcvt defaults to the
csd_supplemental display mapping for characters above 0xa0.  This
means that, if I create a font which uses those characters, and I load
it using fontload, I can't display the majority of the characters
above 0xa0 in the new font.

I believe this situation is the way it is in order to facilitate
display of characters which are not ascii, but which are typically
accessible on a PC, e.g., from DOS.

However, I still think it's a bug that character sets don't display
properly.  Perhaps there's some mysterious VT220 escape code which
will fix the display mapping to do the right thing, but I haven't been
able to find it.

I demonstrated the problem to myself by loading the koi8-r-8x16 font
(from freebsd) into slot 0.  Then, I catted a file which contained
characters from 0x20 to 0xff.  I compared this against the character
set as seen in fed.

The quick hack is to change the initialization and reset functions in
pcvt_out.c and pcvt_vtf.c, to assign cse_downloadable -> GR.  But this
hack may break other things.