On 1 Apr 2017, at 21:57, Christoph Päper <[email protected]> wrote:
> □ U+25A1 and, especially, ▨ U+25A8 for empty fields on a board make no sense. Not so. Think about the data. > U+25A8 always shows as diagonals from the lower left to the upper right (much > like a forward slash /). Black fields are often hatched this way, but could > also be shown with a solid fill ■ U+25A0, a reverse diagonal fill ▧ U+25A7, a > diamond > pattern (diagonal crosshatch) ▩ U+25A9, a square pattern (orthogonal > crosshatch) ▦ U+25A6, a vertical pattern ▥ U+25A5 or a horizontal pattern ▤ > U+25A4. The *conventional* glyph used in international chess diagrams uses the character I chose (with the /// diagonals). That’s the character which should be used to represent chess boards in plain text. Nothing prevents a font designer from choosing to render it (in a chess font supporting this protocol) with a vertical pattern, or with dots, or with as black, or whatever. Please distinguish characters from glyphs. > I suggest you adopt a space character instead, e.g. U+2003 Em Space or U+2001 > Em Quad. No. Absolutely not. Spaces have a variety of properties. Spaces separate things, but are not things themselves. The white square on a chessbord is not a separating nothingness. It’s a white square. Even when a chessboard is made of green and brown marble, one is still a white square, and one a black square. Even when chess pieces are made of yellow and red plastic, one is still a white piece and one is still a black piece. In this proposal the squares and the pieces are all graphic symbols all with the So (Symbol Other) property. Using space characters you suggest would be a mistake; they have the Za (Space Separator) property. > □ U+25A1, ▢ U+25A2 or ⬚ U+2B1A would also work if you wanted a minimal amount > of ink but not none. Christoph, I’ve already implemented this and it works well and robustly. Glyphs could be altered in a variety of ways, but the point is that this is the kind of simple higher level protocol which will solve a long-standing problem simply and easily, and allow the parsing of chess problems as text for analysis, and allow the generation of chess problem images from other descriptions of chess problems and solutions. > 25A1 FE00; White chessboard square; # WHITE SQUARE > 25A1 FE01; Black chessboard square; # WHITE SQUARE > > 25A2 FE00; White chessboard square; # WHITE SQUARE WITH ROUNDED CORNERS > 25A2 FE01; Black chessboard square; # WHITE SQUARE WITH ROUNDED CORNERS > > 2B1A FE00; White chessboard square; # DOTTED SQUARE > 2B1A FE01; Black chessboard square; # DOTTED SQUARE Again there’s no need to use a variety of characters to represent the chess squares. If you want to draw them in your font with a certain non-/// fill, you could. But that is cosmetic and irrelevant. The point is to have the underlying board data as plain text, and that means just using the chess pieces and conventional white and black squares. Remember, the /// is drawn around the chess pieces with the FE01 but for those there is no 25A8 used. Please examine the non-OpenType plain text representations in Figure. They’re even readable by humans. > You should also evaluate a different approach altogether: > > 20DE FE00; Combining white chessboard square; # COMBINING ENCLOSING SQUARE > 20DE FE01; Combining black chessboard square; # COMBINING ENCLOSING SQUARE > > 20DE FE00; Combining white background; # COMBINING ENCLOSING SQUARE > 20DE FE01; Combining black background; # COMBINING ENCLOSING SQUARE > > Although one would need to combine it with a space character as a base for > empty fields, That’s not remotely tempting. It would offer no advantage and would needlessly complicate the system. > this would require only two new entries in StandardizedVariants.txt and be > more flexible regarding alternate (Fairy Chess) game pieces – including > emojis. This proposal has nothing to do with emojis. This is a plain-text protocol for the representation of chessboard data in a parseable fashion. Should fairy chess characters be added to the standard, some additional entries would be added to StandardizedVariants.txt, yes. This is a finite set, however, and this should not be problematic to anybody. It’s certainly simpler than a number of other recommended sequences which have been added to the standard for other purposes. I thank you, sincerely, for your interest in this proposal; it has been considered and tested and it works better than what you have proposed, however. I could prepare additional fonts using dotted or black glyphs for the black squares as you suggest, but the strength of this proposal is that you could achieve those glyphs by simply switching from one font to another, with the underlying chess data preserved. Michael Everson
