Distinct line drawing characters aliased to each other

[srowe]

The horizontal line drawing characters PETSCII codes $60 and $63 both map on to BOX DRAWINGS LIGHT HORIZONTAL (0x2500). Similarly the vertical line characters $62 and $7D map on to BOX DRAWINGS LIGHT VERTICAL (0x2502). While these characters are indistinguishable on the C-64 on earlier systems like the VIC-20 they are different.

[srowe]

I propose adding two new CUS values 0xF13B and 0xF13C for $63 and $62 respectively. I also find the names of the current line drawing characters non-intuitive and suggest the following new names

0xF123 BOX DRAWINGS LIGHT HORIZONTAL THREE EIGHTHS UP
0xF122 BOX DRAWINGS LIGHT HORIZONTAL TWO EIGHTHS UP
0xF13B BOX DRAWINGS LIGHT HORIZONTAL ONE EIGHTH UP
0xF124 BOX DRAWINGS LIGHT HORIZONTAL ONE EIGHTH DOWN
0xF125 BOX DRAWINGS LIGHT HORIZONTAL TWO EIGHTHS DOWN

0xF127 BOX DRAWINGS LIGHT VERTICAL THREE EIGHTHS LEFT
0xF126 BOX DRAWINGS LIGHT VERTICAL TWO EIGHTHS LEFT
0xF13C BOX DRAWINGS LIGHT VERTICAL ONE EIGHTH LEFT
0xF128 BOX DRAWINGS LIGHT VERTICAL ONE EIGHTH RIGHT
0xF129 BOX DRAWINGS LIGHT VERTICAL TWO EIGHTHS RIGHT

[irmen]

Hm....
The problem with this solution is that we used to be able to "type" the real unicode code points U+2502 (BOX DRAWINGS LIGHT VERTICAL) and U+2500 (BOX DRAWINGS LIGHT HORIZONTAL)
Those CUS characters that replace them are not official unicode code points. So we can no longer "type" them but have to specify the code point using explicit hexadecimal notation.
Am I correct?

edit: oh wait, you only replaced one of the double ones

[srowe]

Let me describe the problem better. As things stand if I encode U+2500 it is translated to 0x63.

>>> "─┼─".encode('petscii-c64en-uc')
b'\xc3\xdb\xc3'

This is the wrong PETSCII character, it should be 0x60 for it to line up with the middle character.

[irmen]

I see.