Website founded by
Milan Velimirović
in 2006
20:02 UTC
| |
MatPlus.Net  Forum Internet and Computing FEN format with fairy pieces in PDB |
| |
|
|
|
|
You can only view this page!
| | | (1) Posted by Harry Fougiaxis [Tuesday, Mar 16, 2021 08:58] | FEN format with fairy pieces in PDB
Themis Argirakopoulos is writing a tool for me that will create automatically the booklet for WCCT, so that I don't have to copy/paste manually hundreds of diagrams, composer names, solutions, etc.
One of the features he has in mind is for the program to provide the FEN strings of the diagrams in order to facilitate those who will eventually record the compositions in databases.
WinChloe, yacpdb (Olive) and PDB use different standards for the representation of fairy pieces. WinChloe and yacpdb standards are well documented and he can test his work. But for PDB, although he has understood what the standard is, he has no way to test it online.
Could someone who enters compositions into PDB advise how the following string shows:
QUOTE
q*1q*2q*3q4/-Q-*1Q-*2Q-*3Q4/8/8/8/8/8/8
Please provide a screenshot if possible.
| | | (2) Posted by Andrew Buchanan [Thursday, Apr 1, 2021 04:29] |
Hi Harry,
Sorry for not replying before, but I'm taking a break from most chess stuff at the moment in order to focus on some essential & urgent real life activities. I will be back :) However, this post needs a response.
The following link show 2 PDB problems with pieces all over the place:
QUOTE
https://pdb.dieschwalbe.de/search.jsp?expression=piece%3D%27rose%27+AND+PIECE%3D%27Grash%C3%BCpfer%27+AND+PIECE%3D%27Nachtreiter%27+and+not+stip%3D%27%29%27
You can see the field called FEN which gives an idea of the position. "-Q" gives e.g. neutral queen. "*2N" gives a white knight rotated by 2 quarters clockwise. However, this is an *output* field. The input form is currently different.
QUOTE
Example: wKe1 sDe8 nTLf8: white King e1, black Queen e8, neutral Rook rotated counter-clockwise f8
w: white, s: black, n: neutral
K: King, D: Queen, T: Rook, L: Bishop, S: knight, B: Pawn
L: rotated 90 degrees counter-clockwise, R: rotated 90 degrees clockwise; U: upside down
Special symbols: sY: character X; sQ: hole; wI, sI, nI: white, black, neutral imitator.
How to enter grid lines:
For each square it is possible to specify if there is a line at the left, right, top or bottom of the square. To indicate grid lines, first add the keyword "Lines: " at the end of the list of pieces. Then add a sequence of characters L (left), R (right), T (top), B (bottom), followed by a list of squares for which these lines should be drawn.
Example: to specify the grid lines for grid chess, use the following code:
Lines: Ba3a5a7c3c5c7e3e5e7g3g5g7h3h5h7 Rb1b2b4b6b8d1d2d4d6d8f1f2f4f6f8 RBb3b5b7d3d5d7f3f5f7
Gerd wrote to me:
QUOTE
Hi Andrew,
Thanks for the info. Someone else already showed me this post but I do not use the matplus forum so that I cannot answer myself.
But the answer would be easy: a few months ago I very quickly added the FEN notation on request of Thomas Brand. I don't mind about the specific FEN format for fairy pieces at all, so if there is any standard for this (maybe even an inofficial standard like WinChloe) then I would implement this standard in PDB too. The implementation right now is just a "quick and dirty" implementation which does not follow any standard.
And it is currently no possible to enter position by FEN+ in PDB so the specific question in the post cannot be answered.
Of course we are focused purely on the diagram, not the nature of the pieces. What figurines occupy which squares in which orientation. Also, what other items (letters, symbols, holes, gridlines etc) are visible where. And what is the default size of the board. The mapping of figurines to pieces is a separate activity.
| | | (3) Posted by Joost de Heer [Thursday, Apr 1, 2021 08:38] |
QUOTE
And what is the default size of the board.
That should be determined by the FEN(+), not by a default setting. k3/3K is a FEN for a 4x2 board. Only requirement should be that all lines in the FEN have an equal number of squares (possibly with a character, e.g. X, for squares that are not part of the board, to allow for irregular-shaped boards).
| | | (4) Posted by Harry Fougiaxis [Thursday, Apr 1, 2021 13:03] |
QUOTE
You can see the field called FEN which gives an idea of the position. "-Q" gives e.g. neutral queen. "*2N" gives a white knight rotated by 2 quarters clockwise. However, this is an *output* field. The input form is currently different.
Many thanks, Andrew, this is clear.
Yet, as this an output field only and the input form is currently different, it is practically of no use to someone who inputs problems to PDB.
I'm curious: when inputting (orthodox) positions to PDB, can't you simply paste the FEN string into the form? The current implementation seems counter-productive to me (but maybe I have not fully understood your message...)
| | | (5) Posted by Andrew Buchanan [Friday, Apr 2, 2021 05:04] |
Harry wrote:
QUOTE
Many thanks, Andrew, this is clear.
You are very welcome :D
QUOTE
Yet, as this an output field only and the input form is currently different, it is practically of no use to someone who inputs problems to PDB.
I'm curious: when inputting (orthodox) positions to PDB, can't you simply paste the FEN string into the form? The current implementation seems counter-productive to me (but maybe I have not fully understood your message...)
You have understood correctly. I suspect there are some undocumented features of PDB which allow for e.g. German FEN to be loaded, but when I tried experimenting with this yesterday by loading English FEN as a second diagram into a problem, it broke the problem animation in a way I could not undo! The animation is fragile and depends upon hidden, undocumented state relating diagram, stipulation and solution. (I like PDB a lot, but this is a frustrating weakness.)
I don't know how other folks load diagrams into PDB, but I wrote a humble spreadsheet for orthodox diagrams. Paste an English FEN into cell B1, and a German piecelist form appears in cell B2 :) I made it available a while back on https://www.dropbox.com/scl/fi/kcsmn1v8l3kwpjg22i7mb/fen2pdb.xlsx?dl=0
Gerd does seem to have more development time available than before, and I am pretty sure that if a FEN+ standard is specified, then he will support it. It would be great for example to have rebuses in PDB. Although the focus should be on the visual diagrams (figurines, letters etc) the authors of the standard should consider linkage to stipulation (especially twins), the mappings from figurines to fairy units, and the labelling of squares on non-standard boards (e.g. a9, i3, b0, z-77?, aa5? , etc).
Joost wrote:
QUOTE
(The size of the board) should be determined by the FEN(+), not by a default setting. k3/3K is a FEN for a 4x2 board. Only requirement should be that all lines in the FEN have an equal number of squares (possibly with a character, e.g. X, for squares that are not part of the board, to allow for irregular-shaped boards).
I completely agree. See for example Otto Janko's board generator: https://www.janko.at/Retros/d.php?ff=rnbqkbn4/1pppppp4/1R4p3p
| | | (6) Posted by Joost de Heer [Friday, Apr 2, 2021 15:23] |
I know Otto's diagram creator, since I created the first version of it (https://www.janko.at/Retros/d.htm).
| | | (7) Posted by Andrew Buchanan [Saturday, Apr 3, 2021 06:00] |
Joost wrote:
QUOTE
I know Otto's diagram creator, since I created the first version of it (https://www.janko.at/Retros/d.htm). Sorry Joost thanks for the correct attribution!
The FFEN spec looks great! Can this be the basis for the standard? Might want to make it open-ended somehow. E.g. half-knight-half-queen (a WinChloe figurine) might be represented e.g. by %71. Alternatively, may be simpler to stick to the FFEN proposal, and different databases may locally replace these with specific figurines depending on the identity of the unit.
What next, Harry? :)
| | | (8) Posted by Joost de Heer [Saturday, Apr 3, 2021 10:51] |
For half-pieces: %(ab)
e.g.: %(1S) for a piece where the left side is empty and the right side a white knight, or %(-*2qk) for a piece with the left side a 180 degrees rotated neutral queen and the right side a black king. Possibly allow combinations of 90 and 270 degrees rotated pieces as well to get pieces with a different upper and lower part.
[on second thought, a half neutral piece is just the same as either a white or a black piece (depending on which side you choose]
| | | (9) Posted by Dmitri Turevski [Saturday, Apr 3, 2021 12:23] |
QUOTE
Fairy FEN is an extension to the usual FEN notation.
This statement is very misleading. FEN represents the game state, it contains the information about the nature of the pieces. FFEN only describes the diagram.
"P" means "a white chess pawn" in FEN and "a symbol of white pawn (but not necessarily a chess pawn)" in FFEN.
The difference is subtle, but crucial. If anything, FFEN is not an extension to FEN.
edit: grammar
| | | (10) Posted by Andrew Buchanan [Saturday, Apr 3, 2021 16:42] |
QUOTE
QUOTE
Fairy FEN is an extension to the usual FEN notation.
This statement is very misleading. FEN represents the game state, it contains the information about the nature of the pieces. FFEN only describes the diagram.
"P" means "a white chess pawn" in FEN and "a symbol of white pawn (but not necessarily a chess pawn)" in FFEN.
The difference is subtle, but crucial. If anything, FFEN is not an extension to FEN.
Yes, I agree.
(1) Forsyth notation is the single string e.g. "rnbqkbnr/pp1ppppp/8/2p5/4P3/5N2/PPPP1PPP/RNBQKB1R".
(2) FEN is Edwards' extension to Forsyth notation, which adds state info, moves since zeroing of the 50 move rule, and the overall move number. e.g. "b KQkq - 1 2"
(3) For orthodox chess, the Forsyth diagram and the game diagram are identical, but with fairy chess this would not be the case.
(4) What Joost has produced is "Fairy Forsyth notation"
(5) This might be termed "Fforsyth", which non-Britons might startled to discover is an actual British surname! (Yes with the double f!)
| | | (11) Posted by Hauke Reddmann [Sunday, Apr 4, 2021 14:12] |
I don't know, I don't know...
Of course, extending FEN gives some downwards (upwards)
compability, but is there much use for that (and the
advantages nullified by saddling oneself with a system
that was never meant for problem chess)? Maybe a
completely new standard (XML basis?) would be preferrable.
Hauke, nagging as always
| | | (12) Posted by Andrew Buchanan [Monday, Apr 5, 2021 04:40] |
Hi Hauke,
I think there is already an XML format for problem description which although a noble endeavour didn't really taken off. These days XSD seems very much in decline in the IT world. YACPDB uses JSON; YAML being another choice. But that's really for describing the whole composition, what we're talking about here is extending the diagram picture, and I think a natural way to do this is through the very economical Fforsyth notation.
Worth mentioning maybe another German initiative to use a German piecelist in LaTeX format - I have to say I was shocked to hear this publishing format pushed as a data format, and I am yet to see the virtues. LaTeX has been hugely successful in its design space as authoring tool for academic papers, but as a result for our perspective it is complicated, verbose, with programming-oriented structure, requiring special Linux environments to be configured using a zoo of other supporting products, in order to read or edit the files. Academics already use LaTeX so they have already made the tech investment. However it's pretty uncommon in the the rest of world, and it's a pain to set up and maintain with the most recent versions of all the little software widgets that you need, particularly if you're based on a non-Linux operating system. And piecelist is clumsy as an interchange format compared to forsyth. There is also a horrible idea to embed abbreviations of tags in the LaTeX as well, rather than having a properly separated datamodel for metadata.
I've never heard of LaTeX being proposed as a data format for anything: JSON or YAML are much better as a representation for the overall problems. This LaTeX thing hasn't been proposed openly, rather it's being snuck through. PDF is fine as a primary source of an original published document, but then the secondary problem databases must be independent of this specific text form - want to be able add tags dynamically, slice/dice, define glossary entries etc. No problem if someone writes a programme to derive LaTeX from some other master format, but it shouldn't be the master format itself.
We can see that this whole discussion area could rapidly spiral into something huge. This is why I liked Harry's focused initiative on just the Fforsyth. Hope he can respond.
| | | (13) Posted by Thomas Brand [Tuesday, Apr 6, 2021 14:13] |
Hi Andrew,
Quite confusing for me what you say about LaTeX... Who propagated to use LaTeX as a (formal) description language for chess problems? Of course that were not an appropriate choice, there are much better description languages to do so.
On the other hand LaTeX is excellent choice for high quality publishing -- not only for mathematics (Don Knuth developed TeX for just this purpose), but also for chess problems. Examples are Die Schwalbe and feenschach, both completely typeset with LaTeX.
It's much simpler to do so than you decribe: You can run it "out of the box" with sinple installation not only with Linux operating system, but also on MacOS (more or less the Linux standard distribution with adapted tools for the Mac) and of course on Windows (excellent MikTeX distribution). Correct: The "LaTeX problem chess tools" are developed mainly in Germany (by Elmar Bartel, Stefan Höning and few others like me), but are "of course" very flexible -- for example one configuration command is enough to "translate" German abbrevs for pieces and colours and "turning information" to English or French or whatever you prefer.
And providing not only the diagram itself, but all the necessary information concerning source, awards, stipulation, twins, solution etc. is quite intuitive, I think.
If you want to use a problem found in PDB you have nothing to do but to download it just in LaTeX format. So simple...
| | | (14) Posted by Andrew Buchanan [Tuesday, Apr 6, 2021 18:39] |
Hi Thomas thanks for the reply.
TL;DR latex is adequate as a rather old-school publishing language dominant in the academic world, but it has no place supporting a canonical standard data format
QUOTE
Quite confusing for me what you say about LaTeX... Who propagated to use LaTeX as a (formal) description language for chess problems? Of course that were not an appropriate choice, there are much better description languages to do so.
Gerd suggested this. I wanted to get a way to automate input of compositions from another magazine. Problem is, LaTEX is now being used both as input and output to PDB, because Die Schwalbe and feenschach, so Gerd's proposal was that I or one of this other magazine's representatives should convert these other problems into latEx as the intermediate format. So I gave up.
QUOTE
It's much simpler to do so than you describe: You can run it "out of the box" with sinple installation not only with Linux operating system, but also on MacOS (more or less the Linux standard distribution with adapted tools for the Mac) and of course on Windows (excellent MikTeX distribution).
The "more or less" that you talk about, Thomas, is a killer. A couple of years ago I invested about a week of trying to get all the right files in place, hunting through social forums to find relatively non-obsolete discussions where grudging experts gave vague hints as to which versions of which supporting tools to acquire, etc, etc. Finally, I was able to run it hurray, and the program then irretrievably corrupted my document literally every 5 minutes. And I am relatively technical compared to some. The purpose of doing all this was at Hans Gruber's request to convert an MSWord document for input to feenschach. I never got that article rewritten or published. Bottom line, the lateX tooling is a superb barrier to entry. If one has other reasons to invest the effort in laTex, then of course it's fine, but it's not justifiable purely for chess problems.
LATEX seems reasonable as a private format between PDB and Die Schwalbe / feenschach, but can you please please offer something light and non-exclusionary as an I/O format with other magazines, thanks? JSON appears to be a great choice, and folk can edit the text with Olive easily.
Thanks,
Andrew
| | | (15) Posted by Thomas Brand [Wednesday, Apr 7, 2021 17:47] |
Dear Andrew,
Even though I fear we get "off topic" allow me some additional remarks on LaTeX for problem chess.
Well, I moved from Windows to MacOS last year, and I needed a running LaTeX environment. I installed MacTeX (the "Mac version of TeXlive", see http://www.tug.org/mactex/mactex-download.html), added some Postscript tools according to the manual, integrated my own LaTeX style files for feenschach -- and it worked immediately without any problems. Great!
I can't say anything about the production of other problem chess papers, but my impression is "Word plus any diagram painter" (What about the "FIDE Album editor"??) But I think is's much easier to transfer a problem stored in a database like PDB or in any data description format (by the way, is the WFCC project "problem.xml" -- http://problem-xml.sourceforge.net still alive?) to LaTeX than to Word format. The reason is that LaTeX allowes quite structured data.
Let' see an example of a problem written in LaTeX as we use it for Die Schwalbe or feenschach:
(The MatPlus.Net editor kills backslashes, so I use slashes / here; you have to replace them by backslashes to have correct LaTeX commands)
/begin{diagram}
/author{Kniest, Albert H.}
/source{Deutsche Märchenschachzeitung}
/year{1932}
/month{9}
/pieces{wKc8, wBb6, sKa8, sBa7}
/stipulation{H/#2*}
/solution{1.-- b7/#; 1.a6 b7+ 2.Ka7 b8=Q/#}
/Co+
/end{diagram}
That's quite self-explanatory, isn't it? By the way, you might just change to, say, English notation and then write /pieces{wKc8, wPb6, bKa8, bPa7} -- or just use /fen{k1K5/p7/1P6/8/8/8/8/8}.
That's so simple that even contributors not using LaTeX for themselves (should I call them "hardcore Word users"? ;-) ) deliver the diagrams for Die Schwalbe or feenschach in this format (just pure text files).
It's quite easy to generate LaTeX diagrams from databases or data description files, but the other direction also works: Gerd Wilts wrote a parser to import problems noted in LaTeX as described above to PDB. The reason that it works is that LaTeX was designed as a "structured logical markup language". Try this with Word files and .jpg or .png diagrams... Maybe that was the reason Gerd suggested to use LaTeX diagrams for PDB import? They are quite easy to generate and to parse, they are well-defined with a documented format. Of course not the ideal syntax for data definition, but maybe a pragmatic way until general descriptions are defined, agreed on and any parsers written...
| | | (16) Posted by Olaf Jenkner [Wednesday, Apr 7, 2021 18:39] |
Even Gustav has a menu item <Aufgabe> <Aufgabe speichern (Latex)> to get an output like shown above.
| | | (17) Posted by Andrew Buchanan [Friday, Apr 9, 2021 11:21] |
Hi Olaf, Thomas,
Thanks for your responses.
I know LaTeX *should* be straightforward to set up and use, but on my windows PC it wasn't. I have a suspicion that if it always was straightforward, there would be just a link to download and go, rather than pages saying how simple it is! :D Technology never seems to work when I am near it: I think I am too literal-minded. (This is one reason I prefer chess and mathematics to computing: knights and pi can be counted upon to behave themselves.)
I could have another go at installing it and running LaTeX, but I don't have much disk space left on my laptop (even after some massive purging recently). So I hope that the installation files & executables are small.
Maybe we don't need to run LaTeX at all if there's a clear definition of the format. What is the proposed canonical format itself? I could maybe write the translation from e.g. JSON to LaTeX (and vice versa) e.g. declaratively in Excel. And can then visualize in Olive using JSON to check that any diagram is right.
I do feel that any LaTeX initiative risks being PDB-centric. Why would YACPDB & WinChloe adherents be interested? Why should the editor of a magazine who currently has a feed to WinChloe have to learn LaTeX in order to supply problems to PDB? What's the best and fairest solution that allows us all to share problems maximally?
The final consideration I haven't mentioned before. I am very keen for the authoritative version of PDB to remain in PDB, and not lurking in various private LaTeX files. This includes critically the metadata and usage. It's so easy to copy and paste outside PDB, and this could proliferate bad practices. For example, a lot of proof games uploaded to PDB recently include "Excelsior, white" and "Excelsior, black". This is a waste of time, as all promotions are excelsior in a proof game. But also while in a d#, h# or s# it is very meaningful to distinguish between white and black excelsiors, this is really meaningless in a proof game. Also someone loves the keyword "under-promotion". This again is fine in d#, h# & s# but it is meaningless in PGs, and it makes it very hard to search for problems if only queen promotions are described as "promotions". There are many other examples, and really it requires work in PDB itself to systematize better the keywords, their parameters and usage.
This is quite a fun challenge if approached in the right spirit. I have a bunch of ideas on what can be done. Gerd has expressed general approval of this work, and I am happy to push forward with it, but it's not something that should be done alone. I think one should start with various orthodox genres, and then align with the great work being done in the fairy space by the gang at Julia's Fairies.
| | | (18) Posted by Thomas Brand [Tuesday, Apr 13, 2021 13:23] |
Well, Andrew, the problem chess LaTeX files were not programmed to support PDB: When PDB was created just these LaTeX components were used to typeset Die Schwalbe for a couple of years.
But since the LaTeX decription of a problem is much more "semantic-driven" compared with, say, any Word or .rtf description together with a picture of the diagram, it's not only easy to export LaTeX diagrams from PDB (or if the owners/programmers want, also from WinChloe, YACPDB, ...) but also quite easy to import theses problems into database systems -- not only for PDB but also for any "classic" data base system for chess problems.
Another advantage of LaTeX is that LaTeX itself and the decription files for chess problems can be used on all important operation systems -- and it's free (in the sense of both "free speech" and "free beer").
But I completely agree: Best were a "technically neutral" (and platform independent) description format like JSON and to use it as a central exchange platform: from database to datebase, from databse to typesetting or web pages, to and from problem editors -- and we should not forget the problem solving programs (Popeye just supports to generate output for the LaTeX format).
And indeed I were happy if the old initiative on a standard data format for chess problems (see the link in my last post here) could be rivived. That were a valuable task for the WFCC "Computer Matters" committee I think!
| |
No more posts |
MatPlus.Net Forum Internet and Computing FEN format with fairy pieces in PDB |
|
|
|
ISC 2024
