Comments/Ratings for a Single Item

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"

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

I got the correct name by piping "dnf list" into a file and searching it. I installed cairo-devel.x86_64 and librsvg2-devel.x86_64. It no longer complained about not finding cairo/cairo.h, but it still complained about not finding librsvg/rsvg.h. I found the correct directory and modified the #include lines appropriately, but then it complained that it cannot find glib-object.h. I made corrections in the glib include files to account for it being in the glib-2.0 directory, and I kept doing that for a while, but now I am at an impasse. It says it can't find glibconfig.h, and I can't find that include file in any of the glib-2.0 directories.

I found glibconfig.h in another directory and copied it over. I jumped through a bunch of hoops, and now it reports undefined references to several functions in cairo. It could be that render.c relies on an earlier version of cairo that had many functions no longer available in the new version.

I've uploaded an update to the SVG Alfaerie set here:

https://www.chessvariants.com/graphics.dir/alfaeriePNG/GS-2020-08-14.zip

This file contains everything - not just the new graphics.  There are about 35 new images and some updates.  The set is now up to 130 pieces!  And that's just one color and does not include the compound pieces that are generated by the rendering tool on this page.  We now have enough to switch over almost all the Alfaerie-based piece sets.

H.G., can you extract this to wherever your rendering engine is pulling from, overwriting any existing files with the same name?  No need to render the set to PNG, I have a script to do that.

File updated - there was a glitch with the Pegasus

The should be there now. Still t=newalfa.

[Edit] I probably missed that update. (Caching...)

Ah, yeah, the zip could be cached. Here is the fixed pegasus SVG:

https://www.chessvariants.com/graphics.dir/alfaeriePNG/wpegasus.svg

You really think that is an improvement over the old one? It looks more like a horse with unruly hair to me than as something with wings...

In the old one, the "wings" looked artificial and didn't really match - jagged right angles whereas the horse is smooth curves. But I see how this could look like the horse's mane rather than a wing. I have an idea how to make it more wing-like...

For XBoard I did it like this (second on fourth rank):

That's different than what I was thinking but I do like it and will give it a try.

Ok, new pegasus:

https://www.chessvariants.com/graphics.dir/alfaeriePNG/wpegasus.svg

Ok, new pegasus:

Much less ambiguous indeed! I uploaded it: