Re: PETSCII mapping?

From: Rebecca T <>
Date: Thu, 6 Apr 2017 01:10:02 -0400

The Wikipedia page for PETSCII [1] only marks 20 characters as not having
Unicode equivalents; 2px (light) and 3px (heavy) horizontal and vertical
at various non-center positions, diagonal shading characters, and corner

I’ve done some processing to the table on [1] to filter out the missing
characters — their exact codepoints and descriptions can be found in [2].

These characters are highlighted in red in the attached image (green
are also missing but are duplicates of other characters in the chart), and
marked by U+FFFD � in the compact table [3].

The box-drawing characters seem to semantically represent lines (boxes) and
block elements seem to represent shapes and shades; this makes $7c, $7f,
$a8, $a9, $b6, $b7, and $b8 block elements and the rest box-drawing


[image: Inline image 1]

On Wed, Apr 5, 2017 at 11:32 PM, Rebecca Bettencourt <>

> On 6 April 2017 at 09:44, James Kass <> wrote:
>> Rebecca Bettencourt wrote,
>> > I can put together a unified chart, with mappings to Unicode where
>> > they exist. In fact I think I'll do that. :)
>> I hope you do. That would be a good starting point.
> I'm working on it!
> On Wed, Apr 5, 2017 at 7:40 PM, Elias Mårtenson <> wrote:
>> Do we also have to create an example font that includes these symbols?
>> That seems to be what Michael Everson did for his chess notation proposal
>> that I read recently.
> We do have to provide Unicode with fonts, I believe. We can use an
> existing C64 font, such as Pet Me. Or, we can create a new font with
> vectorized versions of the characters.
>> Then there is the issue of what to do with the text colour and style
>> selectors. PETSCII has characters that indicate a colour change as well as
>> reverse video. At least the reverse video one is important, as it's being
>> used to construct new characters. For example, PETSCII only has a single
>> character "half block" (top part filled). The way you represent a half
>> block with the bottom part filled is to use the reverse video together with
>> the former.
>> It would probably make more sense to represent the reversed symbols as
>> separate code points?
> I would actually leave the color-change and reverse-video characters to a
> higher-level protocol.
>> Regards,
>> Elias

Received on Thu Apr 06 2017 - 00:11:45 CDT

This archive was generated by hypermail 2.2.0 : Thu Apr 06 2017 - 00:11:50 CDT