Comments/Ratings for a Single Item

Use extension png instead of pgn.

Whoops!

Ok, now the images are found, but unfortunately whatever the diagram designer uses to render doesn't seem to support PNG correctly ...

It does seem to work in Game Courier though!

I renamed the folders from alfaerieSVG and alfaerieSVG35 to alfaeriePNG and alfaeriePNG35. Makes more sense ...

The Play-Test Applet now uses the on-site 35x35 PNG set. It defines a diagram with pieces, but it has a script to modify the diagram definition based on what images are actually available: it removes those for which the mentioned image is not present, and adds those for which it does find an image that was not yet used. The original definitions only serve to supply a move with the piece, or a name that differs from the image name. (E.g. 'charging knight' instead of 'forwardknightbackwardsprince'.) For the pieces it adds by itself it cannot predefine a move.

So the Applet now offers all pieces we made, and if we add more PNG files, it will automatically also offer those. When people ask for the HTML it will use the 50x50 set in those. Originally the reasons for that were that this set was available on-site (albeit non-anti-aliased), and that 35x35 was sort of an emergency method to fit the board next to the table (which was important for easy designing) in the Applet, but is really a bit too small for Alfaerie. For playing against a preconfigured diagram it is sufficient to have the table under the diagram, so a larger board is no problem.

Note that the knightwazir and knightferz are now duplicated as wazirknight and ferzknight; the latter two can probably be deleted.

I compared the code in drawdiagram.php to the code in Game Courier, and I found one difference that made a difference. By originally creating the board as a true color image, I got the backgrounds of the images to become transparent. However, the result is a JPG image, which looks fuzzier. I made a correction for that in the code.

While it is nice to have anti-aliased pieces, I do have a strong aversion to some shades of aquamarine, and the shade used for the black pieces feels uncomfortable to me. The original alfaerie pieces have more of a steel blue color, which I personally like better.

I compared the code in drawdiagram.php to the code in Game Courier, and I found one difference that made a difference. By originally creating the board as a true color image, I got the backgrounds of the images to become transparent. However, the result is a JPG image, which looks fuzzier. I made a correction for that in the code.

Excellent!  We are close to being able to start converting to true scalable anti-aliased images, which will be a *huge* improvement.  That said, as one who has spent over a dozen painstaking hours editing in Inkscape in the last two days, there is a lot of work to go ...

While it is nice to have anti-aliased pieces, I do have a strong aversion to some shades of aquamarine, and the shade used for the black pieces feels uncomfortable to me. The original alfaerie pieces have more of a steel blue color, which I personally like better.

100% agreed that the colors cannot change, but I think this was just an accident.  The color is supposed to be 5984bd but is instead 2984bd.  I think it was just a typo on H.G.'s part, since the 2 is just below the 5 on the numeric keypad.

Also, @H.G., if you have to re-render anyway, is there any reason the white can't be true white?  Not a big deal since you can't really tell, but if there is not a reason not to, I think the white should be ffffff for consistency.

New update, since we're re-rendering anyway:

https://www.chessvariants.com/public_html/graphics.dir/alfaeriePNG/GS-2020-07-27.zip

A tiny change or two, but mostly just adds a few new pieces: wequesrex, wkingrook, wkingbishop, and wforwardchancellorprince (the CwDA Colonel.)

First, I know that the Alfaerie set has multiple, different compositions of the same pieces. The kingrook, kingbishop, and equesrex may seem unnecesseary or redundant but there is a reason for my madness: these pieces are used in the Game Courier set group "Alfaerie 1: Historical & Compounds". This will complete that set, if:

Second, as you have made compounds for archbishop and chancellor, can you also make a compound of bishop + nightrider called "wcardinalrider" (and, of course, bcardinalrider)? With my new additions, this is the last piece needed to complete that set.

As for my overall plan, we could do two different approaches:

(1) make the anti-aliased stuff only for new material. The problem is that this site has a TON of material, most of which will not be updated.

(2) swap out existing stuff. I think we should do this, but I am willing to do it ONLY under strict guidelines. The replacement must be considered to be an improvement. Going to smooth, anti-aliased pieces is definitely an improvement... But I will only replace an existing Game Courier piece set if everything has been upgraded, and any changes (and there will be changes) are improvements, not just swapping things out because it is convenient.

Granted, what is an improvement is somewhat subjective. I am editing these pieces. For the most part, it is just fixing errors or making them a more precise representation of what the original author intended. But, in rare cases, I am making more radical changes. I justify this with the opinion that, while most alfaerie graphics are very good, there is a ton of material in this set and some of it is clearly of lower quality. I have changed the Lion and complete re-done the Tiger. I think these both should be considered "improvements" because of the quality of the original artwork. That said, if others disagree, please speak up. It is not my intention force any changes of style on anyone who has strong feelings and doesn't like the changes.

I say all of this because what I plan - changing existing Game Courier piece sets - will change existing graphics across-the-board. I think we really should do this to upgrade the look of the site to modern standards, but please do not think I take any global, retro-active change lightly. I will only do it under these guidelines, and will be upfront about what I am doing and open to objection. Even if a piece set is changed, if the change is not popular, it can always just be changed back. The new graphics are in a new location. The old graphics will not be deleted.

Ah, yes, I made a typo in the color. I was doing this on a remote machine (winboard.nl, a rented VPS) using ssh, so I couldn't see what I was doing. I can render the white pieces with w=#FFFFFF, no problem. I don't know how the raw SVG got to have #F9F9F9, but as long as they all use the same, it doesn't matter what they use. I didn't think it strange that it wasn't exactly white; the XBoard pieces use #FFFFCC, for instance, to give them a more ivory look.

I will include any compounds you request in the script for automatic rendering of the sets. But note that when you need an occasional new compound of existing pieces (i.e. for which the SVG is already on winboard.nl), you can easily get them yourself: just use an URL like

http://winboard.nl/my-cgi/fen2.cgi?t=newalfa&s=50&w=ffffff&p=wnightrider-wbishop

(or any other color you want) to make your browser display the compound:

and then save the image with the name you want.

You can also use the < _ > symbols for creating rotated pieces:

In the effort you, Greg, HG, are making to improve and order the piece images, it would be worthwhile to include the sissa. For many years I have been using the following icons designed by Matthew La Vallee that belong to the Alfaerie Many set:

Of course I am very grateful to him, however I keep thinking that it could be improved by designing an icon that most faithfully represents a Hindu man. As an example, please take a look at this link: https://iconscout.com/icon/turban-man-avatar-1847750.

Do you think that icon could be used? I have the doubt if one could get it for only 1 dollar. It seems very cheap.

Anyway, it would be something great if the sissa could be included in the piece set available in the Play-test applet. 

I posted a new update:

https://www.chessvariants.com/graphics.dir/alfaeriePNG/GS-2020-07-28.zip

Up to 93 images. These, plus some other compounds and rotates I can render myself, should be everything needed for these piece sets:

Alfaerie: Compounds & Upside Down Alfaerie 1: Historical & Compounds Alfaerie 2: Modern Faerie Pieces Alfaerie: Historical

I unpacked your latest zip file in the winboard.nl/graphics.dir/svg/newalfa folder, and rendered them all (I hope). This time with the correct color blue. They can be downoaded from http://winboard.nl/graphics.dir/svg/newalfa/alfaeriePNG35.tar.gz and http://winboard.nl/graphics.dir/svg/newalfa/alfaeriePNG50.tar.gz .

If I inadvertantly forgot to render one, you could get it directly from the renderer.

Fergus, I'm thinking the editors should have a flag we can set to suppress the "External image links detected!" warning for specific pages. While we generally don't want external images, the entire purpose of this page, for example, is to document and provide examples for an external image rendering engine. So external images here seem reasonable to me.

If you agree, I can add the sql flag and update the page logic.

I would prefer not to encourage the use of an external image rendering engine in IMG URLs on this site. If it can produce images that can be uploaded here, that is a different story, and this page could easily include uploaded copies of images created with his engine. But if that's not what it's for, and if H. G. wants to keep the rendering engine on his own site, it may be more appropriate to just have a link page to a page on his own website. A page on his own website would more easily have the same lifespan as the engine itself. If the engine were used on this site, images would break if anything happened to his site.

The page actually does produce a PNG image that can be uploaded to this website, when you hit the 'Draw' button. It also prints the URL for direct access to the renderer; this seemed useful for people that want to post a diagram on a site where they cannot upload stuff. I am not even sure that people who don't have contributed articles here can upload anything, e.g. for posting an image in a Comment.

The illustrations in the article can easily be replaced by uploaded images, and for some of those this would indeed be better. But it is very useful that a potential user can have some advance warning in the rare case that the rendering engine is off-line or unreachable, before he spends a lot of effort on composing a diagram that in the end will not render. Having an image on the page that directly samples the renderer seems a good way to do that. (Frankly, I do not know another way; browser security policies prevent probing another website in the background through JavaScript directly.)

Note that I do not want to keep the rendering engine on my website; I would be perfectly happy if it were on this website. It is just that there is no way for me to get it there, lacking ftp access.

The warning message is not really a technical problem; I can make it disappear through editing (the JavaScript embedded in) this page. So there is no need to build any special provision in the database for that. It is purely a policy matter whether it should be there and what it should say. When I first submitted the article I had in fact replaced it with a message explaining the purpose of the off-site images for the editors, but an editor commented that out of the script. That was fine with me; it meant he had seen it. For this occasion I temporarily re-instated the alternate warning.

Note that I do not want to keep the rendering engine on my website; I would be perfectly happy if it were on this website. It is just that there is no way for me to get it there, lacking ftp access.

If you can upload or email a zip file of your code, I'll look into installing it. From the .cgi extension, I'm guessing it's in Perl, but I don't think that extension is exclusive to Perl like .pl is.

It is a compiled C program. I posted the source at winboard.nl/render.c. I also posted the executable (winboard.nl/render). I am not sure whether that can be transferred to another machine; for Linux it is usually safer to recompile. The program uses the 'cairo' library for drawing, and librsvg for importing the SVG images.

It might not be completely trivial to get it running here.

I haven't compiled a C program in a while. It looks like I first need to install a C compiler. Will GCC do? And how should I make sure I have these libraries installed?

GCC should certainly do it.

I think our server is running CentOS, so we should be able to install the libraries with the dnf command.

I made it on an old Ubuntu Linux (10.04), but the drawing code was taken from XBoard, which is used on many different Linux distros. So I suppose it should work on CentOS without problems. I did indeed use gcc to compile it. I suppose libcairo and librsvg are available from the distro repositories. For compiling you would also need the developer (-dev) packages for those (to have the #include files).

I installed gcc and dnf. It looks like dnf is just an update of yum. So, maybe yum would do as well. Yum says that cairo and librsvg2 are already installed. Nothing came up when I tried to list librsvg by itself.

I placed a copy of the C file in /cgi-bin/ with a modified value for SVG_DIR.

I tried to access https://www.chessvariants.com/cgi-bin/render (or render.cgi), but it gives me a 404 error.

I have not compiled it. I have only put the .c file there. I did just try to compile it, but it complained that I need <cairo/cairo.h>. I probably need the other one too, but compilers will stop with the first error.

See if there's a dnf/yum package for cairo-dev or something like that. On Ubuntu it is called "libcairo2-dev"