Square Brackets with Tick

[Nigel Small]

Thanks to everyone for your responses so far. In terms of my comment on
which brackets make intuitive pairs, I should perhaps have explained my
thought process more clearly. If one is to consider the possible origins of
these symbols, one likely idea is that they could be used to symbolise a
bracketed expression that has been "slashed through". In that context,
pairing the top left tick with the bottom right tick makes sense, as does
the pairing of the other two. Then, the original code point order remains
consistent (though I understand this need not have any relevance). This
appears to mirror Asmus' observation.
On 23 Aug 2015 1:58 am, "Asmus Freytag" <asmusf at ix.netcom.com> wrote:

> 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 ashttp://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./
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20150823/45ad25aa/attachment.html>