Proposal to add standardized variation sequences for chess notation

[Michael Everson]

On 3 Apr 2017, at 23:07, Asmus Freytag (c) <asmusf at ix.netcom.com> wrote:
> 
> On 4/3/2017 2:15 PM, Michael Everson wrote:
>> On 3 Apr 2017, at 17:16, Asmus Freytag <asmusf at ix.netcom.com> 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.

Of course I know that’s your view. It’s just never been an effective communication strategy between you and me generally.

>>> 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).

No, I am sure that a variety of board shapes can be set in plain text with these conventions, though the principle concern is classical chess notation.

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

I think it was a good expedient solution in lead type and that this proposal offers a robust parseable digital version of that solution, and I assert people will make use of that data structure.

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

I think the value in the data structures I have described is best retained as text. Anything else just seems it would be simply needlessly complex,

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

Well, it’s text, Asmus, so you can delete all but one line of a board if you want:

▕▨︁□︀▨︁□︀▨︁♘︀▨︁□︀▏

There. So… what are you talking about? It’s a text matrix. It’s like a kind of poem. 

▗▁▁▁▁▁▁▁▁▖
▕□︀▨︁□︀▨︁□︀▨︁♞︀▨︁▏
▕▨︁□︀▨︁□︀▨︁□︀▨︁□︀▏
▕□︀▨︁♔︀▨︁□︀▨︁□︀▨︁▏
▕▨︁□︀▨︁□︀▨︁♘︀▨︁□︀▏
▕□︀▨︁□︀▨︁♚︀▨︁□︀▨︁▏
▕▨︁□︀▨︁□︀▨︁□︀▨︁□︀▏
▕□︀▨︁□︀♙︁♛︀▨︁□︀▨︁▏
▕▨︁□︀♕︁□︀▨︁♖︀▨︁□︀▏
▝▔▔▔▔▔▔▔▔▘

It even looks like one. That’s a meaningful pattern. A kind of writing system. 

>> 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). 

Why? It’s text. It’s spelling. These structures are read. There’s no reason to encode two letter C’s because one is pronounced [k] and one [s]. 

> That way, you are guaranteed that (if the font supports the glyphs) you get what you want.

Then you’d have to have three, because there are three kinds of things that need to be in a single font: by itself, on a light square, and on a dark square. 

> With variation selectors for background color, you do not get what you want for the pieces.

I implemented it! It works!

> 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).

Your idea really isn’t better. 

> 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).

You want WHITE CHESS KNIGHT, and WHITE CHESS KNIGHT ON SQUARE, and use a VS that changes the colour of the square? That is less legible in plain text than my proposal. Not as good. Detrimental to the user indeed.

> 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).

I don’t agree that your model is better than mine. Interesting, but not better.

> 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 anyway).

Then you’re still stuck for a solution for non-em-square characters for inline text. 

Michael Everson