Re: Unicode fundamental character identity
James Kass via Unicode <[email protected]>
| Newsgroups | gmane.text.unicode.general |
|---|---|
| Message-ID | <[email protected]> |
On 2025-01-31 11:15 PM, [email protected] via Unicode wrote: > > Dnia 31 stycznia 2025 23:45 James Kass <[email protected]> > napisał(a): > > (Hi Piotr, I sent this to the list about 45 minutes ago but it has not > come through yet so I'm sending it along to you directly. Hope this > helps. -James) > > -------- Forwarded Message -------- > Subject: Re: Odp: RE: Re: Re: Unicode fundamental character identity > Date: Fri, 31 Jan 2025 22:01:54 +0000 > From: James Kass <[email protected]> > To: [email protected] > > > > > > On 2025-01-31 9:28 PM, [email protected] via Unicode wrote: > > The proposal L2/25-037 already shows a difference in plain > text of the > HP 264x characters, where 0x12 (2) connects below vertical or > perpendicular diagonal, whereas 0x18 (8) connects below > diagonal of > same direction. Those are different types of connections which > is a > plain text distinction of box drawings. > > A "smart" font dedicated to these characters would provide appropriate > glyphs based on context. This would result in a plain-text display > identical to the original display. > > That doesn't make sense because on a fundamental level, in a legacy > computing semigraphical environment, each character tile is drawn > independently, and only affects the area of the screen dedicated to > that character. Having a context dependent system would overcomplicate > the renderer beyond the scope of the original system. Furthermore, on > the HP 264x system, the two characters can exist in isolation (as > shown in obGQ4Ie.png (1440×720) (imgur.com) > <https://i.imgur.com/obGQ4Ie.png>), and the user can in fact type the > two characters differently, with the 2 and 8 keys as shown in page 31 > of 204 in > 02645-90005_2641A_2645A_2645S_N_Display_Station_Reference_Manual_Nov1978.pdf > (bitsavers.org) > <http://www.bitsavers.org/pdf/hp/terminal/264x/2645A/02645-90005_2641A_2645A_2645S_N_Display_Station_Reference_Manual_Nov1978.pdf>. > Sorry for the confusion. I'm referring to a Unicode "smart" font working on a modern system displaying Unicode plain-text. This is all automatic and handled by the rendering system. If a dedicated font is used to display the text, contextual glyph substitution would make the display indistinguishable from the original display on the legacy system. Also, on a modern system any "dumb" font supporting the characters would still produce a *legible* display, even though it might not be as pretty. And legibility in plain-text is one of the factors driving encoding decisions. (This might be why font selection was mentioned as a solution in the document referenced earlier.) > Data loss in round-tripping is implicitly evident from the > information > provided in the proposal: if an HP 264x Large Character set mode > document has the characters 0x12 0x18, it converts to Unicode as > U+1CE2B U+1CE2B, which converted back to HP 264x Large > Character set > mode is 0x12 0x12, which loses the distinction between the two > characters and will appear slightly differently than the original > document on HP 264x platform. > > Yes, this is implicit in the proposal. Any future proposal should > make > it explicit while referring to the earlier proposal for background. > Please keep in mind that the committee members must wade through many > different proposals covering all aspects of character encoding. > Keep it > short, straightforward, and simple as possible to ease their burden. > > The character has already been proposed. What would any future > proposal have to do with that? > If my understanding is correct, the character has already been proposed and rejected. It's not uncommon for a subsequent proposal to be submitted which addresses concerns raised during the rejection of an earlier proposal. (If my understanding is not correct, someone will probably set me straight.)