Comments/Ratings for a Single Item

I'm now beginning to see why David chose to use blue for the black pieces. I have been looking at the site with my new Likebook Mars, which is an e-ink Android device, and the reds appear very dark or even black, which obscures the detail of the red pieces I've made. But the blue Alfaerie pieces look just fine on its e-ink screen. This is relevant, because David is color-blind, and if I recall correctly, he has difficulty seeing red. I'm going to have to recolor some things so that they are still visible in e-ink and to color-blind people.

It would be really awesome if you could customize the piece colors the way you can with ChessV, but I realize that's a tall ask.

That reminds me, I need to get back to my project of porting the Abstract and Alfaerie sets to SVG vector graphics.  I'm almost done with the eight primary Capablanca pieces for both.

Pieces could be recolored when rendering the board as a single image, and in table- or CSS-rendered diagrams, script URLs in place of image files. For simplicity's sake, it might be best to do it all through a script that shows individual pieces in specific colors. This is assuming that GD can load an image from a PHP script. But this should be done only for solid-color pieces. So, it would be best to do it with new sets or to adapt some pre-existing sets to handle changes in color.

I would suggest lifting the graphics from ChessV.  It has a large set of images from both the Abstract and Alfaerie sets with unified, consisting naming and a consistent format.  I've spent quite a bit of time over the years getting them organized and unified.

I am a bit skeptical about whether making piece colors fully customizable is really worth the effort, compared to just preparing a handful of sets of different colors as normal gif, jpeg or png images. It seems far more useful to have customizable size. But I suppose the technical solution would be much the same, along the lines Fergus suggests: rather than linking to image files we could link to a PHP or CGI program to render the pieces with the desired size and color, e.g. from SVG prototypes, and supply those to the client.

I assume most browser will also cache data fetched from CGI scripts as long as the same arguments get passed to the script; for this reason I always append a dummy "&t=<TIMESTAMP> when requesting 'volatile' data, e.g. when polling whether another party has appended a new move to a game to be fetched. So once a client has used the renderer to obtain a set of pieces of his preferred size and color, he will cache the resulting images, and as long as he sticks to that size, color and pieces he used before, he will cause no further load on the server-side renderer.

I guess it would not even require any adaptations of my Interactive Diagram script to use such a 'dynamic' piece set; the user can just include the name of the script file and the fixed arguments he wants for his design as part of the pathname of the 'graphicsDir' parameter of the diagram, e.g.

graphicsDir=/membergraphics/piece.cgi?c=#8000FF&s=40&t=

where 'c' and 's' are the color and size arguments, and t would specify the piece type in a format that normally is used for the image filename (but with an empty string for the graphicsType extension).

I don't think it would be necessary to limit ourselves to just specifying one color. In WinBoard rendering pieces from true-type chess fonts (the nearest thing Windows supported to SVG), you can independently specify foreground and background colors for both the white and black pieces. It turns out that pieces that are not purely black or very dark gray (like #202020) always need a black outline, or they will look extremely ugly (even when very dark blue). WinBoard contains a special set of ('solid') images for the black pieces, where the 'outline' basically fills the entire glyph, exept for some line details in it (such as the cross on the Bishop). But for people that wanted to change the black piece color, I had to provide an extra option that forced using the 'outline' images normally only used for the white pieces also for black, and have the /blackPieceColor option then apply to the filling of this outline, rather than to the outline itself (as was done for the 'solid' pieces. With the font rendering the outline and filling color can be specified separately, and even then the filling color is subject to a shading gradient to create a 3D illiusion.

SVG images are normal text strings; even if the rendering routine would not supply an option to replace certain colors by certain others, we should be able to write a small routine that locates the color spec inside the SVG file, and substitute it by the color spec for the desired color, before we pass the string to the renderer.

Testing new script.

I was finally able to preserve transparency when resizing. This script works with bitmap images, not with SVG images.

Nice. Would it be difficult to also make it work for SVG? The result would be much smoother, as SVG rendering usually also involves anti-aliasing. I know there is a command rsvg under Linux, which can render SVG files to various bitmap formats. (I usually prefer PNG.) Would it be possible to call such a command from a PHP script, and then send the output file as answer to the request?

All XBoard pieces are available as SVG, and Greg is already working on converting Alfaerie to SVG.

I have never worked with SVG files, and the GD library, which is what this script uses, does not support them. Plus, I don't yet have any SVG files to work with. Once I get some, I could look into how they could be used.

The GD functions are not accepting script URLs as valid image resources. So, I'll have to handle the recoloring of pieces differently for the GIF, PNG, and JPG rendering methods. I'm thinking I'll add two new parameters. I was going to call them wcolor and bcolor, but bcolor is already used for the border color. Maybe color1 and color2. If left blank, the default color would be used. If non-empty, it would override the color for sets using solid color pieces. For the table and CSS rendering methods, it would convert the image URLs in $pieces to the scripted URLs, and for the GIF, JPG, and PNG methods, it would change the color as it worked with the images.

I have the XBoard SVG piece images on my website, at http://hgm.nubati.net/svg/ . It should be relatively easy for me to copy-paste the XBoard code for rendering these pieces to a bitmap (written in plain C) into a CGI program that then outputs it as PGN of a specified size. But I got stuck doing that. I have access to only 3 Linux machines: the one I use for development, running in VirtualBox, which has no web-server running on it. Then I have some webspace I borrow from a former collaborator on XBoard, where I have the XBoard development website on a Linux machine, including my git source repository. I have several CGI programs running there, but I cannot run any SVG stuff there, as librsvg-2 doesn't seem to be installed, and I have no root permission I can use there to install anything. Finally I have my own web server running on a VPS I rent (winboard.nl). I did not manage to run any new CGI program there (even those which tested OK on the XBoard website). Behavior there seems quite sick: I have gitweb.cgi running there to put a mirror of my git repository online, at winboard.nl/cgi-bin/gitweb.cgi . This works fine, despite the fact that gitweb.cgi DOES NOT EXIST, and the cgi-bin directory is entirely empty! If I place other CGI programs in the cgi-bin directory, or even just png images, and try to access these through the web server (lighttpd) with an URL, GitWeb starts running instead, browsing my repository?!? If I place CGI programs in another place in the www tree, they do not seem to run correctly, and produce a blank page when accessed through their URL. I wonder if the machine is somehow hacked.

So I am stuck. I can write a CGI program to produce scaled (or colored) pieces, but I cannot run it where I have a web server, and cannot test it where I can compile it...

If you have your own VPS, what's stopping you from installing the software you need on it?

Nothing. The problem on the VPS is not missing software, but that CGI programs don't seem to work there at all, and cause GitWeb to run instead, for reasons I do not understand. (e.g. try http://winboard.nl/cgi-bin/gitweb.cgi and http://winboard.nl/cgi-bin/ and http://winboard.nl/cgi-bin/gobbledegook.nonsense , and they all do the same thing).

Do you have an .htaccess file in your cgi-bin or home folder? It might be set up to rewrite or redirect any URL to cgi-bin to a particular script.

I'm guessing that GitWeb was supposed to be installed to something like /cgi-bin/gitweb/ instead of to /cgi-bin/ itself, because it appears to be designed to monopolize the directory name as though it were a script name. I would recommend uninstalling it and reinstalling it to its own directory.

Progress: as I expected the webserver (lighttpd) is configured by default to only execute CGI programs when they are in the cgi-bin directory. But it was also configured to alias any URL that contained this directory name to /usr/bin/perl , which is apparently where gitweb lives. This must have happened as part of installing gitweb (which in some earlier version must have been a true .cgi file, but now apparently is something entirely different). So anything inside the real cgi-bin directory was inaccessible, web-access to the directory being diverted to gitweb.

I now configured lighttpd also to allow cgi execution in a new directory 'my-cgi', and a little test program that prints Content-type: text/html plus 'Hello World!' as HTML header, placed in this directory, shows the properly formatted message. So it seems I am back in business, and can now use compiled C programs as CGI, on a machine where I can be root.

test 2: printing "Content-type: image/png" and then copying an existing PGN file to stdout shows that image in the browser for the CGI's URL.

test3: I managed to instal libcairo, the (raster-image) drawing library used by XBoard. (Alas non-trivial, because the Ubuntu running on my VPS was no longer supported, and I had to reconfigure apt-get to be able to install the package from another source.) I could compile a test program that reads a PNG image into a memory bitmap, and then writes that memory bitmap to stdout as PNG. And running it as CGI indeed displays the image in the browser.

test4: This one drove me to despair again. I managed to install librsvg-2, and find the required include and library arguments for compiling. The rsvg functions that were supposed to give me ponters to 'RsvgHandles' kept returning NULL, however, but did not return an error either. I finally solved it by first calling rsvg_init(), a function that according to the librsvg manual does nothing, is deprecated, and should not be used in new code. Apparently my librsvg is so much older than the online manual, that the info in it does not apply. Strange thing is that XBoard works without calling rsvg_init(), even when I compile it for the same Ubuntu version. But it makes calls to libcairo before it invokes librsvg, and perhaps the (equally obsolete) libcairo calls rsvg_init() without me knowing it. Anyway, it works now: the CGI program reads the requested SVG image file into a buffer, and then uses rsvg_handle_new_from_data to convert this data (which at that point was still the exact file contents) to an RsvgHandle. (I took that detour, because the direct route through rsvg_handle_new_from_file() with which I started also gave me errorless NULL pointers, and I wanted to make sure that it wasn't due to inability to access the file. But I had planned to do it through the detour anyway, to get an opportunity to change the colors before rendering.)

test5: I now implemented color changing by replacing all occurences of "#ffffcc" (the default filling color of the XBoard white pieces) by the c=... CGI argument. For now, only hexadecimal RGB codes are accepted as values; it is read as an int through a "%x" format.

Mission accomplished! You can right-click on the images to see how the URL for them looks (under 'image info'). Apart from the c (color), s (size) and p (name of the SVG file without extension) there is a d (directory) argument that can be used to select another piece set.

For getting this I set the graphicsType to empty, graphicsDir to point to the CGI file with the size argument and c=, and made the whitePrefix and blackPrefix the desired color codes and p=White (so both sides use the 'white' outline pieces, but with different filling color.

OK, it seems I messed up when copy-pasting the JavaScript code for the Interactive Diagram in the comment below (as it was not possible to update it in /membergraphics, and links to the updated version on my website were mutilated), and somehow destoyed the closing </script> tag, so that the entire sequel of the page has disappeared. Including the link that would have allowed me to edit it to undo this mess. When I had it as preview everything was perfectly fine, so I don't understand how this could have happened.

Sorry about this. I guess an editor will have to directly access the database to restore the </script> tag.

[Edit] I was able to recover after all. Just lost my posting. What happened was that the JavaScript was too long, and the submission software clipped my comment, including the </script> tag.So that the entire remainder of the Comments page became invisible, as the browser thought it was all JavaScript. I could access it by looking from the page source what the 'Edit' link does, and then guessing the comment ID untill I guessed right. Unfortunately I lost the entire comment because of this, as it was in the clipped section.

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:

I had an idea for a system to indicate pieces in FEN strings with 'dressed letters', which should not be too difficult to remember. No matter how ingenious a system is, in the end there are just too many pieces in the Alfaerie set to avoid that you have to identify some of those by the root name of their image file. The system used in Fairy-FEN, which writes this name between parentheses, using capitalization of the first leter to indicate the color, seems the obvious way to do this. This system is already completely universal. So the system of 1-letter (possibly plus one punctuation character) codes serves only to allow a more efficient encoding.

My idea was to use punctuation to indicate various enhancements of the piece indicated by the letter. Of course we wantthe orthodox Chess pieces to be indicated by their normal 1-letter ID: P, N, B, R, Q or K. But e.g. a tilde '~' suffix could be used to indicate the piece indicated by the preceding letter is knighted (the tilde looks somewhat like the letter N, hence it seems the obvious choice for indicating this). So Archbishop, Chancellor and Amazon would be B~, R~ and Q~. By also assigning single-letter codes for Wazir (W), Ferz (F), Alfil (E, as we usually depict this as  an Elephant, and for this purpose it seems more important to represent how the symbol looks than representing its move), and Dababba (D), we then also cover all 'augmented Knights', W~, F~, E~ and D~.

In a similar spirit, we could use a (single) quote for a wazired piece, and a back-quote for a ferzed piece (because the backquote typically is more slanted in most fonts). The Crowned Rook and Bishop then become R` and B'. Modern Elephant would be E` (ferfil), Phoenix (WA) would be E', Kirin (FD) would be D` and Woody Rook D'. If we assign the letter A to the Alibaba, we have A' for the Omega Champion, A` for the CwDA Fad, and A~ for the Squirrel (NAD).

A '^' could be used to indicate a rider, e.g. N^ is Nightrider, D^ is Dababba-rider. P^ could be the Shogi Lance, which is the slider version of the (Shogi) Pawn. The basic obliques would also have their own letters, N (Knight), Z (Zebra) and C (Camel). That makes the Omega Wizard C`. This relatively simple set of conventions already covers a very large fraction of the pieces one typically encounters in variants. A colon could be used to indicate Pao-like hopping: 'R:' for the Xiangqi Cannon, 'B:' for the Vao, etc. Perhaps the G and S should be reserved for Gold and Silver general.

Remaining letters could be used as abbriviations for animal names. E.g. L = Lion, T = Tiger, H = Hawk, U = Unicorn.

I now also put some SVG files for the Chess Alpha font (from XBoard's alternate piece sets) on my website. These can be used in the CGI renderer by adding the argument t=alpha . (For 'type'; I changed that from d= because the latter now is indicating the dark square shade used with FENs.) These are the glyphs from which Alfaerie is derived, but there are no fairy pieces amongst those.

This absence is ameliorated by a new feature in the renderer, though: it now treats hyphens in the FEN as indicating that the pieces left and right of it should be put on the same square. So X-Y means a Y behind an X. The pieces are then both vertically shrunk a bit, the one in the background aligned with the top of the square to not totally eclips it. This allows 'on-the-fly synthesis' of Alfaerie-style cut-and-paste pieces, e.g. N-Q for Amazon:

or

Some SVG images for Alfaerie:

And some more:

And again some more:

And I leave it for now at these:

Wow, that's some pretty impressive progress.  You made all those?

Yes, I did. Still busy completing the last row, but I get a bit tired of it now.

Well that is very impressive.  You've got way more done that I have so you must have a pretty good technique.  Are you using Inkscape, loading the bitmap, and tracing over it?

I'll do some more pieces in the Abstract set and upload what I've completed.  (The Abstract set is easier to do anyway since it is so geometric.)

Then I need to get ChessV supporting vector graphics, which is why I started making them.