<div id="gwp9749a134"><div id="gwp9749a134h"><div class="gwp9749a134b" data-message-body="true"><div><br></div><div class="gwp9749a134_nh_extra"><p>Dnia 31 stycznia 2025 23:45 James Kass <jameskass@code2001.com> napisał(a):<br></p><blockquote class="gwp9749a134_nh_quote" style="border-left: 2px solid #999; padding-left: 8px; margin: 0;"><div id="gwp9749a134_gwp26c44001"><div>(Hi Piotr, I sent this to the list about 45 minutes ago but it has not<br></div><div>come through yet so I'm sending it along to you directly.  Hope this<br></div><div>helps.  -James)<br></div><div><br></div><div>-------- Forwarded Message --------<br></div><div>Subject:      Re: Odp: RE: Re: Re: Unicode fundamental character identity<br></div><div>Date:       Fri, 31 Jan 2025 22:01:54 +0000<br></div><div>From:   James Kass <jameskass@code2001.com><br></div><div>To:   unicode@corp.unicode.org<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>On 2025-01-31 9:28 PM, piotrunio-2004@wp.pl via Unicode wrote:<br></div><blockquote><div>The proposal L2/25-037 already shows a difference in plain text of the<br></div><div>HP 264x characters, where 0x12 (2) connects below vertical or<br></div><div>perpendicular diagonal, whereas 0x18 (8) connects below diagonal of<br></div><div>same direction. Those are different types of connections which is a<br></div><div>plain text distinction of box drawings.<br></div><div><br></div></blockquote><div>A "smart" font dedicated to these characters would provide appropriate<br></div><div>glyphs based on context.  This would result in a plain-text display<br></div><div>identical to the original display.<br></div></div></blockquote></div><div>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 <a href="https://i.imgur.com/obGQ4Ie.png">obGQ4Ie.png (1440×720) (imgur.com)</a>), 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 <a href="http://www.bitsavers.org/pdf/hp/terminal/264x/2645A/02645-90005_2641A_2645A_2645S_N_Display_Station_Reference_Manual_Nov1978.pdf">02645-90005_2641A_2645A_2645S_N_Display_Station_Reference_Manual_Nov1978.pdf (bitsavers.org)</a>.<br></div><div><br></div><div class="gwp9749a134_nh_extra"><blockquote class="gwp9749a134_nh_quote" style="border-left: 2px solid #999; padding-left: 8px; margin: 0;"><div id="gwp9749a134_gwp26c44001"><blockquote><div>Data loss in round-tripping is implicitly evident from the information<br></div><div>provided in the proposal: if an HP 264x Large Character set mode<br></div><div>document has the characters 0x12 0x18, it converts to Unicode as<br></div><div>U+1CE2B U+1CE2B, which converted back to HP 264x Large Character set<br></div><div>mode is 0x12 0x12, which loses the distinction between the two<br></div><div>characters and will appear slightly differently than the original<br></div><div>document on HP 264x platform.<br></div></blockquote><div>Yes, this is implicit in the proposal.  Any future proposal should make<br></div><div>it explicit while referring to the earlier proposal for background. <br></div><div>Please keep in mind that the committee members must wade through many<br></div><div>different proposals covering all aspects of character encoding.  Keep it<br></div><div>short, straightforward, and simple as possible to ease their burden.<br></div></div></blockquote></div><div>The character has already been proposed. What would any future proposal have to do with that?<br></div></div></div></div><div><br></div>