<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 2/3/2025 9:36 AM, Sławomir Osipiuk
via Unicode wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1738603804156.1426487909.77361119@gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<span class="viv-signature"></span>On Monday, 03 February 2025,
12:19:06 (-05:00), Peter Constable via Unicode wrote:<br>
<br>
<blockquote
style="margin: 0 0 0.80ex; border-left: #0000FF
2px solid; padding-left: 1ex">
<style>div.WordSection1{
page:WordSection1;
}.MsoChpDefault{
}span.EmailStyle20{
color:windowtext;
font-family:Aptos, sans-serif;
}a:link, span.MsoHyperlink{
text-decoration-color:initial;
text-decoration-style:initial;
text-decoration-thickness:initial;
text-decoration-line:underline;
color:blue;
}p.MsoNormal, li.MsoNormal, div.MsoNormal{
font-family:Aptos, sans-serif;
font-size:12pt;
margin-left:0in;
margin-bottom:0in;
margin-right:0in;
margin-top:0in;
}@font-face {
font-family:Aptos;
}@font-face {
font-family:Calibri;
}@font-face {
font-family:"Cambria Math";
}</style>
<div class="WordSection1">
<p class="MsoNormal">As stated previously, Unicode makes no
guarantee of supporting source separation / round-trip
compatibility with HP264x.</p>
</div>
</blockquote>
<div><br>
</div>
<div>I'm honestly surprised by this. I always thought (because it
was repeated so many times - must remember repetition does not
equal truth) that round-trip compatibility with old character
sets was a founding cornerstone of Unicode and so contrastive
use (aka source separation) in an old charset would be
persuasive evidence for inclusion.</div>
</blockquote>
<p>You guys are talking past each other a bit.</p>
<p>Unicode decided early on to guarantee round-trip to important,
widely used character sets of the time. The key interest was to be
able to deploy software that worked internally in Unicode but
could interface with existing systems without incurring data loss
in round trip.</p>
<p>This level guarantee does not exist for just any character set.
It didn't even exist for all character sets then in existence.</p>
<p>However, if conflating two characters causes a particular
problem, Unicode has accepted case-by-case requests not to unify
them, or even to disunify them. However, instead of applying a
guarantee, the UTC will look at a bit of a cost/benefit analysis,
considering the cost of having to encode additional characters (in
perpetuity) vs. the benefit for the intended users.</p>
<p>If this is a problem with a single character, I don't really buy
the cost savings argument, especially in a case where after adding
some extensions, a whole set could be matched. If there is a group
involved, the cost goes up.</p>
<p>On the other hand, I also would like to understand the benefit
for the supposed user group. Is it mainly that of avoiding a
single pixel infidelity in display only, or are these characters
that would need to round-trip, because they might be in data that
is entered on a simulated device, processed on a Unicode system
and then output again.</p>
<p>I think it's stupid for both sides to fight over a single pixel.
Yes, it smells like a bad unification even though the character is
arcane (but so are others where minute details matter even though
'nobody' is likely to use that character much). Having a stupidly
incomplete mapping can be frustrating, but is being unfaithful
going to impact users in any noticeable way? <br>
</p>
<p>A./<br>
</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>