On 2 Apr 2017, at 19:43, Asmus Freytag <asm...@ix.netcom.com> 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. > 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. > 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. Michael Everson
