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./

Reply via email to