Comments/Ratings for a Single Item

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:

It appears that access to the render engine is now permanently boken for everyone using a browser with standard security settings, because of the move to https. It therefore becomes important to migrate the engine to the CVP website. So can we revive this effort?

If I knew what Linux version exactly is powering the CVP server, I could install it myself in a VM, and have a try at compiling the rendering engine. I seem to recall it is some version of CentOS (although that is not mentioned in this discussion?).  The renderer is based on XBoard's board rendering code. I do think XBoard is available for CentOS, which means it must be possible to compile it, or figure out how it was patched by the maintainer to make it possible to compile it.

Fergus Duniho wrote on 2020-08-03 UTC

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.

OK, I installed Rocky Linux 8.6 on a VM, and had a go at it. It seems that Rocky Linux is riddled with errors: packages install files in places where the files themselves don't expect them to be. In the end I managed to compile the rendering engine to the point where it actually produced an executable a.out.

First I had to install the packages for the cairo and rsvg library:

sudo dnf makecache --refresh
sudo dnf -y install cairo-devel
sudo dnf -y install librsvg2-devel

To make gcc find the misplaced include files, I had to compile with the command

gcc -isystem /usr/include/glib-2.0 -isystem /usr/lib64/glib-2.0/include -isystem /usr/include/gdk-pixbuf-2.0 -isystem /usr/include/cairo fen2.c -lrsvg-2 -lcairo

Initially this still gave a linker error for the symbol g_error_free, which is supposed to be in glib. I could not find the corresponding library, though: it was not in the place where pkg-config said it was. As it did not seem an important function (according to the docs it just cleans up after a run-time error to prevent a memory leak, and we should not have errors anyway) I just defined a dummy for it in the program itself, which returns without doing anything. This satisfied the linker, and just left some innocently sounding warnings about use of deprecated things.

I uploaded this slightly modified source of the rendering engine to http://hgm.nubati.net/fen2.c . I suppose the procedure described above should be able to compile it on the CVP server. And that renaming it to something.cgi, and placing it in a CGI enabled directory of the server then should make it work on site.

Of course the directories with the SVG images that it will be rendering will have to be in the place where it expects it. (Set by the macro SVG_DIR in the source at line 61, which should contain a sub-directory for each piece set that is available. (On winboard.nl that would be alfaerie and xboard.)

@Fergus: Would it be a good idea to rewrite the SVG renderer (which now is a compiled C program) as a PHP script that invokes the Linux command rsvg to render the SVG piece at the requested size and possibly the requested color (all specified in the PHP arguments), and relay the output to the client? If rendering a FEN rather than a piece is requested it could return a HTML table with in each cell a URL to itself with the proper arguments to display the piece there.

The CkEditor deletes iframes in WYSIWYG mode, so these are not an option for embedding diagrams.

I am now trying to compile the renderer for the Editor with Scalable Graphics on ftp.chessvariants.com using ssh. But it looks like we don't even have a C compiler there ('gcc' as well as 'cc' evoke a "command not found" response).

So Fergus, could you install a C compiler, and the cairo-devel package (a graphics library)?

So Fergus, could you install a C compiler, and the cairo-devel package (a graphics library)?

Okay, I installed gcc and cairo-devel.

Would it be a good idea to rewrite the SVG renderer (which now is a compiled C program) as a PHP script that invokes the Linux command rsvg to render the SVG piece at the requested size and possibly the requested color (all specified in the PHP arguments), and relay the output to the client?

Converting an SVG to a PNG can be done in PHP without rsvg. The Diagram Designer does it by using Imagick to read the SVG file, convert it to PNG, and pass it to GD. If you just want a script to convert an SVG image to PNG, it could probably be done with just Imagick. The trick is to set the background color to a fully transparent color, which is any 8-digit hexadecimal number ending in 00.

Fergus Duniho wrote on 2022-12-27 UTC

Okay, I installed gcc and cairo-devel.

Thanks! I still run into a problem when I try to compile the C renderer: at

#include <librsvg-2.0/librsvg/rsvg.h>

it complains that the file cannot be found. Indeed there doesn't appear to be any librsvg sub-directory in /usr/include. While the binary run-time library librsvg.so is present in /usr/lib64. I did not run into this problem in my own installation of Rocky Linux.

Is there some additional rsvg package that we are still missing? (Like rsvg-devel?)

[Edit] The include files for gdk-pixbuf-2.0 were similarly missing. I was able to work around it by copying the /usr/include/librsvg-2.0 and /usr/include/gdk-pixbuf-2.0 subtrees from my own installation of Rocky Linux 8 to the folder where I compile (/home/chessvariants/hgm), and adapt the compilation command to look for the include files there. This still led to an error message from the linker, which was not able to find the rsvg-2 run-time library. It appears to be called librsvg-2.so.2 here, and the command probably choked on the final .2. Mentioning the library pathname explicitly, rather than using the -lrsvg-2 compiler flag, solved that problem, and finally gave me a binary. I don't understand how the system here can be so different from the installation I have on my PC.

There still is a problem left. I tried the binary in /index/fen2.cgi, but when I try to invoke it there from the web it just download the binary. So apparently it does not recognize the .cgi extension as special. Then I tried it in /cgi-bin, where I would expect CGI files to work. But it appears that files there are not accessible from the web at all (not even text files like piclist.txt). So it seems the server is somehow configured to block access to the cgi-bin directory. (Even though there are many files there, including PHP and CGI files.)

Is there some additional rsvg package that we are still missing? (Like rsvg-devel?)

Okay, I just installed that.

Then I tried it in /cgi-bin, where I would expect CGI files to work. But it appears that files there are not accessible from the web at all (not even text files like piclist.txt). So it seems the server is somehow configured to block access to the cgi-bin directory. (Even though there are many files there, including PHP and CGI files.)

We did generally stop using anything in that directory as we switched from using Perl scripts to using PHP scripts, but I'm not sure why it's not working. I changed the owner from chessvariants to apache, and I adjusted httpd.conf to get it to run .cgi files and restarted apache, but neither action has helped.

There must be something in the Apache .conf file that blocks access to this directory. I have no experience with the Apache server (on winboard.nl I use lighttpd), but some googling suggests this file should be called apache2.conf. I could not find it using an ssh connection, so I guess it is in a part of the file system that is not accessible to 'chessvariants' (/etc/webmin/apache/ ?).

Not that it is particularly important to place fen2.cgi in that folder. It would be fine anywhere, as long as CGI files are executed by the server there. This probably also requires some changes in the Apache config file, as by default CGI (or PHP for that matter) is switched off.

[Edit] Could also be /etc/httpd/conf/httpd.conf .

[Edit2] I see you already tried that...

[Edit3] There is a line

    ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"

in the httpd.conf. Could this be the problem? Perhaps the /var/www should also be changed to /home/chessvariants/public_html here? Or perhaps safer: the /var/www/cgi-bin directory could be made writable for user 'chessvariants', so we can all put files like fen2.cgi there, without running the risk to enabe all kinds of stuff that we no longer know what it does.

@Fergus - In case you missed the last edit of my previous comment:

Can you have a look at this ScriptAlias issue?

I think I've found a decent alternate use for this tool: creating new combination icons. A single icon, like the ones used to illustrate the article, download as .png files, so I've been able to build decent-looking versions of (for example) Malkia, Zorse, and Bowman. (And, well, this one.) There are still a few things that it can't do, but it's a far sight better than the manual cut-and-paste that I had been doing for that.

Batman thug is a good one!

H.G., is there any way to get this system (at least fen2.cgi) to work with my own SVGs, for my own use? Maybe by setting the graphics directory to the local drive where they're kept, or something like that?

The goal is to make PNG files from compounds of those SVGs.

The problem is that fen2.cgi is on the website winboard.nl, and can only point to drives that are local to that website.

fen2.cgi is a compiled C program, derived from XBoard, and we have so far not been able to compile it here. (And the Ubuntu binary does not work on Centos, probably because it cannot find the libraries where it expects them.) Perhaps I should have another go at it. If you have an Ubuntu system I could give you the source, and you might be able to run it there.

Hm, not really, no. I'm on Windows only. I don't have a C compiler either, though I might be able to find one.

If it helps, I think Fergus is about to upload my SVGs onto graphics.dir.

That doesn't help. It should be uploaded to the winboard.nl server. But perhaps I could do that.