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:

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.

That's actually what I had in mind. :)

OK, I managed to grab a zip file from CVP, and unpacked it on http://winboard.nl/graphics.dir/svg/greenwade/ . As a result you can now render them with http://winboard.nl/my-cgi/fen2.cgi by including &t=greenwade in the query string.

My thanks! :)

Can you have a look at this ScriptAlias issue?

Okay, I have made the proper corrections, and /cgi-bin/fen2.cgi is now giving me a 500 error instead of a 402 error. Maybe it requires a query string.

Well, it required the environment variable "REQUEST_METHOD" to be set; it did a string compare on it, and this crashed on a NULL pointer, which was what getenv() returned when the requested variable did not exist. It was resistent against the query string not existing, (replacing it by an empty string), and the program was written such that in this case it showed a King image.

I modified it to assume the GET method by default. This made things work: when I run public_html/cgi-bin/fen2.cgi from the command line of PuTTy, it responds with "Content-type: image/png", followed by a lot of non-ascii, which I suppose is the png image.

Accessed through the web interface it still gives me the error message "Internal Server Error", though. So I suspect there is still something wrong with the server settings.

[Edit] .html files in cgi-bin can be retrieved, and .php scripts there do work. Other .cgi files there give the same error message. and an attempt to retrieve a .txt file too. My guess is that Apache should still be told that running CGI files from this directory is OK.

I created a helloworld.cgi test script in /cgi-bin/, and it runs from the command line. I deleted an end slash from the ScriptAlias value, and I started getting 404 errors for files in /cgi-bin/ instead of 500 errors. Looking more closely at example code, I saw the ScriptAlias value ending with a slash. So, I put it back in, and I'm getting 500 errors again.

After some googling I came here, where it says that in the Apache config file (httpd.conf) one should have something like

<VirtualHost *:80>
     ServerName www.example.com
     DocumentRoot /var/www/html
     ScriptAlias /cgi-bin/ "/usr/local/cgi-bin/"
     <Directory "/var/www/cgi-bin/">
         Require all granted
         Options +ExecCGI
         AddHandler cgi-script .cgi
     </Directory>
</VirtualHost>

For chessvariants.com we seem to lack de + on the ExecCGI option, and the AddHandler stuff. I have no idea what this all means.

Well, we already tried that, and after an uphill battle even succeeded, and the resulting binary is even on the CVP server, as public_html/index/fen2.cgi . But it appears we ran into a problem with the server refusing to execute the resulting CGI file when accessed from the web; see the discussion here.

I was trying to get cgi-bin to work yesterday, but nothing I tried worked. Today I've been trying to write a PHP wrapper script for fen2.cgi. It's able to run the program and output the data, but it either appears as plain binary text, or if I add a Content-Type header, it says the image cannot be displayed because it contains errors. If you want to take a look at the script and try getting it to work, it is in /cgi-bin/.

I'll have a look at it. fen2.cgi already outputs an image/png Content-Type header, as it expects its output to go directly to the client. But I can make a version that omits this.

[Edit] OK, I now made such a version of fen.cgi that omits the header if it was not called directly by the server, which it can see by the environment variable REQUEST_METHOD not being defined. Apparently the PHP script does not pass the environment to the programs it calls.

Accessed through the web fen2.php now makes a 50x50 white king image appear in the browser.

Problem is that the variable QUERY_STRING is also not passed, so fen2.cgi has no idea what the user was requesting, and puts out the king by default. Is there a way to make the PHP script run fen2.cgi with some environment variables set?

I suppose I could adapt fen2.cgi to accept a command-line argument, and use that as query string when it doesn't find one in the environment. Then fen2.php would just have to append its query string to $command (after a space).

@Fergus: I have no permission to edit fen2.php, nor do I have permission to create other files in that folder.

Can you alter fen2.php such that it passes the entire query string as a single argument to fen2.cgi? I think that should make it work.

That was the first thing I tried, and it didn't work. That's why I converted the query string into command line arguments. But I did try it again, and it still didn't work. Here is what I now get with command line arguments if I omit the PHP header() command:

Content-Type: text/plain -s=$s 

I have now changed the owner of the file, which should let you edit it.

Well, it could not have worked at that time, because fen2.cgi was not looking at its arguments at all. It expected the query string in an environment variable, which is how Apache passes it. Another problem was that the query string can contain &, which in the eyes of the shell terminates the command. I now escaped that with a backslash when fen2.php glues the string back to one piece. Yet another problem was that the PHP script always seems to put out a header, even when the header("image/png") call was commented out: it then uses a default header "text/plain", possibly inserting it before the header emitted by fen2.cgi. So it was imperative that the PHP script would set the header to "image/png", and hence that fen2.cgi would omit the header, as that would then be perceived as corrupted PNG data.

I believe I also was fooled a lot by browser caching, as displaying a queen suddenly started working without me making a significant change.

Anyway, it does appear to work now!

Remaining problem is that the Diagram Editor article cannot be edited without corrupting it. So I cannot change the links that go to the off-site renderer to point to our own fen2.php...

What I'd wonder is, can the Play-Test Applet be edited (or something like it created) to use the local fen2, with selections for which SVG set to use?

If so (and probably even if not), some of the icons I just uploaded* would be superfluous.

*Specifically those for Bowman, Flash Bishop, Little Buffalo, Power Queen, Push Rook, and Relay Knight.

Addendum: I can affirm that it works with my SVG set, as I will "Nao" demonstrate:

Addendum #2: I may have spoken too soon. I tried using it for the Zwangkrieg ID, and all of the pieces came up as unmodified White King.

Well, the original Play-Test Applet, like the Diagram Editor for Scalable Graphics, cannot be edited, as the editing script for articles here is really more a text corrupter than an editor. The new Play-Test Applet, which I created as an independent HTML page, can be edited through ssh or ftp, though.

Basically what you want is a way for the user to specify the graphicsDir.If you can do that you can point it to any piece set, including the rendering script. To make the piece table it should search the directory with the SVG files, though, as the renderer won't tell you which pieces are available. But then it should be smart enough to recognize that graphicsDir is a script, and know where it would get its images from. (Which depends on the query string.)

Addendum #2: I may have spoken too soon. I tried using it for the Zwangkrieg ID, and all of the pieces came up as unmodified White King.

Did you capitalize 'Greenwade'? Unlike on winboard.nl, on CVP it is spelled with a capital.

Well, the original Play-Test Applet, like the Diagram Editor for Scalable Graphics, cannot be edited, as the editing script for articles here is really more a text corrupter than an editor.

If you change the format to Text or turn off JavaScript, it will not use CKEditor.

If you change the format to Text or turn off JavaScript, it will not use CKEditor.

I tried that already long ago on the Play-Test Applet, and it makes no difference at all. The text still gets totally corrupted, with hundreds of unrequested modifications.

I just tried it again on the Diagram Editor: switching JavaScript off in FireFox I click "Edit this page", and without making any changes I immediately save the text again. If I then switch JavaScript on to go to the 'revisions' page, and ask for comparison of the two latest versions, virtually every line in the text is changed.

Some of these changes apparently wreck the page: most striking symptom is that all orthodox pieces have disappeared from the piece table. But who knows what else no longer works.

I even tried taking the article text from the page source, and pasting it into a novel submission (with JavaScript off). It gets corrupted the same way, and no working applet results. So the corruption occurs in the saving. Not by the CKEditor or loading the text into the submission form.

The current list of revisons for this page is:

  #626 last working version
#13158 attempt to change the links to winboard.nl (corrupted)
#13159 reinstatement of #626
#13180 'unmodified' saving of #13159 with JavaScript off (corrupted)

I'm going to do some test edits to see what happens. You can revert back to one of your previous edits when I'm done.

Here's what I did. First, I reinstated #626. Then I went to the bottom of the screen, clicked on Edit Content, and I copied what was in the TEXTAREA to a text editor. Then without making any changes, I saved it in Text mode. I went back to Edit Content again, and I copied what was in the TEXTAREA to another tab in my text editor. When running a comparison between these in my text editor, it found no differences between them. Likewise, the online comparison between the two latest revisions found no difference. As one last check, I did a comparison between #626 and the last revision, and I found no difference between them. So, as far as I can tell, the differences you found were from your own edits and not from any corruption of the text while saving.

ADDENDUM: I did some more comparisons with text copied from the database. The text saved in MemberSubmissions was a match for the others, and so was the text in revision #626. So, perhaps you did some editing while still in HTML mode instead of switching to Text mode right away.

Something very fishy is going on here. I see 3 new revisions, #13185-13187. The first of these still lists me as the author. I suppose that is the reinstated #626. Comparison says #13185 and #13187 are identical. But comparison with #626 shows hundreds of differences! Yet I can confirm that the current version functions correctly: it shows the othodox pieces. So first I thought #626 had been inexplicably corrupted. (This idea is supported by the fact that the date of change it indicates is suddenly today...)

But the amazing thing is that the indicated differences between #626, #13158 and #13159 are the same for every pair of the three! Since this is a logical impossibility, we can conclude that the revision comparison is sick as well.

It is an absolute certainty that the differences between #13159 and #13180 were not due to any edits of mine: I just created #13180 for testing purposes, immediately pressing the 'Save' button after going to the Edit form. Furthermore, JavaScript was switched off, so there was no possibility to switch modes.

Are you sure you were using the same script as I did for editing? I suppose you edited as a CVP editor, while I have been editing as a contributer.

I tried to edit the article through the form for editors rather than the normal form. To my surprise that did not show me the CKEditor; the pulldown for the format at the top of the page was set to 'Text'. When I edited through the contributers form, it was always set to HTML, and I did get a CKEditor, unless I had switched JavaScript off. So I switched it to HTML (but also had the checkbox 'use HTML tags in text' checked) before saving.

This gave me the same corruption, and disappearance of the orthodox pieces from the piece table.

So I went back to the contributer edit form, to reinstate the previous version, and everything worked again.

But something had changed: If I now go to the contributer edit form, the pull-down at the top is set to Text, instead of HTML, and no CKEditor, just plain HTML textareas. So I tried the edit again, and this time saved as 'Text' (assuming this was what you had done). This faithfully saved the edits. The comparison shows no corruption, just the changes, and the resulting page works properly.

It seems that the corruption occurs exclusively when you save in HTML mode (with or without CKEditor, as it also occurs with JavaScript off). Which is a bit strange, as the text I am saving is clearly HTML. Anyway, this solves my problem for being able to edit the article, now that I know how to do it. So I made it use the local fen2.php now.

I reinstated #626, because it hadn't been edited recently. The current timestamp on it is 2023-11-21 12:45:52, which is later than the timestamp of my last edit at 2023-11-21 12:25:27. Adding 5 hours to that for the difference between UTC and EST, I get a time that is about a minute before the comment you are replying to. Yet the timestamp on #626 is 20 minutes later. This is probably from when I updated my comment with details about testing copies taken directly from the database. So, it appears that going to its row in the database updated its timestamp. As a further test, I will go there again and take a copy of what is there now. But first I'll post this to have the timestamp on record.

When I copied #626 to my text editor from the database again, it still matched what I compared it to, which was itself one of the mutual matches from my earlier comparisons. Looking at a comparison online, I see only whitespace differences. For all I know, it is just a difference between CR+NL vs NL at the end of each line.

I just made an empty revision to double check what time zone I am seeing the timestamp in. It was 2023-11-21 15:37:16, which is EST. But to confuse me, the editcomment.php page is listing times in UTC. So, to check the times in EST, I loaded the listcomments.php page. My second revision was at 2023-11-21 12:25:27, and the timestamp on my comment about it was 12:36 PM EST. The new timestamp on #626 is 2023-11-21 12:45:52, which is 9 minutes later.

But to confuse me, the editcomment.php page is listing times in UTC.

I fixed that. I eventually figured it had something to do with the placement of the code for starting a session, which was in the header. When I moved the header ahead of other include files, it started displaying dates in my own timezone.

H. G.,

I have reinstated #13205, because you stopped using fen2.php after that. I happened to be working on the script at the time, using some diagnostic code that stopped it from working. For now, I reverted it back, but I will work on it again later when you are more likely to be asleep. I am trying to make it more secure, so that no one can use it to hack the site.

Beware the current version is #13210. I never stopped using fen2.php. I have been working on it too, so there is a danger that our modifications erase each other. I am done for today, however.

Okay, I have updated fen2.php, and it is working.

Instead of using $_GET directly, it will now decode the query string with urldecode() and html_entity_decode() before parsing it. This allows it to convert both %26 and & to an &.

It uses a $default array to screen out unrecognized options. It adds an option as an argument to the command only if (1) it has a default value listed, and (2) its value does not match the default value. Since I do not know the default values used by fen2.cgi, I made all the default values empty strings. So, right now, it will include any non-empty value for any recognized options.

It uses escapeshellarg() on each value as a precaution against someone trying to run another program on the server.

Since escapeshellarg() was interfering with the use of < and > to rotate pieces, I replaced it with a restriction against including spaces in values.

In case you didn't see my comment earlier, we can still only use < and > to rotate pieces in illustrations, or an entire side on an Interactive Diagram. As much as I might want to use  rather than for the Flash Bishop in the Zwangkrieg ID*, I cannot.

*Actually, I'm vascillating on the question. I'm just using it as an example.

You can, but since <>wbishop is a name that does not have the color prefix in front, you would have to use the % to indicate where it should be inserted. This also suppresses prefixing with the graphicsDir, though. So you would have to write that explicitly too.

Perhaps I should provide a shortcut for that in the ID script. E.g. a leading asterisk in a name that contains a % sign could be replaced by the value of graphicsDir.

[Edit] I updated the ID scripts to replace a * prefix by the grapicsDir in names that contain a % sign. They now also replace all % signs by the color prefix. This should allow specifying the color on both members of a compound piece.

Nice tool. Some remarks if I may:

1. It is not easy to move a piece away. If I left-click on it, it shows the squares to move on and stays. If I right-click on it, it opens a diagram for the moves (good). If I drag it away, it remains attached to the pointer and reappears everytime I come back on the diagram. Maybe I'm not doing the right way, but I tried to follow the instruction "Pieces already on the board can be clicked or dragged for moving them; this way you can correct the location of misplaced pieces, or capture them with another piece".

2. Maybe this is not possible, but I ask. I would find very useful that diagram shows the coordinate system, not on the squares directly but rather a bottom line with the letters and a column with the numbers. (For giant CVs it would be a convenient feature).

3. A button for an automatic disposal of Black pieces in mirror symmetry of White's would be nice to have also.

Thank you

Thank you for the feedback.

I don't have the mouse problems you describe; This is a normal Interactive Diagram, and it should behave like any other. Except that the URLs for obtaining the piece images point to the rendering script, rather than to a file with a pre-calculated image. This offers more opportunity for it to be slow. But that should really happen only the first time you use a certain piece type; after that the browser should have cached the image as a file on your own computer, no matter what its source was, and access should always be fast.

As to (2), are you talking about the board for setting up the position, or the PNG image that will be delivered? The former should be easy, as it is a standard function of the ID that just has to be switched on. But it does take up space, which especially for a large board is a scarce resource. And it raises the problem of how to number the ranks, possibly requiring extra user input to control that.

The Applet just delivers the image the rendering script provides in response to a FEN. It would be a lot harder to provide coordinates there. The renderer was based on XBoard's code for drawing the board, and XBoard draws coordinates inside the squares. Not everyone might want coordinates, so this also requires extra controls in the applet.

As to (3): Agreed; setting up a position is pretty annoying once you are used to the Play-Test Applet. The ID already supports this possibility, so it would just be a matter of adding an input element in the applet to control that. Perhaps a button that you could press to toggle between mirror symmetry and asymmetric setups, starting with symmetry. (So that you coul press it when you have placed all pieces that need symmetry, and then place the others.)

I am currently wrestling to implement handling of the other SVG sets we have. But so far only Greenwade works properly. (Next to Alfaerie and XBoard, which already worked before.) The others suffer from various ailments: the filenames are partly capitalized, (and not only in their first character), only some of the pieces are available in a black variety, some standard pieces have non-standard names...

Yes for 1) it's probably on my side then. For 2) I understand is more complex than I thought. It won't be a good idea after all and the need is not very strong, so never mind. For 3) that's great if it can be done. Maybe with choice between Mirror symmetry / Radiall symmetry / No symmetry at all (free placement).

Thank you

I updated the ID scripts to replace a * prefix by the grapicsDir in names that contain a % sign. They now also replace all % signs by the color prefix. This should allow specifying the color on both members of a compound piece.

So to make sure I have this right: if I want a piece that shows a left-tilted Bishop in front of an inverted Wind, I'd use *<>%bishop-_%wind (which would only work in the ID, though presumably the icons in the overview would have the * omitted and the % replaced with w and b).

At least, theoretically.

Yes, theoretically.

I already ran into a major problem, though: using < in a HTML context is an absolute nono, as it will always be interpreted by the browser as the start of a tag. And the definition of the ID lives in a HTML context. So what you say would work in a URL that you type in the address bar, but not embedded in a web page. So perhaps we will have to look for an alternative symbol for indicating rotation to the left.

It seems Utrecht and Motif now work reasonably as well. And I had to fix escaping of some more characters in the PHP wrapper to make the FEN option work, as it chocked on the quotes and parentheses that would be used when indicating unorthodox and non-standard pieces. But that all works now.

Magnetic now also works.

I wonder what the default color filling for the black pieces should be. The renderer is programmed to only use the black ('solid') SVGs if the specified fill color is #202020. In other cases it uses the white ('outline') pieces filled with the specified color.

What would be a good default color for Motif and Magnetic. In most diagrams where I have seen those used they are reddish. But I understand that gives problems on the Kindle. I now have made it semi-dark blue.

I already ran into a major problem, though: using < in a HTML context is an absolute nono, as it will always be interpreted by the browser as the start of a tag. And the definition of the ID lives in a HTML context. So what you say would work in a URL that you type in the address bar, but not embedded in a web page. So perhaps we will have to look for an alternative symbol for indicating rotation to the left.

I'd noticed that as well. Of course / and \ (which would be my own inclination) have similar problems, don't they? So does just about every other punctuation mark (especially paired marks) that I can think of, except maybe for [ and ].

What would be a good default color for Motif and Magnetic. In most diagrams where I have seen those used they are reddish. But I understand that gives problems on the Kindle. I now have made it semi-dark blue.

My first thought would've been that, or golden yellow (#FFDF00).

(Side note: a good default for Black in my SVGs would be #660088.)

except maybe for [ and ].

I will point out that these are used for shortcodes. Instead of packing stuff onto the piece name, I would recommend adding a new option, such as o for orientation with a default of 0 and possible values of 90, 180, and 270.

I will point out that these are used for shortcodes. Instead of packing stuff onto the piece name, I would recommend adding a new option, such as o for orientation with a default of 0 and possible values of 90, 180, and 270.

 Approached differently, the values could be 0-7, and the piece rotated clockwise 45 degrees times that value.

However, making it a command option still rotates only a piece in an illustration, or an entire set on an ID, unless it can be put after the p= argument. Even then, if I'm reading it right, it'd rotate the entire piece, and not just one part of a combo.

(And I did say "maybe.")

The original function of the renderer was to produce whole-board images from a FEN. (Hence its name...) In FENs digits are reserved for indicating a number of empty squares on a rank. And an extra option could at best apply to all the pieces in the FEN, rather than being selective. And if we have something that works in FENs, we might as well use it for rendering individual pieces as well.

To be frank, I don't really consider rotated pieces very important. The whole idea one should do this is a legacy from the days that there were only 6 glyphs for chess pieces, to represent a multitude of fairy pieces. But today we have Alfaerie. I just implemented the rotation because Alfaerie had some rotated glyphs, and it seemed nice to be able to also render these antialiased without having to make separate SVG for them. And it was easy to do.

I think the $ is still available. So I will use that as an alternative for <.

My main use for a rotated icon is for pieces that move forward like one thing, but backward like another. For example, Bishop + inverted Man = Charging Bishop, Zebra + inverted Knight = Zorse, Chancellor + inverted Man = Colonel, Queen + inverted Centaur = Forequeen, and so forth.

And of course inverted Crab = Barc.

The vertical bar is supposed to satisfy that need. I fixed a bug that prevented x|-y from working similarly to x--y: it was scanning the piece name for | and - in the wrong order (- first), and would then test whether another - followed, to replace it by the first prefix.

The < and > are only needed for sideway rotations.

Yes, that works now. I'll be good on that point, at least. :)

@Fergus: the directory /graphics.dir/svg/Greenwade is owned by root, so I cannot create any files there. (For fen2.cgi to work optimally there must be a defaults.ini file in each piece directory to fine-tune the parameters.)

Can you also check what would be a reddish color (#xxyyyy with xx > yy) that does render like grey on both Kindle and Likebook? Then I could set those as defaults for Magnetic and Motif.

the directory /graphics.dir/svg/Greenwade is owned by root

I changed the owner to chessvariants.

Can you also check what would be a reddish color (#xxyyyy with xx > yy) that does render like grey on both Kindle and Likebook?

I'll look into that some more after I update the Diagram Designer to work better on a mobile device.

@H.G.: The pink and green colors you show here for my icons are ones I specifically chose for Zwangkrieg. More appropriate defaults would be F9F9F9 and 660088.

Also, the wildebeest should be the gnu; that's what I made it for.

And don't forget the H for hawk, E` for modernelephant, C` for wizard (and not just "moon"), B: for ballista, and G! for griffin! :)

@Fergus: Please put in my latest update; rename n2r4 to lower-case; and delete the Flash Bishop, Little Buffalo, Power Queen, Push Rook, and Relay Knight. (Those and the Bowman were meant as placeholders; the Bowman can stay because it actually looks OK.)

I might have to follow up with fixes for the n2r4 and midnight icons, which aren't showing color changes, but I'd like to see how what I sent manages before I try it (and it'll just be one or both of those two).

@H.G.: The pink and green colors you show here are ones I specifically chose for Zwangkrieg. More appropriate defaults would be F9F9F9 and 660088.

And for the square colors?

And for the square colors?

While I have a personal preference for black and red, I do understand how that causes problems on certain monochrome devices, so the light and dark browns in the default are fine, or FFDF00 and C19A6B (the piece colors in Hundred Acre Chess) if that doesn't hurt the eyes too badly.

Edit: It turns out 660088 is too dark. Try 8000FF instead.

I'm also seeing that, in compounds, the bottom of the back piece is truncated. I know that that helps with things like camel-queen, but it causes problems for others, like Relay Knight, Foursquare, Korean Pawn, Ski Bishop, etc.

This happens to be what many of the "modifier" icons (Relay, Korean, Ski) are for, so a single icon can yield dozens of pieces.

Maybe there could be a way to toggle this? Especially on a piece-by-piece basis? (Even if it's an inline variable that can follow the icon description.)

I unzipped Greenwade9.svg, and I deleted wflashbishop.svg, wlittlebuffalo.svg, wpowerqueen.svg, wpushrook.svg, and wrelayknight.svg. There is already a n2r4.svg file that is newer than N2R4.svg. If I rename it, it will replace the newer file. Would you rather I delete it instead?

There is already a n2r4.svg file that is newer than N2R4.svg. If I rename it, it will replace the newer file. Would you rather I delete it instead?

Yes, please delete the older one. And many thanks! :)

Addendum: On inspection, it works out that I am having to fix the Boar, Fox, Midnight, and Mongoose icons, and probably n2r4 as well. I'll have that ZIP in the morning.

This happens to be what many of the "modifier" icons (Relay, Korean, Ski) are for, so a single icon can yield dozens of pieces.

Such modifier icons are a novel concept; the renderer's feature for creating compound glyphs was originally intended for combining symbols for stand-alone pieces. There is some fine tuning of the combination process that can be controlled by the default.ini file in the folder with the SVG images, like demagnification and shift. The amount that is clipped away of the rear piece might even be one of those. (This was all done so long ago that I am not sure how it worked anymore.) In that case I could disable the clipping entirely for Greenwade. And if not, such a global parameter could be added.

The alternative would be to use different characters for combining with and without clipping. E.g. a + instead of a - for unclipped overwriting.

[Edit] OK, I checked out how it works. The default.ini file contained a line

compound 64 52 0 3 40

to control the combining of icons. The parameters here (all in units of 1/64 times the square size) are horizontal and vertical size of the component images, the horizontal shift between the two, a 'fudge factor', and the part of the rear icon that is shown. They are than renedered such that the rear piece touches the top of the square, and the front piece the bottom. Both would be centered horizontally, irrespective of their horizontal resizing, unless a horizontal shift is specified. (Which would then shift ther rear icon to the right, and the front icon to the left from the central position). The fudge factor has to do with fow much flipped pieces are moved vertically. (If a set clings very much to the bottom of the squares, you don't want the flipped pieces to hang from the top.) The final value describes how much of the rear piece is shown, starting from the top.

The default values for these parameters are 50, 50, 14, 0, and 64. But this changed when I copied the default.ini from Alfaerie to the Greenwade directory, in order to control the default colors. I now changed the clipping parameter back to 64. (Flush the cache to see how this affects the generated images!)

The default values for these parameters are 50, 50, 14, 0, and 64. But this changed when I copied the default.ini from Alfaerie to the Greenwade directory, in order to control the default colors. I now changed the clipping parameter back to 64. (Flush the cache to see how this affects the generated images!)

Color me happy. :)

Addendum: Even so, being able to append something like &clip=60 or &shift=15 would probably not be a bad thing, for fine-tuning purposes. That's no rush, though.

I've uploaded the corrections I mentioned in what I hope will be the last update to my set for a while.

(There are a few that I'll want to modify to make more legible, distinctive, etc., but it'll likely take a while, depending on how busy I can make myself with new entries.)

I've uploaded the corrections I mentioned in what I hope will be the last update to my set for a while.

Okay, that's done.