H. G. Muller wrote on Wed, Oct 10, 2018 12:07 PM UTC:
While I was at it, I thought I might as well equip the renderer with a FEN parser, so that it also can generate whole-board images. Presence of an f=<FEN> CGI argument triggers this mode. E.g.
This needs a few more (optional) parameters to control, as white and black pieces are now present at the same time, and we also have to deal with the square shades. So one can specify four colors, through parameters 'w', 'b' (white and black piece filling colors) and 'l', 'd' (light and dark square shades). These all have suitable defaults. The 's' argument indicates size, as when rendering a single piece.
There of course is the problem here of how to assign letters to unorthodox piece types (and how to then translate those in the renderer to SVG filenames). For now I used the XBoard 'canonical' assignment, which was in use when XBoard still only supported 22 piece types, and I still had the illusion that you could get away with an assignement that would be the same for all variants. All 26 letters mean something, but in the end 26 will of course not nearly be enough. Latest XBoard supports 66 piece types, and to support variants that need more than 26 types at once it also allows 'dressed letters' (suffixed by punctuation characters, like c' or L!). This is definitely an area that still requires some thinking.
The assumed SVG naming now is the same as that used by XBoard (like WhiteKing.svg, BlackCamel.svg), which is also not ideal. Alfaerie naming conventions are in general better. But what I consider most important is to have consisten naming through all piece sets.
While I was at it, I thought I might as well equip the renderer with a FEN parser, so that it also can generate whole-board images. Presence of an f=<FEN> CGI argument triggers this mode. E.g.
This needs a few more (optional) parameters to control, as white and black pieces are now present at the same time, and we also have to deal with the square shades. So one can specify four colors, through parameters 'w', 'b' (white and black piece filling colors) and 'l', 'd' (light and dark square shades). These all have suitable defaults. The 's' argument indicates size, as when rendering a single piece.
There of course is the problem here of how to assign letters to unorthodox piece types (and how to then translate those in the renderer to SVG filenames). For now I used the XBoard 'canonical' assignment, which was in use when XBoard still only supported 22 piece types, and I still had the illusion that you could get away with an assignement that would be the same for all variants. All 26 letters mean something, but in the end 26 will of course not nearly be enough. Latest XBoard supports 66 piece types, and to support variants that need more than 26 types at once it also allows 'dressed letters' (suffixed by punctuation characters, like c' or L!). This is definitely an area that still requires some thinking.
The assumed SVG naming now is the same as that used by XBoard (like WhiteKing.svg, BlackCamel.svg), which is also not ideal. Alfaerie naming conventions are in general better. But what I consider most important is to have consisten naming through all piece sets.
One example that does not use default settings
http://winboard.nl/my-cgi/fen.cgi?f=tyexkeyt/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR&w=c0ffc0&b=8000C0&l=ffe8c0&d=D09080&s=55
gives
Rendering single pieces is still possible with this same CGI program: