Re: Proposal to add standardized variation sequences for chess notation

From: Asmus Freytag <>
Date: Mon, 3 Apr 2017 09:16:11 -0700

On 4/3/2017 5:42 AM, Michael Everson wrote:

Read to the end.
> On 2 Apr 2017, at 19:43, Asmus Freytag <> wrote:
>> It's a matter of perspective.
>> Higher-level semantic constructs are encoded in writing (or graphic notation), and you can see the individual marks, signs, letters and symbols as the element of this encoding. However, how strongly any of these marks, signs, letters and symbols are associated with a specific semantic, and how fixed that association is, depends on convention.
>> Asmus, I don’t follow this abstraction of yours. The proposal is simple. The proposal works when OpenType substitutions of “piece” plus “VS” are in the font and when an app can display such a substitution.
>> For example, "left arrow" has a very loose associating with a broad range of concepts that somehow relate to direction.
>> In contrast, "integral sign" is rarely associated with any concept outside calculus.
> And chess piece characters are symbols which mean chess pieces.
>> It's tempting then, to assume that the character for "integral sign" somehow directly represents the semantic of "integration" --- except it doesn't.
>> 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.
>> My dislike for using variation sequences in the way Micheal appear to advocate is based on a different reason:
> This is almost funny. Ordinarily I dislike variation sequences because I consider them pseudo-encoding.
>> 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.).

>> If they are, any plain text that depends on the contrasting use of white and black chess background will become meaningless gibberish.
> This is untrue. Did you not read the proposal? Look again at Figure 3. In the left hand column, the top example, which is only one of the several AsCII-based ways that chess fonts represent chessboards today (without any Unicode chess characters at all). It is legible only if that particular font is loaded. The middle example in the same column is not very good looking. But it is stable, parseable, exchangeable data which gives unique tokens for the empty squares in two colours and which contains the chess characters. It’s not “meaningless gibberish” and it’s not even very difficult to read. Same for the bottom example, which has been force-justified to facilitate legibility; while that font has visible glyphs for the variation selectors, it needn’t.
>> In these cases, explicit encoding would better cover what is desired: a reliable way to mark a distinction between different symbols (the two bishops are separate symbols, that also happen to express distinct, though related concepts -- it is not a single symbol with some ignorable attributes).
> Well, Asmus, if by "explicit encoding” you mean “add more chess characters” this would require the trebling of the number of basic chess characters from 12 to 36. You couldn’t get away with adding just six chesspieces-on-black because then fonts would be forced to draw all the chesspieces-on-white with the same em-square metrics needed to produce chessboards. But that would mean that nobody could use the ordinary chess pieces as just symbols in plain text (as seen in Figures 6 and 8). I do not believe that burdening chess users with having to use different fonts for in-text characters on the one hand and board-layout on the other is a good idea, particularly when both forms of presentation are the norm in chess-problem publishing.
> Further, it would delay implementation of a chessboard solution till the summer of 2019 for no benefit, since the proposal here is simple to implement with nothing more than care on the part of the font designer.
> And when in the past encoding pieces-on-black has been suggested, the answer has been: no, use a higher-level protocol.
> This proposal is a robust and simple higher-level protocol. It enables the preparation of parseable chessboards without having to add characters, or without the problem of having pieces-for-use-in-text looking nearly identical to pieces-for-use-on-white-squares.
>> Now, for the case of suggesting the chess-board cell dimensions, I do not have the same objection to the use of variation selectors. If the variation selectors get stripped, the text may require manual formatting to look correct, but it will still contain the correct symbols (and applying the chosen convention, you will be able to know which bishop is meant).
>> That's much closer to the way variation selectors are intended to be used.
> What? You are very unclear here. 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

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.

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.

That's all.
> Michael Everson
Received on Mon Apr 03 2017 - 11:16:24 CDT

This archive was generated by hypermail 2.2.0 : Mon Apr 03 2017 - 11:16:24 CDT