<div><br></div><div class="nh_extra"><div id="gwp2a6526f8"><div id="gwp2a6526f8h"><div data-message-body="true" class="gwp2a6526f8b"><div class="gwp2a6526f8_nh_extra"><p>Dnia 01 lutego 2025 00:48 James Kass via Unicode <unicode@corp.unicode.org> napisał(a):<br></p><blockquote style="border-left: 2px solid #999; padding-left: 8px; margin: 0;" class="gwp2a6526f8_nh_quote"><div id="gwp2a6526f8_gwp879e10e7"><div>On 2025-01-31 11:15 PM, piotrunio-2004@wp.pl via Unicode wrote:<br></div><blockquote><div><br></div><div>Dnia 31 stycznia 2025 23:45 James Kass <jameskass@code2001.com><br></div><div>napisał(a):<br></div><div><br></div><div>   On 2025-01-31 9:28 PM, piotrunio-2004@wp.pl via Unicode wrote:<br></div><div><br></div><div>       The proposal L2/25-037 already shows a difference in plain<br></div><div>       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<br></div><div>       diagonal of<br></div><div>       same direction. Those are different types of connections which<br></div><div>       is a<br></div><div>       plain text distinction of box drawings.<br></div><div><br></div><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><br></div><div>That doesn't make sense because on a fundamental level, in a legacy<br></div><div>computing semigraphical environment, each character tile is drawn<br></div><div>independently, and only affects the area of the screen dedicated to<br></div><div>that character. Having a context dependent system would overcomplicate<br></div><div>the renderer beyond the scope of the original system. Furthermore, on<br></div><div>the HP 264x system, the two characters can exist in isolation (as<br></div><div>shown in obGQ4Ie.png (1440×720) (imgur.com)<br></div><div><<a ="" rel="noopener noreferrer" target="_blank" href="https://i.imgur.com/obGQ4Ie.png>),">https://i.imgur.com/obGQ4Ie.png>),</a> and the user can in fact type the<br></div><div>two characters differently, with the 2 and 8 keys as shown in page 31<br></div><div>of 204 in<br></div><div>02645-90005_2641A_2645A_2645S_N_Display_Station_Reference_Manual_Nov1978.pdf<br></div><div>(bitsavers.org)<br></div><div><<a ="" rel="noopener noreferrer" target="_blank" href="http://www.bitsavers.org/pdf/hp/terminal/264x/2645A/02645-90005_2641A_2645A_2645S_N_Display_Station_Reference_Manual_Nov1978.pdf>.">http://www.bitsavers.org/pdf/hp/terminal/264x/2645A/02645-90005_2641A_2645A_2645S_N_Display_Station_Reference_Manual_Nov1978.pdf>.</a><br></div><div><br></div></blockquote><div>Sorry for the confusion.  I'm referring to a Unicode "smart" font<br></div><div>working on a modern system displaying Unicode plain-text.  This is all<br></div><div>automatic and handled by the rendering system.  If a dedicated font is<br></div><div>used to display the text, contextual glyph substitution would make the<br></div><div>display indistinguishable from the original display on the legacy<br></div><div>system.  Also, on a modern system any "dumb" font supporting the<br></div><div>characters would still produce a *legible* display, even though it might<br></div><div>not be as pretty.  And legibility in plain-text is one of the factors<br></div><div>driving encoding decisions.  (This might be why font selection was<br></div><div>mentioned as a solution in the document referenced earlier.)<br></div></div></blockquote></div><div><br></div><div>That still cannot possibly work on isolated instances of the characters. In fact, if you have two different Large Character set strings that only differ by the use of 0x12 or 0x18 character, then the HP 264x will display them distinct in Unicode 16.0 mapping they will result in the exact same string and no amount of contextual glyph substitution will work. And as I said, complex features such as contextual glyph substitution are fundamentally completely out of scope for characters that originated from semigraphical text, no matter how modern the system displaying it is.<br></div><div><br></div><div><br></div><div class="gwp2a6526f8_nh_extra"><blockquote style="border-left: 2px solid #999; padding-left: 8px; margin: 0;" class="gwp2a6526f8_nh_quote"><div id="gwp2a6526f8_gwp879e10e7"><blockquote><div>       Data loss in round-tripping is implicitly evident from the<br></div><div>       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<br></div><div>       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><div><br></div><div>   Yes, this is implicit in the proposal.  Any future proposal should<br></div><div>   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. <br></div><div>   Keep it<br></div><div>   short, straightforward, and simple as possible to ease their burden.<br></div><div><br></div><div>The character has already been proposed. What would any future<br></div><div>proposal have to do with that?<br></div><div><br></div></blockquote><div>If my understanding is correct, the character has already been proposed<br></div><div>and rejected.  It's not uncommon for a subsequent proposal to be<br></div><div>submitted which addresses concerns raised during the rejection of an<br></div><div>earlier proposal.  (If my understanding is not correct, someone will<br></div><div>probably set me straight.)<br></div></div></blockquote></div><div><br></div><div>It's not in <a ="" rel="noopener noreferrer" target="_blank" href="https://www.unicode.org/alloc/nonapprovals.html">Archive of Notices of Non-Approval (unicode.org)</a> so it's not rejected.<br></div></div></div></div></div><div><br></div><br>