Proposal to add standardized variation sequences for chess notation

[Garth Wallace]

On Thu, Apr 6, 2017 at 5:19 AM, Christoph Päper <christoph.paeper at crissov.de
> wrote:

> Mark Davis ☕️ <mark at macchiato.com>:
> >
> > 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
> <http://www.unicode.org/mail-arch/unicode-ml/y2017-m04/0090.html>:
>
> >> 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.
>
>
This is all correct.


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

Usually substitute, but yes.


>
>   - Black/dark squares are those whose file and rank are either both odd
> or both
> even.
>   - White/light squares are those whose file is odd and rank is even, or
> vice
> versa.
>
> Corollary: The glyph background is almost only important within diagram
> notation.
>

Yes, this is acknowledged in the proposal.


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

Also, I believe that existing fonts and text rendering systems cannot tell
what is above or below the current line, so there is no way to determine
what the background should be based on rows.

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").
>

The only connection this has with emoji is that it uses the variation
selector system. Emoji is a means of indicating full-color embedded images,
and usually rely on rendering or interpreting systems that substitute
graphics, or various non-standardized font extentions. None of that is
necessary, orrelevant, to chess diagrams.

I don't believe emoji are even necessarily fixed-width. That's incidental
(and I think some implementations of the flags are wider than 1em).


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

I don't see how this would work. Any row with a white rook on the first
file would start with a black background? What?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20170406/a7f0bace/attachment.html>