Talk:ISO/IEC 10367

Issues with this article
Hi, to anyone who's reading this, there appear to be glaring problems with this article that have been overlooked. Looking around on google, I get the impression this isn't really a character set that just includes some box drawing characters, but a more general character set standard that specifies several character sets, including this box characters set (I think?). The sole reference given gives a "_BOX" suffix to the set's name, which the original author of the article may have missed. Also, the article probably should be moved to "ISO/IEC 10367" to reflect the proper standard name.

To support what I'm saying, here are some sources:
 * ISO/IEC 10367:1991 information page at iso.org
 * A preview of the ISO/IEC 10367:1991 document from the IEC webstore site [Added note: appears to actually be ISO/IEC 7350, which defines registration procedures for ISO/IEC 10367. --HarJIT (talk) 15:48, 23 September 2019 (UTC)]

I can't rewrite the article in light of these issues though, since I'm not experienced at that sort of thing here on Wikipedia (yet), and I haven't access to the actual full standard itself anyway. Anyone who can do something about these problems though, please do. 82.9.105.98 (talk) 04:55, 1 September 2017 (UTC)
 * It lacks the necessary encyclopedic context to exceed WP:NOTSTATS. What RS should I look for? – Laundry Pizza 03  ( d c&#x0304; ) 02:27, 30 April 2018 (UTC)

---

Dumping some partial information that I've gathered on what this standard is supposed to be (at least, insofar as it relates to ISO 8859 and ISO 2022):

Reading JTC1/SC2/WG3 N451 (the final open-access draft of what was published as ISO/IEC 8859-13) gives me the following:

This set of coded graphic characters may be regarded as a version of an 8-bit code according to ISO/IEC 2022 or ISO/IEC 4873 at level 1.

This part of ISO/IEC 8859 may not be used in conjunction with any other parts of ISO/IEC 8859. If coded characters from more than one part are to be used together, by means of code extension techniques, the equivalent coded character sets from ISO/IEC 10367 should be used instead within a version of ISO/IEC 4873 at level 2 or level 3.

ISO 4873 appears to be ECMA 43, which appears from a skim to be defined as a subset of ISO 2022 applied to 8-bit streams, without multibyte sets or shifts to GL. Level 2 uses single shifts to GR to GL, while level 3 uses both single shifts to GL and locking shifts to GR, and level 1 uses neither.

So here I gather that (a) ISO 10367 defines coded character sets, plural, (b) ISO 8859 sets are not supposed to be shifted between using ISO 2022, (c) ISO 10367 provides equivalent sets which are supposed to be switched between.

-- HarJIT (talk) 12:43, 15 August 2019 (UTC)

The box drawing set from ISO 10367 transpires to be registered as ISO-IR 155, and seeing a printed code chart does make me wonder about whether the Perl mappings are necessarily "correct": the first set are clearly both shown and named as heavy (as in e.g. ┏), not double (╔), unlike the Perl mappings. Also, 0xCB is clearly given as the upper half block (i.e. U+2580), whereas the Perl mappings map it to the private use area, annotating it as "Unit space B EISO-IR-8-1_60E" (i.e. it apparently believes it to represent the narrower of the two NATS fixed spaces). Hmmm. --HarJIT (talk) 19:46, 15 August 2019 (UTC)

Given the scarcity of 10367 resources, the fact that only the box-drawing one seems to have an ISO-IR registration (while others would need one to be accessible in 2022, and therefore 4873, unless they turn out to be mere subsets or aliases of other encodings), and that ISO-2022-JP-2 clearly mixes 8859 parts (gasp! not that non-compliance with ISO/IEC 8859 is exactly rare) rather than any elusive 10367 parts, I suspect that 10367 presumably didn't actually get adopted as intended (assuming, that is, that it isn't actually 8859 or 646 in a trenchcoat, which I have no grounds to assume)? Of course, the standard itself would clear some things up, except I'm not sure I'd get enough value out of fixing the article to warrant spending 158 francs on it (to say nothing of the apparently separate 7350).

I could at least fix the mappings to actually match ISO-IR-155, and possibly rename the article to ISO-IR-155 or ISO-10367-BOX since it's seemingly the tip of the iceberg for ISO 10367, but that would still be one source and no background information. Alternatively, adding the mentions from 8859 would be particularly confusing due to only the box set being displayed. And it still doesn't explain why the Perl mappings are divergent, especially not regarding 0xCB. --HarJIT (talk) 16:07, 23 September 2019 (UTC)

Just jotting down an additional reference to it: ISO-IR-166 (i.e. the registration for the G1 set of ISO-8859-11 or TIS-620) states it's "for use with the G0 set of ISO/IEC 10367:1991". --HarJIT (talk) 14:38, 25 September 2019 (UTC)

---

Finally I have tracked down an explanation:

ISO 10367 provides a collection of G-sets, suitable to be used with level 2 or level 3 of ISO 4873. ISO 10367 contains all G0 and all G1 sets from the parts 1-9 of ISO 8859, but also some additional ones (all these have got an IR nummer [sic] too, according to ISO 2375). There is a Supplementary Set of letters that do not occur in Latin 1 or 2, and a set of "box" characters.

Oh, okay, so ISO 8859-[1&hellip;9] (at least) are sync'd with ISO 10367, hence why ISO-2022-JP-2 is in a roundabout way permitted. As in, it's not an ISO-8859 encoding since it doesn't comply with ISO 8859's stipulations for using the sets (and in fairness, I'd be very confused if I saw ISO-2022-JP-2 listed as an ISO-8859 encoding), but it still complies with ISO 10367's stipulations for using the selfsame sets. This would also explain why the "equivalent coded character sets from ISO/IEC 10367" don't seem to have their own registrations, since their content is the same.

ISO-IR-155 would be one of the non-8859 parts.

--HarJIT (talk) 12:32, 2 October 2019 (UTC)


 * Hi, I am the anonymous IP address who flagged the issues with this article back over 2 years ago (wow has time flown by). Good to know that someone more knowledgeable has dealt with it now. =) ...not sure how I missed that second source I listed was actually a different ISO/IEC standard though, but oh well. Monster Iestyn (talk) 15:36, 29 February 2020 (UTC)