Proposal to add standardized variation sequences for chess notation

[Christoph Päper]

Garth Wallace <gwalla at gmail.com>:
> On Thu, Apr 6, 2017 at 5:19 AM, Christoph Päper <christoph.paeper at crissov.de>
> wrote:
> 
> >  Although Michael Everson readily dismisses any connection to emojis, (...)
> >  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 (...)
>
> The only connection this has with emoji is that it uses the variation selector
> system.

As I've shown, that's not the *only* connection.

> Emoji is a means of indicating full-color embedded images,

That may be how they are often conceived. It's not quite true, though. The first
sentence of UTS#51 reads:

    Emoji are pictographs (pictorial symbols) that are typically presented in a
colorful cartoon form and used inline in text.

That sounds similar, but is different in an important detail: the scope, active
vs. passive. Emojis do not reference images, but systems present them as images.

> ...  and usually rely on rendering or interpreting systems that substitute
> graphics,

Such systems are widespread, but emojis don't rely on them since they are true
characters.
Symbol fonts like Font Awesome, for instance, are usually PUA-only, although
they should be using codepoints of existing emojis and other symbols as much as
possible for fallback and interoperability reasons. They don't because they'd
risk that some of their consistent, monochrome glyphs would be replaced with a
colorful picture by an overly aggressive system.

> or various non-standardized font extentions. 

Opentype 1.8 standardizes as many as four approaches to colorful glyphs.

> None of that is necessary, or relevant, to chess diagrams.

Chess diagrams (unlike chess notation) are often rendered as graphics, not text.
Board and glyphs may have fancy designs and colors, e.g. wooden fields. You
would get that for free with emoji presentation, but fonts would not have to use
more than two colors. Note that "white" chess pieces should usually not be
rendered as outlines only, i.e. with transparent eyes, but with a solid whitish
interior. Almost all other pre-emoji characters with "White" in their standard
name are hollow. "Black" means always 'solid', but the actual color can be any
(including white), although text is still mostly typeset in a blackish color.

> I don't believe emoji are even necessarily fixed-width.

In all existing implementations they are. They are even always square. I'm not
sure whether their em square always matches the sinographic ("ideographic")
square, but it seems as if it usually does.

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

Usually empty squares would determine the backgrounds of adjacent pieces, but if
you have a line of adjacent chess pieces (up to 8 by standard rules) without any
empty square (e.g. before the first move), there would need to be some kind of
heuristic. I chose the colors of pieces that do not come in pairs (i.e. King and
Queen) and of the left-most figurines (Rook and Pawn) for a board with white at
the bottom, because that is the most common orientation. If you want, I could
write and post the code in Adobe OT feature file notation required for `calt` to
demonstrate that this would yield results as expected for all full-size 8*8
diagrams and even for many detail diagrams of a section of the board.