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