Re: Proposal to add standardized variation sequences for chess notation

On 5 Apr 2017, at 11:05, Asmus Freytag <asmusf_at_ix.netcom.com> wrote:

> Actually, I'm now leaning towards a preference for any scheme that does not use VS, but relies on ligatures.

This would make editing the text more difficult and would yield less legible results in environments where the ligatures aren’t supported.

> Such a scheme would need
> a) no matching spacing for the bare pieces (the ligature with the empty square would result in the correct spacing)

Well, that’s no different at all than my scheme except you ligate pawn and empty square as I ligate pawn and VS. But your scheme has the disadvantage of being similar to the emoji sequences, which would appear to require ZWJ between the pawn and the empty square. That means you have more characters to deal with and in fact you end up with variable length chessboard lines, which yields the worst possible results in fallback.

> b) no pieces with built-in dark background (pieces simply ligate with the empty "black" square).

Or as I have it, pawn and VS.

>> Now, what happens to the two scheme if rendered with yellow text ('foreground') on a blue background?
>
> According to Michael, the effect should be that of lead typography.

Well that’s not really what I was talking about with lead typography. (That’s more the ASCII-art argument.)

> This would mean that the entire ligature has the same ink color, and all parts that are not "ink" are the background color (paper color).

Yes, paper and ink. As in http://evertype.com/standards/unicode-list/looking-glass-yellow-blue.png

> Unlike lead typography, the ink can be perfectly opaque, allowing a lighter color to show on a dark background. Or the opacity of the foreground can be selected to an intermediate level, allowing the ink to look greenish in your example.

In any case this is a red herring.

> (The results with a VS based system are not really different, because I imagine, the actual glyph repertoire is identical in all alternatives discussed so far - relying solely on ligatures has the benefit of not involving the UTC at all, therefore it could be implemented today without delay).

Except that ligatures is problematic for actually making chessboards. The risk that fallback becomes illegible is hugely magnified. Here:

http://evertype.com/standards/unicode-list/ligation-vs-VS.png

On the left we have your scheme, shown in a mono-width font; on the right, mine. Ligation, in fallback will lead to variable-width text on each of the eight lines, which will differ depending on how many chess pieces or none appear. With the VS solution, *all* chess data will have the same number of characters in each line. In fact, parsers could identify misplaced VS characters (VS1 where VS2 would have to be there) or missing ones. Moreover, reverse-parsers (or whatever the term could be) could take narrative text data as in:

http://evertype.com/standards/unicode-list/34-variantim.png

and generate tables from it (if the narrative data were well-formed).

All the UTC has to do is approve the set of VS sequences as a *standardized* way of doing this. Ad-hoc ligation is just going to lead to continued chaos, as well as continued dependence on differently-encoded ASCII fonts.

Michael Everson
Received on Wed Apr 05 2017 - 11:03:11 CDT