Proposal to add standardized variation sequences for chess notation

Christoph Päper christoph.paeper at crissov.de
Mon Apr 10 03:49:33 CDT 2017


Garth Wallace <gwalla at gmail.com>:
> 
> On Fri, Apr 7, 2017 at 3:17 PM, Christoph Päper <christoph.paeper at crissov.de>
> wrote:
> > 
> >  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.
>
> My point is that the features that distinguish emoji from other symbols in
> Unicode are not required, 
> and in many cases not desired, for typesetting chess diagrams. It complicates
> things for no reason.

If Unicode chess diagrams used VS-16 instead of VS-1 and VS-2, users could one
day choose a font that fakes marble, wood, glass, steel or just some random
color or even animation for pieces and board squares. Since this kind of
customization is a common feature in chess applications, I'd expect it to be a
welcome feature for textual diagrams as well, even if it's not used (much) in
print books. Within the web ecosystem that relies upon CSS for styling, authors
and readers could very well and easily use different designs. With non-emoji
chess characters, the differences would mostly be limited to glyph outlines.

Is that "no reason"?

> And risking that some consistent monochrome glyphs would be replaced with
> colorful pictures 
> by overly aggressive systems is also something that should be avoided with the
> chess symbols.

VS-15 should be better at that than any other variation selector. 

I know that recent Samsung Android devices provide emoji glyphs for chess
pieces, but have no such device available to test whether and how they react
differently on no VS, VS-1..14, VS-15 and VS-16, with and without a supporting
font provided.

> Chess diagrams *are* often rendered as graphics. When people want things like
> wood grain squares, they use graphics.

See above: with emoji chess pieces users would have the choice to display
textual board diagrams in their preferred style. In some cases, people and users
are authors or editors, but readers elsewhere.

> Chess diagrams are *also* frequently typeset with fonts, using the same means
> as text.
> When doing so, the results are monochrome, with diagonal hatching for the dark
> squares.
> This is well established practice.

I do not contest any of that.

> Full color display of conventionally typeset diagrams would not be expected
> behavior, 
> nor, in many cases such as publishing, would it be welcome behavior. It's the
> wrong tool for the job.

Again: emoji glyphs are not required to use more than a single color, cf.
I-Mode, Android 4.3, Windows 7, Symbola, Emojione B&W, Adobe Source Emoji.

> Look, this proposal is not about "Wouldn't it be a neat idea if we could make
> chess diagrams in text?" People had that neat idea before they had the neat
> idea for Unicode, or for computers for that matter. This is about removing a
> barrier to people using Unicode instead of various mutually-incompatible
> dingbat fonts for something they already regularly do.

I understand that perfectly well. Currently, Unicode chess pieces are only
well-suited for figurine notation, not for 2D diagrams. I even agree with the
approach to use variation selectors. I just think that there would be
significant positive synergy from reusing the infrastructure already established
for emojis.

> Doesn't matter. My point was that fixed width is not an inherent quality of
> emoji, it's just common.

That's what I'm telling you about colorfulness. I provided several counter
examples for the latter above, but know none for the former.

UTS#51 has this to say on the matter:

    Current practice is for emoji to have a square aspect ratio, deriving from
their origin in Japanese. 
    For interoperability, it is recommended that this practice be continued with
current and future emoji.

> >  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. (...) 
> >  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.
>
> I suppose a guess with a 50/50 chance of being wrong is still considered a
> heuristic, of sorts. 
> I would like to see your proof of concept (...) since I'm very skeptical that
> this would work reliably in practice.

It works with 100% accuracy for every row that contains at least one empty
square (with explicit color). For pieces of all the same color, this basically
only happens for the two rows at the top and bottom in the initial position.
These are taken care of by examining the first character in a series of eight:
rook or pawn, black or white. I've added king and queen only for robustness in
diagrams that do not show the full 8 by 8 standard board. Even where it could
fail, the diagram would probably be just as valid for the alternate alternating
pattern.

> One nice thing about the existing VS proposal is that it does not require any
> heuristics at all. 
> Each square is explicitly marked as light or dark, with no guessing needed.

The UI/UX drawback is that authors have to explicitly mark every field -- unless
you put the heuristics there.



More information about the Unicode mailing list