RE: PETSCII mapping?

[Peter Constable via Unicode]

From: Unicode [mailto:unicode-boun...@unicode.org] On Behalf Of Rebecca T
Sent: Wednesday, April 5, 2017 2:26 PM

> As time goes on, “not in widespread use” will become a flimsier and flimsier
> argument against inclusion — why isn’t there a larger community of PETSCII
> enthusaists? Partially because the only way to share PETSCII is through 
> images!
> The consortium (passively or actively) prevents communication through 
> exclusion
> and then uses the lack of communication as a justification against inclusion —
> it’s a poor, tautological argument, and it won’t serve the consortium
> long-term.
>
> Simply put, we need new criteria for inclusion…

Your assertions are based on assumptions that simply aren’t valid. Unicode 
regularly encodes characters for things that are not in widespread use, and 
that fit the intended scope of the Standard. If someone can demonstrate that 
there are users who _would_ interchange texts that currently cannot be 
represented in Unicode for lack of appropriate characters, then that certainly 
can be considered. But the fact that some text element was represented in some 
legacy system does not alone comprise an adequate basis for encoding.

And as Asmus said elsewhere in this thread,
> Nothing gets decided by the UTC unless there's a proposal on the table.

Also, as Elias said,
> Wouldn't it make sense to get in touch with active Commodore 64 communities
> to find out how people deal with this today?

This is key: if there isn’t an on-going interest among some user community for 
interchanging the putative characters in Unicode, then that would weaken a case 
for encoding.


> we must weigh a character’s merits and usability on its own. (does
> it fill a gap in communication? Will it be used?)

That is already and has always been a basis on which characters get encoded in 
Unicode.


Peter

Re: PETSCII mapping?

[William_J_G Overington]

> At some point this should be taken off the main list since discussion will 
> get very detailed very quickly.
 
> I agree. How should we get all the interested parties together?

> Everybody interested, raise your hand

Yes please.

William

Re: PETSCII mapping?

[Philippe Verdy]

This 2x3 block graphic set was also part of Videotex/Teletext/Antiope
standards in Europe (used on PCs, dedicated terminals, and TV programs, and
still supported in more recent teletext technologies, even if many smart
TVs offer other interactive protocols based on web standards, or possibly
embedding an HTML/CSS/Javascript rendering engine, sometimes even with
Android SDK support for applications). It has even been implemented in some
TV networks in US.
Before graphic displays became widespread (when the EGA standard started
being added, then when non-monochromatic monitors appeared almost
immediately after it), almost all text terminals had such minimal support
for such "mosaic" graphics. Only the original IBM PC had a much more
limited set, using 1x2 blocks, while using box-drawing graphic subset in
their legacy codepages.
The original IBM logo was made of these 1x2 blocks

2017-04-07 3:19 GMT+02:00 Mark E. Shoulson :

> On 04/06/2017 08:07 AM, Rebecca T wrote:
>
>> Here’s a copy of the Teletext character set; it includes box-drawing
>> characters
>> for all combinations of a 2×3 grid of cells. 2⁶ = 64 characters, so we
>> might
>> need a new block.
>>
>> [1]: http://www.galax.xyz/TELETEXT/CHARSET.HTM
>>
>> My old TRS-80 also did "graphics" like this, with 64 2×3 cells. That was
> even how it did it when you were setting individual blocks.  The smallest
> "pixel" you could control in graphics was one of these ⅙ths of a character
> cell, and wouldn't you know it? As soon as you set one in a cell occupied
> by some other character, the other character would disappear.
>
> Not positive these count as plain text, but there's a decent argument for
> it.
>
> ~mark
>
>

Re: PETSCII mapping?

[Mark E. Shoulson]

On 04/06/2017 08:07 AM, Rebecca T wrote:
Here’s a copy of the Teletext character set; it includes box-drawing 
characters
for all combinations of a 2×3 grid of cells. 2⁶ = 64 characters, so we 
might

need a new block.

[1]: http://www.galax.xyz/TELETEXT/CHARSET.HTM

My old TRS-80 also did "graphics" like this, with 64 2×3 cells. That was 
even how it did it when you were setting individual blocks.  The 
smallest "pixel" you could control in graphics was one of these ⅙ths of 
a character cell, and wouldn't you know it? As soon as you set one in a 
cell occupied by some other character, the other character would disappear.


Not positive these count as plain text, but there's a decent argument 
for it.


~mark

Re: PETSCII mapping?

[Mark E. Shoulson]

On 04/05/2017 05:25 PM, Rebecca T wrote:


As time goes on, “not in widespread use” will become a flimsier and 
flimsier

argument against inclusion
Indeed.  This is the chicken-and-egg problem, and you are not the first 
to (rightly) point it out as a flimsy excuse.  Thanks for bringing it up 
again, though: people still seem to go back to it a lot.


~mark

Re: PETSCII mapping?

[Rebecca T]

Count me in!

I’m partial for one large unified proposal, FWIW.

On Thu, Apr 6, 2017 at 2:24 PM, Rebecca Bettencourt 
wrote:

> On Thu, Apr 6, 2017 at 10:43 AM, Doug Ewell  wrote:
>
>> Michael Everson wrote:
>>
>> > Everybody interested, raise your hand…
>>
>> I'm in. 
>
>
> I'm in as well of course.
>
>
>> Rebecca Bettencourt wrote:
>>
>> > The question is, do we want to add these missing graphics characters
>> > incrementally, platform by platform, or put together a larger proposal
>> > for, say, one big Block Elements Extended block?
>>
>> I would guess the latter. There's no tremendous rush; there should be
>> time to do a proper analysis of target platforms, evaluate which
>> proposed characters should be unified with existing or other proposed
>> characters, and so forth.
>>
>> Of course there's no guarantee this will be the last request ever for
>> 8-bit computer compatibility characters, but there doesn't seem much
>> point in intentionally dragging the process out, platform by platform.
>>
>
> You make a good point. I'm in either way. :)
>
>

Re: PETSCII mapping?

[Rebecca Bettencourt]

On Thu, Apr 6, 2017 at 10:43 AM, Doug Ewell  wrote:

> Michael Everson wrote:
>
> > Everybody interested, raise your hand…
>
> I'm in. 


I'm in as well of course.


> Rebecca Bettencourt wrote:
>
> > The question is, do we want to add these missing graphics characters
> > incrementally, platform by platform, or put together a larger proposal
> > for, say, one big Block Elements Extended block?
>
> I would guess the latter. There's no tremendous rush; there should be
> time to do a proper analysis of target platforms, evaluate which
> proposed characters should be unified with existing or other proposed
> characters, and so forth.
>
> Of course there's no guarantee this will be the last request ever for
> 8-bit computer compatibility characters, but there doesn't seem much
> point in intentionally dragging the process out, platform by platform.
>

You make a good point. I'm in either way. :)

Re: PETSCII mapping?

[Doug Ewell]

Michael Everson wrote:

> Everybody interested, raise your hand…

I'm in. 

Rebecca Bettencourt wrote:

> The question is, do we want to add these missing graphics characters
> incrementally, platform by platform, or put together a larger proposal
> for, say, one big Block Elements Extended block?

I would guess the latter. There's no tremendous rush; there should be
time to do a proper analysis of target platforms, evaluate which
proposed characters should be unified with existing or other proposed
characters, and so forth.

Of course there's no guarantee this will be the last request ever for
8-bit computer compatibility characters, but there doesn't seem much
point in intentionally dragging the process out, platform by platform.
 
--
Doug Ewell | Thornton, CO, US | ewellic.org

Re: PETSCII mapping?

[Rebecca Bettencourt]

On Thu, Apr 6, 2017 at 5:25 AM, Michael Everson 
wrote:

> At some point this should be taken off the main list since discussion will
> get very detailed very quickly.
>

I agree. How should we get all the interested parties together?

Re: PETSCII mapping?

[Michael Everson]

On 6 Apr 2017, at 17:36, Rebecca Bettencourt  wrote:
> 
> At some point this should be taken off the main list since discussion will 
> get very detailed very quickly.
> 
> I agree. How should we get all the interested parties together?

Everybody interested, raise your hand…

Michael Everson

Re: PETSCII mapping?

[Rebecca Bettencourt]

The Teletext set of 2x3 block characters also covers a significant chunk of
the TRS-80 and CoCo character sets:

http://www.kreativekorp.com/software/fonts/trs80.shtml

I have been thinking of proposing those characters for a while, actually,
and that would have been my next proposal after PETSCII. :) The question
is, do we want to add these missing graphics characters incrementally,
platform by platform, or put together a larger proposal for, say, one big
Block Elements Extended block? My first thought is that an incremental
approach would make it easier to get characters into the standard, but what
do I know.


-- Rebecca Bettencourt

On Thu, Apr 6, 2017 at 5:07 AM, Rebecca T <637...@gmail.com> wrote:

> Here’s a copy of the Teletext character set; it includes box-drawing
> characters
> for all combinations of a 2×3 grid of cells. 2⁶ = 64 characters, so we
> might
> need a new block.
>
> [1]: http://www.galax.xyz/TELETEXT/CHARSET.HTM
>
>

Re: PETSCII mapping?

[Michael Everson]

On 6 Apr 2017, at 04:32, Rebecca Bettencourt  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.

I’ll help with that; we should harmonize with other characters in the standard.

At some point this should be taken off the main list since discussion will get 
very detailed very quickly.

Michael Everson

Re: PETSCII mapping?

[Rebecca T]

Here’s a copy of the Teletext character set; it includes box-drawing
characters
for all combinations of a 2×3 grid of cells. 2⁶ = 64 characters, so we might
need a new block.

[1]: http://www.galax.xyz/TELETEXT/CHARSET.HTM

Re: PETSCII mapping?

[Alastair Houghton]

On 6 Apr 2017, at 08:25, Elias Mårtenson  wrote:
> 
> 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.

Since most of the issue is graphics characters, and since that same problem 
affects PETSCII, ATASCII, the ZX80 set, and Teletext/Videotex/Viewdata (aka BBC 
Micro mode 7), would it be better to come up with a complete set of extra 
graphic characters that need to be encoded, and make it a proposal to “complete 
the set” of box drawing and graphics characters?  IMO the Teletext set is 
*much* more important than PETSCII or ATASCII; while there will very likely be 
text encoded in the latter two, there are significant volumes encoded in the 
Teletext set.  Quite a bit of data has already been lost (there are mirrors of 
old Prestel/Viewdata BBS systems, some of which have sadly lost all the 
graphics because of the lack of equivalent Unicode characters), and a lot of 
the rest is either encoded in a non-standard encoding or held as screen shots.

Also, it would be worth looking to see if there are any discussions from past 
attempts to get any of these things into the Unicode standard; I can’t imagine 
this is the first time anyone’s asked for more graphics characters.

Kind regards,

Alastair.

--
http://alastairs-place.net

Re: PETSCII mapping?

[Elias Mårtenson]

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.

Regards,
Elias

On 6 April 2017 at 15:19, Rebecca Bettencourt  wrote:

> I've completed my unified chart:
>
> https://docs.google.com/document/d/10RJKTNFZFEww0yRVPzPdeNnyC_
> PUkAMhn7OVB7YdTFc/edit?usp=sharing
>
> 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
> characters:
>
> 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 
> wrote:
>
>> On 6 April 2017 at 11:32, Rebecca Bettencourt 
>> 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
>> themselves.
>>
>> 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.
>>
>> Regards,
>> Elias
>>
>
>

Re: PETSCII mapping?

[Rebecca Bettencourt]

I've completed my unified chart:

https://docs.google.com/document/d/10RJKTNFZFEww0yRVPzPdeNnyC_PUkAMhn7OVB7YdTFc/edit?usp=sharing

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
characters:

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  wrote:

> On 6 April 2017 at 11:32, Rebecca Bettencourt  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
> themselves.
>
> 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.
>
> Regards,
> Elias
>

Re: PETSCII mapping?

[Elias Mårtenson]

On 6 April 2017 at 11:32, Rebecca Bettencourt  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
themselves.

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.

Regards,
Elias

Re: PETSCII mapping?

[Rebecca T]

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

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
characters
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
the
block elements seem to represent shapes and shades; this makes $7c, $7f,
$a7,
$a8, $a9, $b6, $b7, and $b8 block elements and the rest box-drawing
characters.

[1]: https://en.m.wikipedia.org/wiki/PETSCII
[2]: https://github.com/years/Unicode-PETSCII/blob/master/new.txt
[3]:
https://github.com/years/Unicode-PETSCII/blob/master/graphic-table.txt

[image: Inline image 1]

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

> 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
>>
>
>

Re: PETSCII mapping?

[Charlotte Buff]

Rebecca Bettencourt wrote:
> I'm all willing to help put together a proposal for encoding missing
block
> element characters, but I would need other people to a) gather evidence
of
> use in plain text and b) write up the proposal in Unicode's formal
language
> since I've never proposed characters to Unicode before.

I'm in the process of preparing a proposal for several old character sets,
one of them PETSCII. At the moment I am still mostly concerned with
analyzing the sets and determining which characters can sensibly be unified
with existing ones and how to best structure the included repertoire.

Currently I am quite busy with university stuff so things progress rather
slowly, though.

Re: PETSCII mapping?

[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
>

Re: PETSCII mapping?

[Elias Mårtenson]

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.
>

The Wikipedia page on PETSCII has a character map where the missing
characters are highlighted. Based on my count, there are 31 missing
symbols. Those should be reasonably simple to document and highlight.

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.

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?

Regards,
Elias

Re: PETSCII mapping?

[James Kass]

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 all willing to help put together a proposal for encoding missing
> block element characters, but I would need other people to a) gather
> evidence of use in plain text and b) write up the proposal in Unicode's
> formal language since I've never proposed characters to Unicode before.

Even the most prolific of our proposers had to start someplace...

> As time goes on, “not in widespread use” will become a flimsier
> and flimsier argument against inclusion...

Agreed.  As arguments go, that one was never very robust.

Best regards,

James Kass

Re: PETSCII mapping?

[Asmus Freytag]

On 4/5/2017 4:49 PM, James Kass wrote:

Asmus Freytag wrote,


There's no need for inflammatory rhetoric.

Indeed not.  How fortunate we are that nobody has posted any.


Indeed. Grabbed the wrong item from my word bin today.

A./


Best regards,

James Kass

Re: PETSCII mapping?

[Michael Everson]

I agree with Rebecca. It’s going to be a handful of characters, used by the 
handful of people who use legacy character sets. Those people exist (I run Mac 
OS 9 regularly because it’s necessary for some of my work) and since some of 
these legacy characters are encoded, it makes sense to make sure all of them 
are. It’s no harm to the standard to support them. 

Asmus is right. It needs a proposal. 

> On 5 Apr 2017, at 23:14, Asmus Freytag (c)  wrote:
> 
> On 4/5/2017 2:25 PM, Rebecca T wrote:
>> > If there's a credible need to convert files between Unicode-based systems 
>> > and
>> > those using PETSCII
>> 
>> There is! It’s called “sharing textual information” and it’s how our society
>> functions. Can we afford to blithely abandon data from the best selling
>> computer in history [1] because nobody cared to standardize its?
> 
> There's no need for inflammatory rhetoric.
> 
> If you believe there is a credible need, then it should be easy to document 
> that as part of a proposal.
> 
> Nothing gets decided by the UTC unless there's a proposal on the table.

Re: PETSCII mapping?

[James Kass]

Asmus Freytag wrote,

> There's no need for inflammatory rhetoric.

Indeed not.  How fortunate we are that nobody has posted any.

Best regards,

James Kass

Re: PETSCII mapping?

[Asmus Freytag (c)]

On 4/5/2017 2:25 PM, Rebecca T wrote:
> If there's a credible need to convert files between Unicode-based 
systems and

> those using PETSCII

There is! It’s called “sharing textual information” and it’s how our 
society

functions. Can we afford to blithely abandon data from the best selling
computer in history [1] because nobody cared to standardize its?


There's no need for inflammatory rhetoric.

If you believe there is a credible need, then it should be easy to 
document that as part of a proposal.


Nothing gets decided by the UTC unless there's a proposal on the table.

A./


> A similar scenario might exist if C64 emulators run on Unicode-based 
systesm

> were a widespread phenomenon

They do! Even last month, there was a PETSCII directory-art contest. [2]

A bit off-topic, but:

As time goes on, “not in widespread use” will become a flimsier and 
flimsier

argument against inclusion — why isn’t there a larger community of PETSCII
enthusaists? Partially because the only way to share PETSCII is 
through images!
The consortium (passively or actively) prevents communication through 
exclusion
and then uses the lack of communication as a justification against 
inclusion —

it’s a poor, tautological argument, and it won’t serve the consortium
long-term.

Simply put, we need new criteria for inclusion — as the vast majority 
of the
world’s systems (from written communication in text messages to the 
manuscripts

of all new books) are already Unicode-based, we can no longer rely on a
character’s existing presence outside of Unicode as a signal to warrent
inclusion; we must weigh a character’s merits and usability on its 
own. (does

it fill a gap in communication? Will it be used?)

[1]: 
http://www.cnn.com/2011/TECH/gaming.gadgets/05/09/commodore.64.reborn/

[2]: http://csdb.dk/event/?id=2558

Re: PETSCII mapping?

[Rebecca T]

> If there's a credible need to convert files between Unicode-based systems
and
> those using PETSCII

There is! It’s called “sharing textual information” and it’s how our society
functions. Can we afford to blithely abandon data from the best selling
computer in history [1] because nobody cared to standardize its?

> A similar scenario might exist if C64 emulators run on Unicode-based
systesm
> were a widespread phenomenon

They do! Even last month, there was a PETSCII directory-art contest. [2]

A bit off-topic, but:

As time goes on, “not in widespread use” will become a flimsier and flimsier
argument against inclusion — why isn’t there a larger community of PETSCII
enthusaists? Partially because the only way to share PETSCII is through
images!
The consortium (passively or actively) prevents communication through
exclusion
and then uses the lack of communication as a justification against
inclusion —
it’s a poor, tautological argument, and it won’t serve the consortium
long-term.

Simply put, we need new criteria for inclusion — as the vast majority of the
world’s systems (from written communication in text messages to the
manuscripts
of all new books) are already Unicode-based, we can no longer rely on a
character’s existing presence outside of Unicode as a signal to warrent
inclusion; we must weigh a character’s merits and usability on its own.
(does
it fill a gap in communication? Will it be used?)

[1]: http://www.cnn.com/2011/TECH/gaming.gadgets/05/09/commodore.64.reborn/
[2]: http://csdb.dk/event/?id=2558

Re: PETSCII mapping?

[Rebecca Bettencourt]

You can find charts of complete PETSCII character sets here:

http://www.kreativekorp.com/software/fonts/c64.shtml

The missing characters are a handful of block elements: upper fractional
blocks (Unicode only has lower), halves of MEDIUM SHADE, checkerboards and
diagonals.

I can put together a unified chart, with mappings to Unicode where they
exist. In fact I think I'll do that. :)

I'm all willing to help put together a proposal for encoding missing block
element characters, but I would need other people to a) gather evidence of
use in plain text and b) write up the proposal in Unicode's formal language
since I've never proposed characters to Unicode before.

(Additionally, I wonder if we could find evidence of the Apple II's or
TRS-80's characters in use in plain text as well. Not necessarily saying
those should be encoded as well, just that we should investigate.)



-- Rebecca Bettencourt

On Wed, Apr 5, 2017 at 12:47 PM, Murray Sargent <
murr...@exchange.microsoft.com> wrote:

> What PETSCII characters aren’t already in Unicode? A couple geometric
> symbols? Looks mostly like a simple codepage translation.
>
>
>
> Murray
>
>
>
> *From:* Unicode [mailto:unicode-boun...@unicode.org] * On Behalf Of *Rebecca
> Bettencourt
> *Sent:* Wednesday, April 5, 2017 9:42 AM
> *To:* Asmus Freytag <asm...@ix.netcom.com>
> *Cc:* unicode <unicode@unicode.org>
> *Subject:* Re: PETSCII mapping?
>
>
>
> On Wed, Apr 5, 2017 at 3:18 AM, Asmus Freytag <asm...@ix.netcom.com>
> wrote:
>
> Unicode is not an archive of anything ever used on computers.
>
>
>
> Why not? Isn't one of Unicode's goals to support the conversion of
> documents using legacy character sets into Unicode? I do not understand
> why, say, the entire IBM PC character set is eligible for encoding, but not
> the entire Commodore 64 character set.
>
>
>
>
>
> Were there word processors on the Commodore 64 that allowed the input of
> PETSCII characters? Could documents written using that software demonstrate
> a need to encode those characters? What about instruction manuals, magazine
> articles, and program listings that used PETSCII characters in running
> text? Surely there must be more than enough examples for a computer as
> popular as the Commodore 64.
>

Re: PETSCII mapping?

[Rebecca Bettencourt]

On Wed, Apr 5, 2017 at 3:18 AM, Asmus Freytag  wrote:

> Unicode is not an archive of anything ever used on computers.
>

Why not? Isn't one of Unicode's goals to support the conversion of
documents using legacy character sets into Unicode? I do not understand
why, say, the entire IBM PC character set is eligible for encoding, but not
the entire Commodore 64 character set.


Were there word processors on the Commodore 64 that allowed the input of
PETSCII characters? Could documents written using that software demonstrate
a need to encode those characters? What about instruction manuals, magazine
articles, and program listings that used PETSCII characters in running
text? Surely there must be more than enough examples for a computer as
popular as the Commodore 64.

Re: PETSCII mapping?

[Asmus Freytag]

  
  
On 4/5/2017 1:18 AM, Elias Mårtenson
  wrote:


  I have been searching, trying to find some
information as to why there is a large set of symbols in PETSCII
which cannot be mapped to Unicode.


PETSCII is the character set used by the Commodore 64,
  which was an incredibly popular computer in the 80's, and
  still remains in use to this day. More information on the
  character set can be found on Wikipedia: https://en.wikipedia.org/wiki/PETSCII


Searching for PETSCII in the archives for this mailing list
  only reveals two messages, none of which addresses my
  question.


Given that this is a web-documented character set, used by
  a very popular system, there must be some reason why these
  symbols are missing from Unicode.


Could anyone provide some information on this?


Regards,
Elias
  

Dear Elias,
  
Unicode is not an archive of anything ever
used on computers.
If there's a credible need to convert files
between Unicode-based systems and those using PETSCII with full
round-trip convertibility, then that _might_ constitute a case
for encoding. A similar scenario might exist if C64 emulators
run on Unicode-based systesm were a widespread phenomenon, in
which case having a standardized Unicode representation for the
missing code points might be in scope.
  
I cannot speculate whether the UTC would
find a proposal to that effect compelling, it would depend on
the user community affected and the specific evidence adduced in
support.
A./