Re: Square Brackets with Tick

[Asmus Freytag]

On 8/22/2015 2:47 PM, Richard Wordingham wrote: But codepoints are normally orderly until they enter the ISO approval process. Thereafter, disorder creeps in, and becomes ever more likely as blocks fill up Haha, good one. . The concern here is that the opening-closing pairing information, which used not to be a property, has been deduced wrongly. The code chart is prima facie evidence that whoever drew the order up conceived of U+298D and U+298E as a pair. Not necessarily. Code charts are sometimes ordered in mysterious ways. However, read on. I've traced the character as far back as http://www.unicode.org/L2/L1999/99159.pdf . Unfortunately, its meaning therein is implicitly described as unknown! It looks as though someone somewhere fashioned type for it - or perhaps another of the set of four - but no-one remembers what it was used for! This document doesn't tell you what the pairing is supposed to be, only that which ones are opening and closing (so we know that they are intended to be arranged [ ] and not ] [ (ticks omitted), but we don't know which of the two [[ go with which of the two ]], other than the - natural - assumptions that pairs are listed adjacently). For the first document that gives the pairing information, see: http://www.unicode.org/L2/L2012/12173r-bidi-paren.pdf There is no note or other indication in this document that shows that any thought was put into the different ordering. However, it is notable that all other bracket pairings follow the bidi mirroring glyph relation, so I would put my money on that that file was used to create the pairs using a script, rather than manual editing. This is corroborated in section 3.2 of that document. Nigel was the first to notice that these were not encoded as left-right glyph pairs, but with the diagonal "tick" (originally called a solidus) having the same orientation in a pair (as if intended to bracket something in either diagonal or anti-diagonal direction). Given that L2/12-173 states that the property was derived via algorithm that is based on left-right mirroring and not via matching open/close pairs based on other factors, (including adjacency in the charts) I'm happy to join the growing chorus that declares this to be a bug. Luckily there seems to be no stability policy that would prevent fixing this one. A./