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./
Received on Sat Aug 22 2015 - 19:54:58 CDT