Re: Proposal to add standardized variation sequences for chess notation

From: Christoph Päper <>
Date: Thu, 6 Apr 2017 14:19:24 +0200 (CEST)

Mark Davis ☕️ <>:
> I'm looking forward to similar postings on checkers and go pieces. (...)
> And I'm looking also forward to the ♖+ZWJ+⬛️ (etc) proposal.

Well, actually ...

Garth Wallace made an important observation in

>> Currently, chess fonts can be (roughly) divided into "diagram fonts" and
>> "notation fonts".

The major goal of Michael Everson's proposal to introduce standardized sequences
with variant selectors 1 and 2 (U+FE00/1) for chess piece characters (primarily
U+2654-F), as far as I understand it, is to assure "diagram" glyph design. This
means fixed-width figurines centered in the character cell, with means for
square color and board border elements (incl. labels), whereas "notation" style
usually has proportional figurines sitting on the baseline.

The square color is ignored in standard chess notation, where fields are
conventionally known by their alphabetic column index ("file", A-H for a
standard checkerboard) and numeric row index ("rank", 1-8), i.e. A1 through H8,
which are virtually never styled as "⬛A1", "◻B1", "<background:black>B2</>"
whereas figurine charactres may either augment or substitute conventional letter

  - Black/dark squares are those whose file and rank are either both odd or both
  - White/light squares are those whose file is odd and rank is even, or vice

Corollary: The glyph background is almost only important within diagram

Diagrams may only show select squares, so the color of the first or last one and
hence intermediate ones cannot necessarily be deduced from the immediate
context. (They may be implied by row and column labels, which is simple for a
sighted human reader, but complex for computers and blind readers.)

Although Michael Everson readily dismisses any connection to emojis, e.g.
L2/16-021 or L2/16-087+088, and hence the Emoji and Emoji_Presentation character
properties as well as sequences with variation selectors 15 and 16 (U+FE0E/F),
normal emoji design actually matches "diagram" notation quite nicely in that all
emoji glyphs are rendered within an (ideographic / em) square. Black and white
squares are also already available as emojis in small U+25AA/B, medium-small
U+25FE/D, medium U+25FC/B and large U+2B1B/C. The last ones would probably be
preferred. Only the first ones are default text style characters. The characters
for empty squares from the proposal, U+25A8/1, have no emoji representation yet.
I've suggested to use the hatching characters U+25Ax for their colors as in
heraldic tinctures, which relate U+25A8 to Purple ("purpure").

Without the need for ZWJ sequences, Opentype fonts can employ their Contextual
Alternates `calt` feature to select the correct background color in diagram
notation: In a sequence of up to eight chess pieces without an empty square with
explicit color, an initial U+2656-FE0F White Rook, U+2654-FE0F White King,
U+265B-FE0F Black Queen or U+265F-FE0F Black Pawn would default to a black
background, U+2659-FE0F White Pawn, U+2655 White Queen, U+265A-FE0F Black King
or U+265C-FE0F Black Rook to a white background. Other than that, each character
uses the alternate glyph with opposing background color from its preceding
(left-side) glyph. The empty squares work as explicit anchors.

A font intended for print wouldn't have to use any fancy colors or effects for
emoji glyphs, but only infer the centered squared presentation from a variation
selector, so it could still use proportional glyph in running text.

In conclusion, although I support the proposal in principle, I strongly suggest
to consider to use established VS-16 and implicit contextual backgrounds instead
of arbitrary VS-1 and VS-2 with explicit backgrounds.

(With only VS-16, my previous remarks about the representation of empty squares
would be somewhat moot. Technically, it's still redundant, but at least it would
be consistent.)


- L2/16-021:
- L2/16-087:
- L2/16-088:
- Hatching colors: etc.
Received on Thu Apr 06 2017 - 07:19:38 CDT

This archive was generated by hypermail 2.2.0 : Thu Apr 06 2017 - 07:19:39 CDT