Re: Proposal to add standardized variation sequences for chess notation

From: Asmus Freytag (c) <>
Date: Mon, 3 Apr 2017 15:07:38 -0700

On 4/3/2017 2:15 PM, Michael Everson wrote:
> On 3 Apr 2017, at 17:16, Asmus Freytag <> wrote:
>>>> The same indirection is at play here.
>>> This is pure rhetoric, Asmus. It addresses the problem in no way.
>> Actually it does. I'm amazed that you don't see the connection.
> I’ve never understood you when you back up into that particular kind of abstract rhetoric.

Sometimes thinking through something in abstract terms actually
clarifies the situation.

>>>> the oft-stated fact that variation selectors may be ignored.
>>> I’m aware of this. I may be wrong, but I believe you advocated for the encoding of variation sequences for mathematics purposes.
>> Yes, for those cases where the differences are known to not carry meaning, but where duplicating all fonts or duplicating the characters would have been the wrong solution to allow support for both conventions (e.g. upright vs. slanted integral signs, details of relational operator design, etc.).
> The “meaning” of a chess-problem matrix is the whole 8 × 8 board, not the empty dark square at b4 or the white pawn on

In other words, you assert that partial boards never need to be
displayed. (Let's take that as read, then).
> The “problem” the higher-level protocol is supposed to solve is the one where a chess piece of one colour sits in an em-squared zone whether light or dark. In lead type this was a glyph issue. Lead type had just exactly what my proposal has: A piece with in-line text metrics, spaced harmoniously with digits and letters, and square sorts with and without hatching.

Leaving aside the abstract question whether modeling lead type is ipso
facto the best solution in all cases...

> Standardized variation sequences are the best way to achieve this simply and without needless duplication. :-)
>>> Are you saying that the empty white and black squares should use VS but the chess pieces are not? That makes no sense to me at all.
>> I'm saying that perhaps it would be appropriate to select M-square glyph variants via a variation selector. That seems a clear-cut glyph *variation* to me. (If this variation is ignored, then the text looks bad, but in a way that is similar to selecting the wrong font - which is a rule-of-thumb way of evaluating whether variation selectors are appropriate).
> OK, then you support the part of the proposal that applies VS1 and VS2 to the chess pieces.

My statement just was that a proposal where piece + VS should be
M-square, piece w/o VS should be generic, might make some sense (and
same for a suitable "empty" cell).

The next question would be whether the alternation in background is best
expressed in variation sequences or by some other means.

If you never need to show just a single field, then I concede that the
main drawback of variation selectors for the background style is absent;
however, reading ahead in your message, the partial grid appears to be
common, therefore the reason to choose an alternate solution to the
background style is a strong one.
>> The distinction between white/black background might be of a different nature. If you have arranged everything in a grid with the correct matrix, then the color of the background is perhaps redundant, given that there is a uniform convention for it.
> Yes but you still want it to be reasonably legible when the OpenType ligatures fail. I think that this:
> ▗▁▁▁▁▁▁▁▁▖
> ▕□︀▨︁□︀▨︁□︀▨︁♞︀▨︁▏
> ▕▨︁□︀▨︁□︀▨︁□︀▨︁□︀▏
> ▕□︀▨︁♔︀▨︁□︀▨︁□︀▨︁▏
> ▕▨︁□︀▨︁□︀▨︁♘︀▨︁□︀▏
> ▕□︀▨︁□︀▨︁♚︀▨︁□︀▨︁▏
> ▕▨︁□︀▨︁□︀▨︁□︀▨︁□︀▏
> ▕□︀▨︁□︀♙︁♛︀▨︁□︀▨︁▏
> ▕▨︁□︀♕︁□︀▨︁♖︀▨︁□︀▏
> ▝▔▔▔▔▔▔▔▔▘
> is far better than this:
> ▗▁▁▁▁▁▁▁▁▖
> ▕□︀□︀□︀□︀□︀□︀♞︀□︀▏
> ▕□︀□︀□︀□︀□︀□︀□︀□︀▏
> ▕□︀□︀♔︀□︀□︀□︀□︀□︀▏
> ▕□︀□︀□︀□︀□︀♘︀□︀□︀▏
> ▕□︀□︀□︀□︀♚︀□︀□︀□︀▏
> ▕□︀□︀□︀□︀□︀□︀□︀□︀▏
> ▕□︀□︀□︀♙︁♛︀□︀□︀□︀▏<< Is it the pawn or the queen that’s on the black square?
> ▕□︀□︀♕︁□︀□︀♖︀□︀□︀▏
> ▝▔▔▔▔▔▔▔▔▘
> See? To parse this one you have to remember which of the white squares are the alternating black ones. I don’t consider that as legible as using both 25A1 and 25A8.
> The colour of the matrix is NOT redundant for a human reader.
OK -- in that case you've actually made an argument for *duplicating
*the codes for *ALL *the pieces (as well as the empties). That way, you
are guaranteed that (if the font supports the glyphs) you get what you
want. With variation selectors for background color, you do not get what
you want for the pieces.

Having the system use specific character codes for the empties and
variation selectors for the pieces is a needless complication; just
duplicate the few pieces with a hatched background. (The precise style
of hatching should be left to the font - that's not something that you
specify in plain text).

Leave the question of requesting M-square metrics to a (single)
variation selector and you are done. (the convention would be that 25A8
+ VS results in an M-square glyph using some hatching that matches that
of the hatched code points for chess pieces, not necessarily matching
the hatching style that you get for 25A8 w/o the VS). (Alternatively,
you could add a code for "dark cell" so that the hatching can be
anything whether or not there's VS).

Now, this model is much closer to the way VSs are used for math
operators (but the reasoning may be a bit abstract, so I won't bother
you with it here).
>> If you assume the characters will ever be used outside a full grid, then that assumption fails and it will not be possible to restore the intended meaning if the variation selectors are missing. That's a warning flag, that they may not be appropriate for that use.
> You can’t assume that they wouldn’t be. All of my examples in §2 of the proposal are in fact outside of a full grid. I think the proposal as it stands ticks the most boxes. (I have changed “black square” and “white square” to “dark square” and “light square” however.
If the proposal duplicates the pieces that are on dark squares and does
not use any VS sequences to select the color of the square (but only to
select the M-square metrics) it would be more robust and less complex to
implement. (A chess font would not need to do anything but provide the
right glyphs and ignore the VS, because they would be in M-squar metrics

Received on Mon Apr 03 2017 - 17:08:06 CDT

This archive was generated by hypermail 2.2.0 : Mon Apr 03 2017 - 17:08:06 CDT