Comments/Ratings for a Single Item

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...

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 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.

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.

Testing new script.

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

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.

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.

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.

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.

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.

I love using the Alfaerie graphics: it is the piece-set with the greatest
variety. I note that otheers have modified some of your images, but kept
these new images in the Alfaerie style.

Has anyone ever made an image of a dog that is compatible with the Alfaerie
set? I am looking for a dog image for a game I am working on.

Nope!

He's right!

In miscelaneous there's a nightknight, but, once I asked about this and they told me that not all designs are real pieces.

Or, the nightknight is the knightrider, did you took a look at the piececlopedia?

Hugs.

M. Winther: 
| Why don't you download a font editor and complement the Tasc figurine 
| font with fairy pieces.
| /Mats

Would this be before or after I wrote the 7-men tablebase builder, a Shogi engine, back-ported WinBoard to Linux, fixed up Joker80 for the upcoming World Championhip of the unspeakable variant, and implemented on-the-fly tablebase generation in my normal-Chess engine Joker?

Problem is that I am aready severely overloaded with Chess-programming projects, so I try to avoid doing things that others might do as well or better as I could do them, or might even have done already. So that I can concentrate on those that people are waiting for most, and will not be done unless I do them.

'Tascbase (now discontinued) had a TrueType chess figurine font for diagrams, which is freeware I'm sure'

Yes, but it seems to contain only symbols for orthodox Chess pieces. There are many freely available fonts that do that, (e.g. see http://www.enpassant.dk/chess/fonteng.htm ), but virtually none those support fairy pieces. And the few that do usually support them as rotated ordinary symbols (upside-down Queen for Grasshopper etc.), which I positively hate.

There is George Tsavdaris' WinboardF font, but it is far more limited than Alfaerie. And there is the Superchess font that supports the orthodox plus 9 non-orthodox Chess pieces, but it has a licene agreement that allows it only to be used for Superchess. So besides the fact that it is even more limited than the WinboardF font, it cannot b distributed with WinBoard.

Tascbase (now discontinued) had a TrueType chess figurine font for diagrams, which is freeware I'm sure
http://home7.swipnet.se/~w-73784/TBASEDIA.TTF

There are also diverse chess true type fonts here:
http://www.chessvariants.com/d.font/fonts.html
/Mats

Is it possible to make the alfaerie set available as a true-type font? Then it would be automatically scalable to any size, rather than needing a separate set of bitmaps for every size.

They could also be used in the WinBoard GUI, in that case.

>> How do we propose graphics for inclusion in the set? I have been modifying some of the alfaerie graphics for some of the diagrams I have made on my computer, and I think they could be useful.

Please email them to me, and I will consider them for the next expansion set! Just click on my name and mail to the displayed email address. Thanks!