beckiergb at gmail.com
Thu Apr 6 02:19:50 CDT 2017
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
-- Rebecca Bettencourt
On Wed, Apr 5, 2017 at 10:24 PM, Elias Mårtenson <lokedhs at gmail.com> wrote:
> On 6 April 2017 at 11:32, Rebecca Bettencourt <beckiergb at gmail.com> wrote:
> 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