Proposal to add standardized variation sequences for chess notation

Christoph Päper christoph.paeper at crissov.de
Mon Apr 10 05:40:25 CDT 2017


Michael Everson <everson at evertype.com>:
> On 7 Apr 2017, at 23:17, Christoph Päper <christoph.paeper at crissov.de> wrote:
> 
> >> 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.
> 
> Christoph, YOU ARE WRONG.

Even if I were, nobody has proven that. Everybody is just shouting out their
presumptions and prejudices, full of falsehoods.

> Emoji as a special relationship with vendors and a particular implementation
> environment. 

That is true. It does not mean that

a) this environment would not be used to interchange chess diagrams nor
b) parties interested in rendering textual chess diagrams couldn't take
advantage of it and bend it to their requirements.

> Vendors via the UTC look at symbol and pictograph and other characters and
> decide if they want to give these symbols and pictographs and other characters
> the special characteristic which implies generally colour rendering and
> implies an obligation to supply input methods for those characters.

Yes, Unicode's emojification process is still seriously broken. It's not an
argument against reusing the underlying techniques, though.

> nobody needs to send an 8 x 8 chessboard matrix in a tweet. Get it?

Now you are kidding, right? With 68 chars remaining for comments, stuff like
#chesspuzzle would be much improved if replies could include boards as well
without resorting to screenshots (which requires rebuilding the diagram in your
favorite chess app) or image editors, just copy and paste of text characters.
Most serious players would continue to rely on more or less proprietary exchange
formats within their preferred app, though.

> Please stop trying to conflate emoji and chess characters. It is NOT, I think,
> a solution which the UTC would agree to. I would oppose it in SC2. 

That's why I'm trying to convince you (but not just you) in this early stage.

> Two centuries of standard chess diagramming practice is all that’s needed to
> support.

In a B2C-only publishing world perhaps. It's not what we're living in any more,
fortunately.

> >> I don't believe emoji are even necessarily fixed-width.
> > 
> > In all existing implementations they are.
> 
> That’s not true. 

Could you please provide a counter example?

The original Japanese sets did feature three space characters for full, half and
another partial (1/3?) ideographic width, but none of the visible glyphs were
less than fullwidth.

> > They are even always square.
> 
> Not always, and that’s enough chaos. There is no standardization currently in
> chess fonts. 

*Emojis* are always square. I didn't say anything about fonts used for chess
diagrams here.

> > Without the need for ZWJ sequences, 
> > Opentype fonts can employ their Contextual Alternates `calt` feature 
> > to select the correct background color in diagram notation: (...)
> 
> (...) there’s no legible fallback if the “calt” features can’t be invoked.

In a standard 8 by 8 squares chess diagram using U+2654..F and U+2B1B/C, you
would still have *at least* 32 squares (i.e. 50%) with explicit color shown.
Emoji characters line up on the ideographic grid. Even if figurine glyphs had no
distinctive background color, it would still be legible.



More information about the Unicode mailing list