What to do if a legacy compatibility character is defective?

[Doug Ewell]

piotrunio-2004 at wp.pl wrote:

> The response to this proposal in L2/25-010 is fundamentally logically
> incorrect and does not provide any feedback whatsoever.

Here is the Script Encoding Working Group’s response to Piotr’s proposal, in its entirety:

“We received a proposal requesting a disunification of some of the legacy computing box drawing characters. The proposal seeks encoding a character that is one pixel different from U+1CE2B LARGE TYPE PIECE DIAGONAL UPPER RIGHT, and encoding 26 characters of box drawing lines for PETSCII and Apple II whose glyphs differ in thickness from the characters already encoded in the Symbols For Legacy Computing and Box Drawing blocks.

“We deem the differences demonstrated in the proposal to not constitute differences in plain text. No evidence of a document that would make a distinction between the corresponding characters in the different code pages was provided.

“The request appears to come from a misunderstanding of the standard. The document is making glyph distinctions, while the Unicode standard is based on character identities. It is not a goal of the standard to harmonize PETSCII and Apple II code pages. The issues raised in the proposals can be solved by using appropriate fonts and as such no action is recommended to be taken.”

If there is no “feedback,” it is because SEW essentially rejected the proposal on its premise.

> In that response, terms like 'differences in plain text', 'glyph
> distinctions', 'character identities' or 'appropriate fonts' are
> thrown around as buzzwords, completely defying all logic.

Uh, OK.

SEW is the body responsible for evaluating all non-Han encoding proposals. They probably know a thing or two about plain text and glyph distinctions and such.

My take is that Piotr did indeed receive a “proper explanation,” just not the one he wanted.

--
Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org