Dnia 31 stycznia 2025 22:08 James Kass via Unicode 
<[email protected]> napisał(a):  On 2025-01-31 5:42 PM, 
[email protected] via Unicode wrote:  I'm not saying that it is, but if 
I'm relying on arguments relevant to  the actual usage of the characters, 
and the dominant opposing side  does not provide all that much coherent of a 
reasoning in return, then  I'm getting suspicious.   Doug and Peter have 
provided some good advice with respect to such  suspicions.  My apologies to 
Peter Constable for my failure to  understand exactly what was being dismissed 
earlier in this thread.   Quoting from  www.unicode.org 
https://www.unicode.org/L2/L2025/25010-script-wg-report.pdf   "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."   
That seems coherent enough.  If a simple and concise exhibit can be made  
showing the desired distinction making a difference in plain text, then  that 
would be a logical next step.  Evidence illustrating data loss in  
round-tripping would also be helpful.  Input from the user community  
supporting retaining distinctions in Unicode should help the effort.   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.   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.

Reply via email to