Comments/Ratings for a Single Item

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