lokedhs at gmail.com
Thu Apr 6 02:25:42 CDT 2017
Wouldn't it make sense to get in touch with active Commodore 64 communities
to find out how people deal with this today? I'm sure there are use cases
that none of us have thought about.
On 6 April 2017 at 15:19, Rebecca Bettencourt <beckiergb at gmail.com> wrote:
> I've completed my unified chart:
> The result is either 20 or 24 characters to be encoded, depending on
> whether or not 4 of them should be unified with existing characters.
> 14 have fairly obvious names following a pattern established by existing
> Left and Lower One Eighth Block
> Left and Upper One Eighth Block
> Right and Upper One Eighth Block
> Right and Lower One Eighth Block
> Left Half Medium Shade
> Lower Half Medium Shade
> Right One Quarter Block
> Right Three Eighths Block
> Upper One Quarter Block
> Upper Three Eighths Block
> Four-by-Four Checker Board
> Reverse Four-by-Four Checker Board
> Upper Left to Lower Right Fill
> Upper Right to Lower Left Fill
> 10 need some more thinking (they are all horizontal and vertical lines at
> various positions within the character cell; naming depends on if we want
> to unify some of them with the HORIZONTAL SCAN LINEs in the Miscellaneous
> Technical block).
> -- Rebecca Bettencourt
> On Wed, Apr 5, 2017 at 10:24 PM, Elias Mårtenson <lokedhs at gmail.com>
>> On 6 April 2017 at 11:32, Rebecca Bettencourt <beckiergb at gmail.com>
>> 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.
>> Are there any existing C64 fonts with vectorised glyphs?
>>> 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.
>> For colour change, I definitely agree. The reverse video case is a bit
>> different since the resulting characters are very much separate symbols by
>> I think I need to take a closer look at existing C64 textual content to
>> see how it was actually being used in real life. I do recall that reverse
>> video was heavily used in file names, so there is definitely an argument
>> for introducing “COMBINING PETSCII REVERSE VIDEO”. It would be unfortunate
>> if higher-level markup is required to accurately represent the name of a
>> file stored on a C64 floppy disc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Unicode