Check out Janggi (Korean Chess), our featured variant for December, 2024.


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

Comments/Ratings for a Single Item

EarliestEarlier Reverse Order LaterLatest
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]
Bob Greenwade wrote on Mon, Nov 13, 2023 05:21 PM UTC:

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.


💡📝H. G. Muller wrote on Mon, Nov 13, 2023 07:12 PM UTC in reply to Bob Greenwade from 05:21 PM:

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.


Bob Greenwade wrote on Mon, Nov 13, 2023 07:17 PM UTC in reply to H. G. Muller from 07:12 PM:

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.


💡📝H. G. Muller wrote on Mon, Nov 13, 2023 08:09 PM UTC in reply to Bob Greenwade from 07:17 PM:

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


Bob Greenwade wrote on Mon, Nov 13, 2023 08:19 PM UTC in reply to H. G. Muller from 08:09 PM:

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


💡📝H. G. Muller wrote on Mon, Nov 13, 2023 09:33 PM UTC in reply to Bob Greenwade from 08:19 PM:

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.


Bob Greenwade wrote on Mon, Nov 13, 2023 10:12 PM UTC in reply to H. G. Muller from 09:33 PM:

My thanks! :)


🕸Fergus Duniho wrote on Sun, Nov 19, 2023 07:02 PM UTC in reply to H. G. Muller from Thu Dec 29 2022 08:54 AM:

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.


💡📝H. G. Muller wrote on Sun, Nov 19, 2023 08:02 PM UTC in reply to Fergus Duniho from 07:02 PM:

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.


🕸Fergus Duniho wrote on Sun, Nov 19, 2023 08:39 PM UTC in reply to H. G. Muller from 08:02 PM:

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.


💡📝H. G. Muller wrote on Sun, Nov 19, 2023 09:55 PM UTC in reply to Fergus Duniho from 08:39 PM:

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.


🕸Fergus Duniho wrote on Mon, Nov 20, 2023 05:02 PM UTC in reply to H. G. Muller from Home page of The Chess Variant Pages on Sun Nov 19 09:29 AM:

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


💡📝H. G. Muller wrote on Mon, Nov 20, 2023 05:34 PM UTC in reply to Fergus Duniho from 05:02 PM:

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


💡📝H. G. Muller wrote on Mon, Nov 20, 2023 06:15 PM UTC in reply to H. G. Muller from 05:34 PM:

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


🕸Fergus Duniho wrote on Mon, Nov 20, 2023 06:54 PM UTC in reply to H. G. Muller from 06:15 PM:

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.


💡📝H. G. Muller wrote on Mon, Nov 20, 2023 07:53 PM UTC in reply to Fergus Duniho from 06:54 PM:

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!


💡📝H. G. Muller wrote on Mon, Nov 20, 2023 08:02 PM UTC in reply to H. G. Muller from 07:53 PM:

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


Bob Greenwade wrote on Mon, Nov 20, 2023 08:16 PM UTC in reply to H. G. Muller from 08:02 PM:

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.


💡📝H. G. Muller wrote on Mon, Nov 20, 2023 08:41 PM UTC in reply to Bob Greenwade from 08:16 PM:

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


💡📝H. G. Muller wrote on Mon, Nov 20, 2023 08:47 PM UTC in reply to Bob Greenwade from 08:16 PM:

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.


🕸Fergus Duniho wrote on Mon, Nov 20, 2023 11:53 PM UTC in reply to H. G. Muller from 08:41 PM:

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.


💡📝H. G. Muller wrote on Tue, Nov 21, 2023 08:45 AM UTC in reply to Fergus Duniho from Mon Nov 20 11:53 PM:

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)

🕸Fergus Duniho wrote on Tue, Nov 21, 2023 05:19 PM UTC in reply to H. G. Muller from 08:45 AM:

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.


🕸Fergus Duniho wrote on Tue, Nov 21, 2023 05:36 PM UTC in reply to H. G. Muller from 08:45 AM:

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.


💡📝H. G. Muller wrote on Tue, Nov 21, 2023 06:34 PM UTC in reply to Fergus Duniho from 05:36 PM:

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.


25 comments displayed

EarliestEarlier Reverse Order LaterLatest

Permalink to the exact comments currently displayed.