Check out Atomic Chess, our featured variant for November, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

LatestLater Reverse Order EarlierEarliest
Diagram Editor with scalable graphics. An easy-to-use tool for drawing boards and pieces of any size and color.[All Comments] [Add Comment or Rating]
💡📝H. G. Muller wrote on Thu, Dec 29, 2022 08:54 AM UTC:

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

Can you have a look at this ScriptAlias issue?


💡📝H. G. Muller wrote on Wed, Dec 28, 2022 06:12 PM UTC in reply to Fergus Duniho from 05:30 PM:

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 Duniho wrote on Wed, Dec 28, 2022 05:30 PM UTC in reply to H. G. Muller from 08:35 AM:

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.


🕸Fergus Duniho wrote on Wed, Dec 28, 2022 04:58 PM UTC in reply to H. G. Muller from 08:35 AM:

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

Okay, I just installed that.


💡📝H. G. Muller wrote on Wed, Dec 28, 2022 08:35 AM UTC in reply to Fergus Duniho from Tue Dec 27 09:36 PM:

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


🕸Fergus Duniho wrote on Tue, Dec 27, 2022 09:51 PM UTC in reply to H. G. Muller from Thu Dec 22 08:40 PM:

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 Tue, Dec 27, 2022 09:36 PM UTC in reply to H. G. Muller from 06:45 PM:

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

Okay, I installed gcc and cairo-devel.


💡📝H. G. Muller wrote on Tue, Dec 27, 2022 06:45 PM UTC:

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)?


💡📝H. G. Muller wrote on Thu, Dec 22, 2022 08:40 PM UTC in reply to H. G. Muller from Wed Oct 5 06:18 PM:

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


💡📝H. G. Muller wrote on Wed, Oct 5, 2022 06:18 PM UTC in reply to Fergus Duniho from Mon Aug 3 2020 10:52 PM:

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

 


💡📝H. G. Muller wrote on Thu, Jun 30, 2022 12:02 PM UTC:

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.

 


💡📝H. G. Muller wrote on Sat, Aug 15, 2020 09:00 AM UTC in reply to Greg Strong from 03:35 AM:

Ok, new pegasus:

Much less ambiguous indeed! I uploaded it:

 


Greg Strong wrote on Sat, Aug 15, 2020 03:35 AM UTC in reply to H. G. Muller from Fri Aug 14 06:39 PM:

Ok, new pegasus:

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


Greg Strong wrote on Fri, Aug 14, 2020 06:49 PM UTC in reply to H. G. Muller from 06:39 PM:

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


💡📝H. G. Muller wrote on Fri, Aug 14, 2020 06:39 PM UTC in reply to Greg Strong from 06:26 PM:

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


Greg Strong wrote on Fri, Aug 14, 2020 06:26 PM UTC in reply to H. G. Muller from 05:21 PM:

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


💡📝H. G. Muller wrote on Fri, Aug 14, 2020 05:21 PM UTC in reply to Greg Strong from 05:16 PM:

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


Greg Strong wrote on Fri, Aug 14, 2020 05:16 PM UTC in reply to H. G. Muller from 05:01 PM:

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

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


💡📝H. G. Muller wrote on Fri, Aug 14, 2020 05:01 PM UTC:

The should be there now. Still t=newalfa.

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


Greg Strong wrote on Fri, Aug 14, 2020 04:44 PM UTC:

File updated - there was a glitch with the Pegasus


Greg Strong wrote on Fri, Aug 14, 2020 04:14 PM UTC:

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.


🕸Fergus Duniho wrote on Mon, Aug 3, 2020 10:52 PM 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.


🕸Fergus Duniho wrote on Mon, Aug 3, 2020 08:04 PM UTC in reply to Greg Strong from 06:27 PM:

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.


Greg Strong wrote on Mon, Aug 3, 2020 06:27 PM UTC in reply to Fergus Duniho from 06:13 PM:

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


🕸Fergus Duniho wrote on Mon, Aug 3, 2020 06:13 PM UTC in reply to H. G. Muller from 06:06 PM:

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.


25 comments displayed

LatestLater Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.