How was the order of Unicode block-quadrant characters chosen?

Question

Unicode codepoints 0x2596–0x259f can help you draw primitive graphics by offering all the combinations of on or off for the four quadrants of a glyph. They're available in this order:

▖  ▗  ▘  ▙  ▚  ▛  ▜  ▝  ▞  ▟
00 00 10 10 10 11 11 01 01 01
10 01 00 11 01 10 01 00 10 11

Actually, that's only ten of the sixteen you need for the full set. The remainder are scattered a bit:

0020 2580 2584 2588 258C 2590
     ▀    ▄    █    ▌    ▐
00   11   00   11   10   01
00   00   11   11   10   01

...but I think I more or less understand why they're scattered. Space is a leftover from ASCII, and the others sit in very pretty patterns in codepoint-space. The lower half block sits in a sequence of seven increasingly-tall blocks (terminating with the full block), and the left half block sits in a sequence of seven decreasingly-wide blocks (beginning with the full block), while the upper half and right half hang out at the respective ends of those sequences.

But how was the order of the first ten mentioned in this question chosen? Some hypotheses I pondered but rejected:

1. The first three all have just one of the four quadrants "on"... but the fourth one does not follow this pattern, with the final single-quadrant codepoint lying near the end of the sequence. So we don't group them together by quadrant count.

2. If you think of the bottom left quadrant as the least significant bit, followed by the bottom right, top left, and top right, then the first three could be understood as simply "counting up" (skipping over the blocks that are scattered around the rest of codepoint space), but then the fourth one in that pattern actually appears in position five instead.

3. If you look at just the top left and top right quadrants, it looks like a nice clean gray code. But the bottom two bits don't appear (to me) to be continuing that pattern. For example, I would expect 00/01 to transition through 10/01 to 10/00, but 10/01 appears later in the sequence.

4. There are ten of them, which factors to 2×5; perhaps laying them out that way reveals something?

    ▖  ▗  ▘  ▙  ▚
   ▛  ▜  ▝  ▞  ▟
   ▖  ▗
   ▘  ▙
   ▚  ▛
   ▜  ▝
   ▞  ▟
   

   I don't see anything obvious.

So what was the process used to decide their order?

Answer 1

U+2596–U+259F were added in Unicode 3.2.0 (see the relevant delta code chart), as a result of this proposal. None of the available documents explain the sequence of code points chosen — worse than that, the proposal explains where the characters come from, but the code points don’t follow the order used in the source character sets. However the character names suggest an order:

• Quadrant LL
• Quadrant LR
• Quadrant UL
• Quadrant UL and LL and LR
• Quadrant UL and LR
• Quadrant UL and UR and LL
• Quadrant UL and UR and LR
• Quadrant UR
• Quadrant UR and LL
• Quadrant UR and LL and LR

It’s possible that each character was described by listing its “set” quadrants from top-left to bottom-right, using acronyms shared throughout the proposal (“LL” etc.); and then the overall list was sorted alphabetically. The result is inconsistent (UL to LR inside individual character names, LL to UR in the list)…

(Intriguingly, the 3.2 technical report doesn’t mention these characters at all!)

Answer 2

To start with it's important to keep in mind that Unicode is not intended and does not provide any means of binary sequence, other than no two characters having the same code point. Thus any addition is always done on random base. Pages are only meant to help looking for what space to be used next to keep it manageable.

The remainder are scattered a bit [...] but I think I more or less understand why they're scattered. Space is a leftover from ASCII, and the others sit in very pretty patterns in codepoint-space.

The main reason for this is that the 'Terminal graphic characters', as those 10 are called, have been added only after the 'pretty' ones. Code Page 2580 had in Unicode version 3.1 exactly 10 code points left, which worked out perfectly to have them inserted with 3.2 as seen in this PDF.

For the historical sequence:

The addition was originally proposed by Frank da Cruz (*1) for the Kermit Project at Columbia University in 1998 as part of an ongoing effort to integrate various terminal control and special and graphics characters. The various quarter squares were needed to incorporate

• Heath/Zenith 19 Graphics Character Set
• Wyse Graphics 3 Character Set
• Televideo 965 Multinational Character Set

Interestingly the UR/LL variant was not to be found in any of those character sets and added for completeness.

Timeline for inclusion:

• The first draft is of September 30, 1998
• The original proposal dates from November 10th, 1998 and suggested provisional usage at E0DB..E0E4.
• It was intended to be part of Unicode 3.0
• By March 31st, 2000 the proposal was revised to include changes made by Unicode 3.0 (two characters already included), as well as to add dome more characters to accommodate certain IBM mainframe character sets.
• In May 2000 the WG moved the Terminal Graphic Symbols for accept
• In September 2000 ISO WG2 accepted them
• In March 2002 they were officially published with Unicode 3.2 - now occupying 2596..259F

For the 'Why that sequence'

One can only guess for the exact reason, as non of the character sets referenced had the exact same order or even a logical order at all - except when looking at the Wyse WCS3. It features most of the quadrant symbols (13) and orders them in a somewhat circular fashion:

WCS3: |▝|▖|▗|▘|▐|▄|▌|▀|▙|▛|▜|▟|█|

Comparing those with Unicode 3.2 reveals that all WCS3 characters not already assigned otherwise do show up in exactly the same (non contiguous) sequence:

WCS3: |▝|▖|▗|▘|▐|▄|▌|▀|▙|▛|▜|▟|█|
      | | | | |*|*|*|*| | | | | |*| (Assigned otherwise)
UCS:  | |▖|▗|▘| | | | |▙|▛|▜|▟| |

With the sole exception of the upper right quadrant (▝). It and the missing 'diagonal' ones (|▚|▞|) seem to have been interspersed at will.

Then again, Stephen's remark about them being simply alphabetically sorted by name does make a very good point.

---

*1 - How hard Frank da Cruz fought - and what absurd arguments he had to fight, is in part documented in the mail communication about their inclusion:

I for my part do NOT!!!! want to see these terminal graphic things in the BMP. They belong in Plane 1.

Perhaps, but as the lawyers say, the door was opened by the characters already included in blocks at U+2400, U+2500, U+2600, and U+2700. In any case, the intention here is to help Unicode become somewhat more "technology-neutral". Terminal emulation is a fact of life, and important to a significant number of serious and productive computer users; why should its special glyphs be excluded from the same status enjoyed by dingbats and astrological signs? Seriously, I think terminal emulation is far more mainstream than many Unicoders seem to think, and I hope it is a worthy goal to welcome this constituency into the fold, thus allowing them to continue their work in their accustomed manner, rather than according to the dictates of haute couture, with the added bonus of uniform access to the world's writing systems.

I think he makes a pretty solid point. Terminal characters are the foundation of any character set to be unified.