Comments/Ratings for a Single Item

The showpiece.php script is not based on fen.cgi, and it would be a lot of work to try to duplicate its ability to edit and combine images. Maybe I could take a crack at compiling fen.cgi over here.

Why not just make the compound pieces you want as separate images?

I could do that, though part of the point of some of the images is to minimize having to do that no matter how many different ideas come up. I mentioned earlier having some outliers to add much later (like Anteater, Bharal, and Inquisitor) along with some that are mainly used in Shogi (dog, monkey, etc.), but on the whole these rely somewhat on fen2's ability to compound to make these rarer pieces.

The Spy arguably does deserve an image of its own; for now, I'll start getting some ready for this game and the others I'm trying to get loaded (including full Camel and Zebra QBRM sets, or at least some images usable for such).

I got the %26 in there (the other changes were already in place), and the pieces are now on the board, except for the compounds (Bowman, Spy, and Helepolis). I'm assuming that compounds (as seen with H.G.'s fen2 program) aren't implemented with showpiece at this time.

Compound graphics aren't rendering.

It looks like you are expecting to be able to combine two images into a single image. The showpiece.php script does not do this. Is this something another tool did? Why not just make the compound pieces you want as separate images?

I made some changes to get my copy of your diagram to work. I replaced graphDir with graphicsDir, graphSuffix with graphicsType, and & with %26. Are any pieces missing from it?

This ID's still having issues:

• I don't remember what I changed to get the images to show up on the board in Hundred Acres when they were only showing up in the overview.
• Compound graphics aren't rendering.

I tested window.navigator.userAgent, and it gave useful values on my Kindle and in Chrome on my Likebook Mars, but the value it gave in Firefox on my Likebook Mars did not mention the device by name. I cleared the cache in Chrome on my Likebook Mars, but I still saw a black bar over the board.

Please try what it does on the Kindle.

It is only the Likebook Mars that displays red as black. The Kindle displays red as white, which leaves the text legible. However, I now see the text in a grey bar on the Kindle, and I think that previously I just saw the text against the same white background as the rest of the comment.

I only could find very round-about ways for determining whether a display is greyscale. Like drawing something colored in a HTML canvas element on the page, and then reading back the pixels to see if they are all grey (i.e. have R=G=B).

Getting to know which device you are running on seems to be impossible for security reasons. It is possible to get the userAgent string that the browser sends to the server in the request headers, though. Which is the thing your PHP script retrieves. Normally the computer type is not specified in that string (just OS and browser), but apparently the e-readers are an exception to this. So perhaps I can get this to work in JavaScript as well.

[Edit] I now put in the code

  var ua = navigator.userAgent;
  ua = ua.search(/(kindle|likebook|meebook|boox|onyx|pocketbook|inkpad)/i);
  if(ua >= 0) useMarkers = 2, realColor = startColor = '#E0E0E0', light = '#FFFFFF', hicol = '#808080'; // assume grey-scale display

For my desktop things still look normal. Please try what it does on the Kindle.

Well, not really, because it relies on images from an external website, which is something we want to discourage. Especially since this is a http website: most people won't be able to see those images at all, since CVP became a https site. It requires a non-default setting of the browser to see them.

Well, I'll wait until you/I/we can get the new system to behave, then.

In showpiece.php, I am using this code:

$ua = getenv("HTTP_USER_AGENT");
$eink = preg_match("/(kindle|likebook|meebook|boox|onyx|pocketbook|inkpad)/i", $ua);

I know "kindle" and "likebook" work, and the others are just guesses based on brand and product names.

Nice, but that is server side in PHP. The client machine (from the TCP/IP request header) there apparently is stored in an environment variable before Apache invokes the PHP interpreter, so the PHP program can fetch it with getenv().

But the JavaScript is running client side, and does not have access to the server environment variables. If there was a JavaScript method for identifying the machine it runs on, that would be usable.

On my desktop, I clicked on Reload Skip Cache, and when I inspected the Javascript-produced HTML with Web Developer Tools, I couldn't find any IMG tags for the pieces. I changed graphSuffix to graphicsType in a preview, but it didn't change the result.

Two things that could play a role here:

• The Diagram below also uses the wrong key for graphicsDir. So by default it uses /membergraphics/MSinteractive-diagrams/ instead of your rendering script, and there are no .svg files there.
• The pieces in the Diagram are drawn as background. To know what is actually used as image URL, I always use the images in the piece table (rightclicking those in FireFox, and select 'inspect' from the context menu that appears).

When I corrected the graphicsDir and graphicsType keys in that comment, the pieces did show up in the table. But still not on the board. Perhaps SVG rendering is not supported for background images, in FireFox?

What alternative do we have for recognizing a monochrome display?

In showpiece.php, I am using this code:

$ua = getenv("HTTP_USER_AGENT");
$eink = preg_match("/(kindle|likebook|meebook|boox|onyx|pocketbook|inkpad)/i", $ua);

I know "kindle" and "likebook" work, and the others are just guesses based on brand and product names.

My desktop also gives colorDepth = 24. I recall that the 16 was inspired by the browser on my Kobo e-reader. (Which seems to have magically disappeared?!)

OK, so using colorDepth for this won't work. What alternative do we have for recognizing a monochrome display?

You did flush the cache?

I did that in Firefox on my Likebook Mars, but I saw no improvement. On my desktop, I clicked on Reload Skip Cache, and when I inspected the Javascript-produced HTML with Web Developer Tools, I couldn't find any IMG tags for the pieces. I changed graphSuffix to graphicsType in a preview, but it didn't change the result.

screen.colorDepth

My desktop computer, my Likebook Mars, and my Kindle Scribe all report a value of 24. So, this isn't useful for distinguishing between them.

  if(screen.colorDepth <= 16) useMarkers = 2, realColor = '#E0E0E0', light = '#FFFFFF', hicol = '#808080'; // assume grey-scale display

'hicol' is what is used as background color on highlighted messages, 'realColor' and 'light' the square shades. I have not tested it on an e-ink device.

I have fixed the default extension. You did flush the cache? (If e-reader browsers have such a thing...)

The failed attempt to specify the graphicsType does expose the typo in the default value for this; I will fix that.

Let me know when you have. Web Developer Tools in Firefox is still telling me the images have the .pgn extension.

I'm still seeing a black bar above the board on my Likebook Mars. Tell me how you check the color depth with Javascript, and I will report back the values I get.

When the Berserkers appear on this diagram, it'll be ready to be moved into the main article. (Unless it needs to be recolored, which it very well might.)

Well, not really, because it relies on images from an external website, which is something we want to discourage. Especially since this is a http website: most people won't be able to see those images at all, since CVP became a https site. It requires a non-default setting of the browser to see them.

The ID already makes an attempt to recognize e-ink devices (by their color depth), for the purpose of suppressing color highlighting, and forcing the use of marker symbols instead. (Which otherwise would require useMarkers=1.) I could also make that affect the background color of messages like 'Checkmate!'. For the initial message that appears above the board the HTML setting the background is just part of the message, but it is not very critical that this should be red. I could switch it to green.

The ID accepts any string as graphicsType, and would append it to the filenames as an extension (i.e. separated by a dot) if it is not set to the empty string. Except when there is a % in the filename; then the extension (and graphicsDir prefixing) is suppressed, to allow 'guest images' of another, explicitly mentioned type.

The problem with the Diagram below is that it uses the key graphSuffix for specifying the graphics type, which is not recognized by the definition parser. (And then ignored. Perhaps I should emit a warning for unrecognized parameters, instead of the usual meaasge above the board.) The confusion probably arises from that graphSuffix is the internal name of the variable used in the JavaScript for this. The variable names do not always coincide with those of the parameters, as the idea of using the original content of the Diagrams HTML tags to define the Diagram (rather than extra JavaScript between <script> tags) evolved only later, and the variable names did not always seem optimal.

The failed attempt to specify the graphicsType does expose the typo in the default value for this; I will fix that.

[Edit] OK, I think I fixed everything, both in betza.js and betzaNew.js. The default graphicsType is now png, and the red highlighting in the text above the board is now changed to #808080 when the colorDepth of the screen is <= 16. It also displays an error message for the last non-fatal error. (Flush cache to use new version!)

How about purple and light grey?

Your fuschia squares are still white on my Kindle Scribe. On my eink devices, colors with a high red value do not work well. They are too dark on the Likebook Mars and too light on the Kindle Scribe. I recommend staying away from red squares unless H. G. makes them render as a medium grey on eink like I did with red pieces using showpiece.php.

It wouldn't have rendered the Bowman, Helepolis, or Spy anyway, as those are compound images. (Or would it? I'm not sure.) Still, it's good to know that for something like Hundred Acre Chess (which doesn't use those) that's an option, or soon will be.

PS: I switched to white/fuschia. How is it now?

I am trying this code, but there is a bug preventing it from working. Instead of appending .svg to the file name, as I have instructed it to, it is appending .pgn. This is probably a typo for .png, as that is a graphics format, and .pgn is a format for storing chess games. Also, since we're able to use SVG images now, it should allow svg as a value for graphicsType or graphSuffix.