<div dir="ltr">Is there an open access version of 14652 ? It sounds like an extension of chapters 6 and 7 of the Posix spec? The ISO desc mentions APIs that will be developed? Also it looks like the spec is currently withdrawn, is there a replacement? <a href="https://www.iso.org/standard/37069.html">https://www.iso.org/standard/37069.html</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 29, 2019 at 2:11 PM &lt;<a href="mailto:keld@keldix.com">keld@keldix.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Apr 29, 2019 at 02:00:23PM -0400, Steve Downey wrote:<br>
&gt; Not &quot;some&quot;. I want the entire set of Unicode functionality as a first class<br>
&gt; citizen, although some of them have higher priority than others.<br>
<br>
<br>
I am willing to consider support for all of unicode functionality.<br>
much is however not defined by unicode. and not in a c/c++ style<br>
I think some unicode is not well designed, like ucs16.<br>
(the stuff they copied from me, however, is ok:-)<br>
<br>
<br>
<br>
<br>
&gt; Keld, what capabilities not provided by Unicode algorithms and databases<br>
&gt; are you concerned about not being supported? I&#39;ve been doing text<br>
&gt; processing a lot, and working with code points or scalar values has made my<br>
&gt; life easier, with less complaints from my customers. Well, except for a few<br>
&gt; who don&#39;t like CDATA in XML dumps, but were somehow OK with utterly broken<br>
&gt; XML.<br>
<br>
i did a number of designs that they have not yet copied, eg in 14652, and posix has some<br>
non-unicode stuff on the way.<br>
<br>
keld <br>
<br>
&gt; On Mon, Apr 29, 2019 at 1:48 PM Steve Downey &lt;<a href="mailto:sdowney@gmail.com" target="_blank">sdowney@gmail.com</a>&gt; wrote:<br>
&gt; <br>
&gt; &gt; The &quot;POSIX&quot; and &quot;C&quot; locales, where the &quot;POSIX&quot; locale is the superset of<br>
&gt; &gt; capabilities of the &quot;C&quot; locale, but otherwise by definition equivalent, is<br>
&gt; &gt; the one you get if you do not make a setlocale() call.<br>
&gt; &gt; So, not _a_ posix locale, but _the_ POSIX locale.<br>
&gt; &gt;<br>
&gt; &gt; On Mon, Apr 29, 2019 at 1:37 PM &lt;<a href="mailto:keld@keldix.com" target="_blank">keld@keldix.com</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;&gt; On Sun, Apr 28, 2019 at 05:25:28PM -0400, JeanHeyd Meneide wrote:<br>
&gt; &gt;&gt; &gt; On Sun, Apr 28, 2019 at 4:01 PM &lt;<a href="mailto:keld@keldix.com" target="_blank">keld@keldix.com</a>&gt; wrote:<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt;   I believe there are a number of encodings in East Asia that there<br>
&gt; &gt;&gt; will<br>
&gt; &gt;&gt; &gt; &gt; still be<br>
&gt; &gt;&gt; &gt; &gt; developed for for quite some time.<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt; major languages and toolkits and operating systems are still<br>
&gt; &gt;&gt; character set<br>
&gt; &gt;&gt; &gt; &gt; independent.<br>
&gt; &gt;&gt; &gt; &gt; some people believe that unicode has not won, and some people are not<br>
&gt; &gt;&gt; &gt; &gt; happy with<br>
&gt; &gt;&gt; &gt; &gt; the unicode consortium. why abandon a model that still delivers for<br>
&gt; &gt;&gt; all?<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt; &gt; keld<br>
&gt; &gt;&gt; &gt; &gt;<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; I think there&#39;s really only one thing that needs to be fixed, and that&#39;s<br>
&gt; &gt;&gt; &gt; the POSIX and C locales. Right now, they force a by-requirement 256<br>
&gt; &gt;&gt; &gt; single-byte encoding. (Chapter 6, Section 2, first sentence:<br>
&gt; &gt;&gt; &gt; <a href="http://pubs.opengroup.org/onlinepubs/9699919799/" rel="noreferrer" target="_blank">http://pubs.opengroup.org/onlinepubs/9699919799/</a>).<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; the posix std has since 1991 had provisions for iso 10646 and most posix<br>
&gt; &gt;&gt; implementations<br>
&gt; &gt;&gt; today supports iso 10646 and iso 14651 - with a lot of collation and<br>
&gt; &gt;&gt; character attribure support<br>
&gt; &gt;&gt; long befor unicide made something up.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; This restriction is what has been utterly and absolutely destroying the<br>
&gt; &gt;&gt; &gt; ability to behave properly with a large set of encodings deployed around<br>
&gt; &gt;&gt; &gt; the world, including Unicode, as a default. I am actually spending time<br>
&gt; &gt;&gt; and<br>
&gt; &gt;&gt; &gt; cycles now contacting people on the C Standards Committee and reaching<br>
&gt; &gt;&gt; out<br>
&gt; &gt;&gt; &gt; to people to find the POSIX individuals responsible for overseeing this<br>
&gt; &gt;&gt; &gt; standard: that the locale is a single-byte encoding is not &quot;character<br>
&gt; &gt;&gt; set<br>
&gt; &gt;&gt; &gt; independent&quot;: it means that only a small fraction (ASCII, or similar)<br>
&gt; &gt;&gt; can<br>
&gt; &gt;&gt; &gt; possibly be the default C or POSIX locale. That Unicode (specifically,<br>
&gt; &gt;&gt; &gt; UTF8) happens to work in C and C++ is because the defaults for many of<br>
&gt; &gt;&gt; the<br>
&gt; &gt;&gt; &gt; implementations simply pass char/wchar_t/char16_t/char32_t through their<br>
&gt; &gt;&gt; &gt; interfaces and do not touch it. But, the moment anyone uses facets or<br>
&gt; &gt;&gt; &gt; locales in any meaningful manner, much of it falls over.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; this is not true, quite the contrary.<br>
&gt; &gt;&gt; yes posix has a standard posix locale which is 7/8 bit and portable,<br>
&gt; &gt;&gt; but 10646 has been supported since 1991 in posix. and works are inderway<br>
&gt; &gt;&gt; for a posix 10646 locale,<br>
&gt; &gt;&gt; iso 14652 has a candidate for that which is also the base for many glibc<br>
&gt; &gt;&gt; national locales.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; POSIX/C need to acknowledge that multibyte encodings are reasonable<br>
&gt; &gt;&gt; &gt; defaults (not just recommended extensions, but plausible defaults).<br>
&gt; &gt;&gt; Until<br>
&gt; &gt;&gt; &gt; then, no: the C standard does not deliver for all and actively harms the<br>
&gt; &gt;&gt; &gt; development and growth of international text processing on large and<br>
&gt; &gt;&gt; small<br>
&gt; &gt;&gt; &gt; hardware systems.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I think you are not up to date. how can Linux and osx and other posix<br>
&gt; &gt;&gt; os&#39;es deliver<br>
&gt; &gt;&gt; fully internationalized systems with support for more languages than<br>
&gt; &gt;&gt; microsoft windows?<br>
&gt; &gt;&gt; linux supports more than 100 languages, an mostly in utf-8.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; keld<br>
&gt; &gt;&gt; _______________________________________________<br>
&gt; &gt;&gt; SG16 Unicode mailing list<br>
&gt; &gt;&gt; <a href="mailto:Unicode@isocpp.open-std.org" target="_blank">Unicode@isocpp.open-std.org</a><br>
&gt; &gt;&gt; <a href="http://www.open-std.org/mailman/listinfo/unicode" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/unicode</a><br>
&gt; &gt;&gt;<br>
&gt; &gt;<br>
</blockquote></div>