Comments/Ratings for a Single Item

How would I go about programming the King to be able to swap places when capturing its own pieces? Like I could swap a pawn next to the King and still have all of the check detection. What I have now is letting me capture my own piece, but I can't drop it back down to where the King was to imitate a swap. The code successfully says that it swapped but the piece remains taken.

sub k from to:
  verify fn km #from #to;  // legal king move
  verify sub hw #from #to; // dont mind this
  if not #ktest:           // whether or not to just test legality
    if and $lastcaptured (isupper $lastcaptured):
      say Swap King {#from} with {#to};
      drop $lastcaptured all #from;
      set k #to;
    endif;
  endif;
  return true;
endsub;

edit: entirely my fault, i didn't have any code in my Post Move section so it didn't actually run the k subroutine. i made it so it drops the piece where it moved from

Games with a rank label of 0 don't display correctly, as can be seen in Apothecary Chess Modern. It looks right if the rank label 0 is replaced with something else

Another game with this problem is Rococo

Now that Daniel brought this problem up, I should also note that presets with a Max Columns value of 0 don't display, only showing the following text.

When cols is zero, you don't have a board. Exiting before it tries to divide by zero.

An example is my old Hook Shogi preset and other old presets, for which I did because I was younger and less experienced.

Thankfully, this is very easy to fix. Throw in a clause in the script that forces the Max Columns value to be 1 if the field is evaluated to be 0.

Pseudocode, assumes val("Max Columns") has been pre-validated to let only integers through.

if (val("Max Columns") == 0) { cols = 1; } // Set Max Columns to 1 to prevent dividing by 0 or a negative number

else cols = Math.abs(val("Max Columns")); // Valid value (take absolute value to ensure proper division)

This and other changes I tried making to the code didn't help. So, I undid them all to avoid introducing new bugs with code that didn't solve the problem anyway, and I deleted every variable assignment in your settings file that was to an empty string.

@Fergus: I need to study some past games played on GC. How to "scroll" in a given game in order to see the successive moves 1 by 1?

I know how to visualize a given position, but I can't find how to scroll in the list of moves.

I don't know if this feature exists.

Thank you

View mode lets you view successive moves 1 by 1. To view a move, you should select it and click the View button, which will load a new page with a different position. If you start from the beginning, it will automatically select the next move for you, so that you can go through a game just clicking on the View button.

I see. I was wondering if there was not something more user-friendly. On large board (e.g. 16x16), one has to scroll the screen to reach the view button and as the full board seems to be reloaded with few seconds latency, it is quite difficult to see if a piece has been taken. Going back to check is only possible by selecting the move in the list. Which is slow in long games.

Ideally, one would need a control zone with arrows to go back and forth. Thanks anyway, I will see if I can manage my study like this.

I used to see something like that on presets made with H.G. Muller's GAME-Code Generator, but when I went looking to see how it worked, I couldn't find any that did that anymore.

Presets automated with GAME code generated with the Play-Test Applet have such buttons to navigate through a game locally. At least if they include the JavaScript it suggests in the HTML rules section.

The problem is that this JavaScript cannot be used for other automated presets, because it is unaware of automatic side effects (i.e. board modifications not explicitly indicated in the move notation). Such as e.p. capture and castling. The GAME code from the Applet solves this by including a list of such moves as JavaScript array hidden in the preset page, which the navigation code then uses to see where it should apply side effects to the moves in the official move list that the user can see.

I understand the design choice of letting the navigation be handled by the server rather than locally through JavaScript was made for the benefit of users with JavaScript switched off. But it is a pity that the interests of such mostly hypothetical users goes at the expense of actually existing users like Jean-Louis and me, for which the server-side implementation is so woefully inadequate that it is totally useless, and I have long since accepted that in practice Game Courier just doesn't support navigation through existing games. (For me the problem existed even in small games, where no scrolling is needed, because long delays occurred in page loading due to adds present on the preset page, and even on a good day when such delays were seconds rather than minutes the board image would jump to different locations on the display from move to move. I doubt, btw, that users with JavaScript off would think the existing system satisfies their needs.

Presets automated with GAME code generated with the Play-Test Applet have such buttons to navigate through a game locally. At least if they include the JavaScript it suggests in the HTML rules section.

My Experiment preset has included the JavaScript you suggest, but it's not providing any navigation buttons. I added type="text/javascript" in case that would help, but it didn't. I also checked that JavaScript functions can overwrite other JavaScript functions with the same name, which is also how functions and subroutines work in GAME Code. So, trying to redefine functions is not the problem. Your MovePiece.js script comes after mine on the page and should overwrite any functions with the same name. So, I imagine something is broken in your script.

I understand the design choice of letting the navigation be handled by the server rather than locally through JavaScript was made for the benefit of users with JavaScript switched off.

Not quite. It is mainly that Game Courier is a server-side project with some client-side enhancements, which is in contrast to the Interactive Diagrams, which is a client-side project with some server-side enhancements. So, each does some things better than the other. Also, I don't have the same experience you have in client-side programming, and I more frequently approach things from the server-side. But I am interested in adding this as a further client-side enchancement to Game Courier.

Perhaps something changed in the layout of preset pages that broke things. The script tries to insert them into a HTML element with tagname 'kbd'. (The function AddButtons, which is called from GetPieces, which is called after a 500ms delay from GetMoves, does that. This is conditional on an array 'impmoves' being defined on the page, though. Which the betza.txt include would do, to relay which moves had implied side effects.)

The idea was indeed that the functions in movepiece.js would overrule those defined on the page (of which they are modified versions) earlier.

Perhaps something changed in the layout of preset pages that broke things.

I'm currently looking at your movePiece.js code. I see that GetMoves has this line:

  statuss = document.getElementById('statuss');

However, there is nothing on the page called statuss, and your code doesn't create anything with that ID.

I also think your code may be based on an old version of movePiece.js. While yours has the functions showLegalFrom() and showLegalTo(), mine uses the functions showAllLegal() and showNextLegal(). I do recall using the other function names at one time. Since I did not describe them with comments, it's just the function names and the code itself that might tell us the difference between these.

The statuss element is something I use while debugging; by having its object available in a variable it is easy to put error messages in the innerHTML there. After I had debugged the code the statuss element was removed (it would only be in the text part of the preset I used for debugging), and all displaying of error messages was removed, so it doesn't hurt that statuss is now undefined. I could have removed this line too, but leaving it in makes it easier to resume debugging in case of trouble.

If you changed the name of the routines called as event handlers for the mouse clicks on board squares, then you have indeed broken the presets using this code. Proper operation depends on the functions being called. That doesn't explain the non-appearence of the button bar, though, as this is done by the initialisation code, and is not triggered by mouse clicks.

I think most of the functions is the same as your originals; the reason I overruled thos was not because I wanted different behavior w.r.t. the mouse clicks. But l changed the HTML representation of the board on initialization, with the routine FixBoard: this makes the piece images background. I did that to get rid of the annoying expansion and contraction of board ranks when the rank became empty, or a piece on it got highlighted. But this means that the event handlers also have to modify the board squares in a different way in response to the clicks.

If you changed the name of the routines called as event handlers for the mouse clicks on board squares, then you have indeed broken the presets using this code.

The functions I mentioned are only called in movePiece(), and we each have different versions of that function. So, that might not be a problem. However, I did notice that your definition of movePiece() starts like this:

movePiece = function(c) {

Is that just an alternate way of defining a function, or does it make a difference?

I think the new functions I wrote were for the purpose of handling multi-part moves with a common first move. In games like Fusion Chess, it can pop up a requester asking which full move a player wishes to make.

That doesn't explain the non-appearence of the button bar, though, as this is done by the initialisation code, and is not triggered by mouse clicks.

Through testing with a copy that I can add alerts to, I found this line to be the problem:

  if(tabs.length < 2) return;

This appears just before AddButtons(); in GetPieces(). An alert works before this line but not after. Using an alert to report the value of tabs.length, it is 1.

By commenting out this line, the buttonBar shows up, but when I try to navigate through a game, it does nothing but clear the board.

@HG: in fact my current need is to study a game of Bigorra, which is very long with 245 moves. I need to see when and how a piece has captured another one. The game I study has been played on GC so I have its recording. Alas, on GC the captures are not recorded. This is why I need to scroll all the game along.

As you pointed out, scrolling with GC is not optimal. I wish I could transfer that game onto ID in order to scroll and replay it. Is there a way I can do that easily. When I simply paste the list of moves into ID I get an error. What should I do to get a list of moves understood by ID?

Thanks

@Jean-Louis: you could try to delete all spaces that separate the piece ID from the coordinates. You might have to remove the hyphen between the squares too (I am not sure about that). Of course it is essential that the Diagram would use the same piece IDs as GC; otherwise you should remove all those two. (Since GC notation always mentions the full origin coordinates, it should be redundant.)

I picked up this style of defining functions from Jocly; I now believe it is completely equivalent to the other method of function definition.

It was long ago that I wrote this, so I have to look it up now in the code as well. But 'tabs' is an array that holds all HTML table elements, and it is tested whether the first of these has id="board". The second apparently is expected to be a table of piece images, where the column headers are piece IDs, and the columns then contain the image. For the navigation to work, it needs to know the initial setup; this cannot be derived from the current position and the move list, as pieces could be captured before they moved. So the GAME code includes a FEN for it. Together with the move list and the knowledge of implied side effects that determines all positions in the game, in terms of piece IDs. But to display the position it needs to associate IDs with images. Some pieces in earlier positions might no longer be on the board in the current position, so it cannot get those from the board. Therefore it gets them from the table (function GetPieces).

But if the table is missing, there is nothing to get, and it cannot reconstruct earlier positions. Therefore it also doesn't create navigation buttons. If you make it create the buttons desppite the fact that it has no associations between IDs and images, the dislay function doesn't know what pieces to display. This explains why you see an empty board.

Apparently the page is no longer formatted as the code expects it to be.

I got it to work by rewriting GetPieces() like this:

function GetPieces() {
  // if(tabs.length < 2) return;
  AddButtons();
  for (let key in pieces) {
    pieceURLs[key] = dir + pieces[key];
  }
}

dir and pieces are new JavaScript copies of the PHP variables $dir and $pieces, which are normally defined in a set. They used to be in a showPiece() function, which I got rid of today, because as far as I could tell, nothing was using it, and there are other alternatives now. But I kept the lines defining these variables and gave them global scope.

OK. The navigation is further dependent on the presence of an array impmoves, which contains the FEN, and the number of all moves with implied side effects. In the GAME code generated by the Play-Test Applet these can only be castlings and e.p. captures. The JavaScript extracts the moves from the move list (on the page as a pulldown), and then marks all the implied moves by appending "; #" to them. When encountering such a marked move during navigation, it distinguishes castling from e.p. by the ID of the moved piece; if it is K/k it also moves the Rook, if not it removes the last moved piece.

It is imaginable, though, that some presets would have other moves with implied side effects (i.e. not written in the move list). E.g. Advancer or Withdrawer capture, burning by a Tenjiku-Shogi Fire Demon... So to meke this more generally useful it would be helpful if there was a second list of moves hidden in the page that would specify either all board mutations, or those not explicitly specified by the move list that is presented to the user. Together with a FEN of the initial position, and the list of images to use for the pieces, that would make local navigation possible as a standard feature for all presets.

I'm unable to use the mouse to select pieces in any of these games.

https://www.chessvariants.com/play/pbm/play.php?game=Atlantean+Coffee+House+Shatranj&log=arx-cvgameroom-2023-258-846

https://www.chessvariants.com/play/pbm/play.php?game=Bigorra&log=arx-cvgameroom-2023-268-989

https://www.chessvariants.com/play/pbm/play.php?game=Enhanced+Courier+Chess&log=sissa-arx-2024-17-995

https://www.chessvariants.com/play/pbm/play.php?game=Cetran+Chess+3&log=arx-sissa-2023-334-071

I'm unable to use the mouse to select pieces in any of these games.

Sorry, I made a typo today. It's now corrected.

I fixed yours yesterday to get a better idea of how it worked, but today I have been working on new code for doing the same kind of thing. I have had the new controls visible only to me so that the bugs I have to fix don't affect users. I have now made it visible to editors in general, though not others, so that you might take a look at what I have so far.

Instead of going in movepiece.js, I am writing code for individual parts of Game Courier. So far, the navbox that appears in View or Solitaire mode has controls above it. These controls affect the move shown in the box below, and for some shape/render combinations, they change the position on the board. So far, the square/table, square/css, and custom grid/css combinations support viewing past moves. Each does this with its own updatePosition() function, which is customized for how it displays the board. So, I have to do one combination at a time, and I don't think I'll be able to do it for boards rendered entirely as a single image.

Instead of calculating FENs based on the moves, I have had Game Courier produce an array called positions, which contains the position before and after every move, as well as information on the origin and destination of each move. It's able to use this to highlight not only the official origin and destination spaces but also any space that has changed from the previous move. To distinguish these from the main ones, I have made these additional borders circles. I then used it to view a game of Ultima, and it also highlighted the spaces pieces had been captured from.

Some things I still have to do are add controls to the form for moving in a correspondence game and stop legal moves from displaying for moves other than the current one.

Instead of calculating FENs based on the moves, I have had Game Courier produce an array called positions, which contains the position before and after every move, as well as information on the origin and destination of each move.

Because I had already used the name positions for the custom shape, I changed the new variable's name to posdata. Also, it only contained the position data before each move, and I added in the position data for after the last move after runsubroutine() completed. So, now the >| button works correctly.

I was wondering if there was not something more user-friendly. On large board (e.g. 16x16), one has to scroll the screen to reach the view button and as the full board seems to be reloaded with few seconds latency, it is quite difficult to see if a piece has been taken. Going back to check is only possible by selecting the move in the list. Which is slow in long games.

I have been working on this the past couple days, and my position navigation controls are now ready for public use. Buttons appear above the drop down list of past moves, and these control navigation through the moves. There are some differences in the buttons for viewing a game and making a move in a correspondence game. The former has options for moving back to the beginning, back two moves, back one move, ahead one move, ahead two moves, and ahead to the last move. When the current move isn't the last move, it also has a button for going to that move. Since the latter has moves a player cannot go back to disabled, it has buttons for going back or ahead one turn instead of one or two moves. For the shape/render combinations of square/table, square/css, and grid/css, selecting a move with either the drop down list itself or with the buttons for navigating through it, the position will change to match the selected position. For other shape/render combinations, the buttons will facilitate navigation through the list of past moves, but they will not change the position of the pieces on the board.

You can view legal moves only for the move initially shown. While this is usually the latest move, Game Courier has long had the ability to view past moves through its usual server-side interface. When viewing a past move this way, you will be able to see the legal moves for it (assuming its preset supports them), but you will not be able to see positions past it, because to calculate the legal positions for that move, Game Courier stopped early and did not calculate the later positions. So, to view every position of a game in the new JavaScript-aided manner, you should start by viewing the latest move in the usual server-side manner.

This is a nice improvement to Game Courier, Fergus. A lot of chess sites have used similar buttons for viewing the playback of a recorded chess game, for a number of years now.

What would make this even better is being able to use the arrow keys to navigate the game history.

Isn't that what it already does? Or do you mean something other than navigating through the past moves of a game?

I think Daniel means to be able to use the 4 arrow keys on a keyboard (rather than clicking on arrow-buttons with a mouse). I guess that could be doable, especially if exactly 4 (or less?) options to choose from with the keyboard arrow keys is all that's ever wanted for a given application. At the moment you've got six options with the arrow-buttons you've placed for GC navigation.

Yeah, I mean using the keyboard arrow keys.

That could be hard. I think there are security issues with reading the keyboard from JavaScript, and that it is therefore forbidden, unless you give focus to a HTML element that obviously allows it (i.e. a text input) with the mouse.

Yeah, I mean using the keyboard arrow keys.

This is already working without explicitly adding support for it. The trick to it was that the drop down menu required focus before you could use arrow keys to navigate it, and while clicking on a button was changing its value, it was not giving it focus. I fixed this by giving focus to the SELECT element whenever a button above it is clicked. Once you give it focus, whether by clicking on it or on one of the buttons above it, you can navigate through it with the keyboard. The left arrow, up arrow, and PgUp button all move the selected line up, which takes it back to previous moves. The right arrow, down arrow, and PgDn button all move the selected line down, which moves it ahead to later moves. Also, the Home button takes it to the first move, and the End button takes it to the last move.

Dear Fergus, thanks for your effort. Alas, I'm not able to operate it. It works to show the diagram for a given move, but then when I try to go ahead or back I see no change on the diagram. I'm reading your explanation but I don't understand what you have written. Your answer is so complex, I'm lost. I'm going to see if I can manage it with ID. Thank again anyway.

The arrow buttons for playing forward or back the moves don't seem to be working now for me, too. It was working two days ago, if not yesterday as well.

I just tested it with the only available game of Bigorra, and it works easily. Start by going to the first move with the |< button, and then go to subsequent moves with the > button or with the down arrow key.

The arrow buttons for playing forward or back the moves don't seem to be working now for me, too. It was working two days ago, if not yesterday as well.

Make sure your rendering method is either CSS or Table and that your shape is either Square or Custom Grid. It will not work for rendering methods that draw the entire diagram as a single image, as GIF, JPG, and PNG do. Also, I have not added support for hexagonal, circular, or spherical boards.

@Fergus: rectification. When reviewing the game from the first move, it works. Good. Thanks

Note that you made your preset for Bigorra with H. G. Muller's Game-Code Generator, and it includes his alternative movepiece.js file. You should remove this from your preset and from any other preset that includes it, because it was designed for his earlier and unrelated system for navigating through past moves, which is not working because of some conflicts with how Game Courier currently works, and it replaces functions from my more up-to-date movepiece.js script.

The following is a link to a game log I looked at where the arrow-buttons didn't work today (other game logs I tried, so far, didn't have the problem, now that I looked at a few more of them) - it's for a CV played on an 8x8 board with 4 armies controlled by 2 players, though I didn't check too carefully how it renders the diagram (says PNG in one place), as it's not a preset I made myself:

https://www.chessvariants.com/play/pbm/play.php?game=4-Handed+Chatarunga&log=panther-zcherryz-2022-123-934

Looks like there is no much coordination between you Fergus and HG, at least something I can feel, and this is too bad for non-expert in computer people like me. HG's applet has been a real help for me. Without it, I would be unable to make a preset alone. Now, I understand that I would have to modify my presets, if this is true it is a very bad news. I have this : script src="/membergraphics/MSgame-code-generation/movepiece.js"> at the end of the preset page. Shall I simply remove this? To put what instead? And what will be the consequence? Will the old games still readable? Any impact on on-going games?

JavaScript can change the pieces on the board only if they are represented by individual images. But the PNG rendering method does not use individual piece images. It displays the whole diagram as a single image like the Diagram Designer does. In many cases, such as this one, all you have to do is change the rendering method to either Table or CSS, and then you can use JavaScript to display past moves without reloading the page for each move.

I have this : script src="/membergraphics/MSgame-code-generation/movepiece.js"> at the end of the preset page. Shall I simply remove this?

Yes.

To put what instead?

Nothing. It is just an alternative version of a script that Game Courier already runs.

And what will be the consequence?

Better performance, because it will not interfere with or replace any functions in the official movepiece.js script.

Will the old games still readable?

Yes.

Any impact on on-going games?

No.

The new CG feature that Fergus added implements largely the same as what before was only possible through movepiece.js, and might conflict with it. I will check whether I should simply remove that file from the server (so that presets trying to link with it won't get any code to overrule the new standard feature), or that there still is some role left for it to play. But on the tablet I have on me I don't even know how to view page source, so it will have to wait.

@HG @Fergus

For the moment, I can't edit any GC Preset file. I don't know why. I get only a blank white page whichever the GC I'm trying to edit. What's wrong?

Yes, right now when I click onto Edit Mode from a preset (mine or someone else's) I have the same trouble - even with a non-rules-enforcing Game Courier preset (naturally not generated by the Play-Test Applet).

For the moment, I can't edit any GC Preset file. I don't know why. I get only a blank white page whichever the GC I'm trying to edit. What's wrong?

It was trying to use some variables that were set only when it runs GAME Code, but in case GAME Code has an infinite loop or some other error that stops it from working, Edit mode runs without running any GAME Code. So, the problem was caused by expected variables not being set. I have now put this code in a conditional that works only when GAME Code has run and set the expected variables.

Regarding the ability to navigate through past moves, I have now gotten it to scroll up the comment for the selected move so that it will be visible once you select the move.

To make it easier to annotate a game, I have added the navbox for moving through the positions to the Annotate form.

In this game you can see that the new navigation system does not account for piece recoloring.

In this game you can see that the new navigation system does not account for piece recoloring.

I'm meaning to eventually get to that. Today I've been working on something else. I've started working on using drawdiagram.php in conjunction with the CSS method to support hexagonal boards. It's drawing an empty board on which I can overlay pieces, but I'm currently having difficulty aligning the pieces with the board.

I'm meaning to eventually get to that.

When you do, can you also add the move back/forward 1 move buttons to the page where you make a move in one of your games? It seems to be missing from that page.

Also, when I try to promote a piece in a log (such as in this log with W 13j-12k; +W-dest), when I click Preview, it redirects to a blank GC preset page.

When you do, can you also add the move back/forward 1 move buttons to the page where you make a move in one of your games? It seems to be missing from that page.

The movenum select element on the page for moving in an ongoing game was originally designed to allow players to take back moves, and since you cannot play as your opponent, it was set up to disable each move you made so that you could only select a last move by your opponent and then make a new move. However, this will still be stopped even if I enable all the past moves and provide one step buttons. So I'll consider it.

when I try to promote a piece in a log (such as in this log with W 13j-12k; +W-dest), when I click Preview, it redirects to a blank GC preset page.

That's weird. After getting the same result, I looked at the HTML code for the form, and I saw nothing amiss. It included values for game, settings, and log.

I tested Shogi to see if it happened there. It did not, though it was using ask instead of askpromote to just ask if you wanted to promote.

Since Chess now handles promotion differently than it used to, I tested Marseillais Chess, which is using an older include file that still uses askpromote. I marched up two Pawns, and it worked fine for both of them.

Turning back to the HTML of your form, I did see that positions had a value, which was unusual. This is used only for the Custom shape, but you were using the Square shape with Table rendering. I did briefly use the $positions variable for what I renamed $posdata before I noticed it was already in use. But using grep to see where I might be misusing $positions didn't turn up anything suspicious. But it did occur to me that during the brief time when I was using the $positions name for $posdata, it could have gotten recorded in your log. That did happen, making your log really huge. I deleted the line, and that fixed things. So, I expect it was such a huge line, it wasn't recorded in full, and this broke your form. I wonder if I'll have to do something to compress the $posdata value for large games like this. In my initial test, it seems to be working fine for your game. I was able to go through the moves in your game from start to finish.

Okay, it works now.

As for the Navigational panel, it's not a huge deal, but it just seemed weird to me that those buttons were missing.

In this game you can see that the new navigation system does not account for piece recoloring.

It does now, though I see I have to do something about the size of SVG images in the Captured Pieces area.

This is more behind-the-scenes stuff, but it will decrease file size. Instead of storing every single full position in the posdata JavaScript variable, it will now store only the original position in full, and it will store each subsequent position only as its differences from the previous position. I got this to work by writing a JavaScript function called getPosition, which calculates a position by starting with the original position and going through all the changes up to the specified position.

I encountered a few bugs while working on this today. At first I wrote a getPiece function, but that wasn't working out when I tried reducing the position data to only what is essential. Then getPosition would work some of the time but eventually break down. I realized that when I copied an array in JavaScript, it was making a reference to the array instead of a fresh copy. So, when I changed what was supposed to be a copy, I also changed the original array, which really messed things up. So, I wrote the function to start with a fresh array I simply populated with values from the original array. This worked, and I made other corrections to get everything working.

If captured pieces are calculated by subtracting the current pieces from the original pieces, then they will be sorted in the order of increasing frequency among the original pieces. Unlike sorting them in alphabetical order, this provides some kind of approximation of their relative value. However, it does not provide any hint of the relative value of pieces appearing in the same frequency, such as Knights, Bishops and Rooks in Chess.

Both the presets for Apothecary Chess Classic and Modern are not allowing selecting pieces with the mouse.

Both the presets for Apothecary Chess Classic and Modern are not allowing selecting pieces with the mouse.

I don't know why other games weren't affected, but I have managed to fix the problem. You should refresh your cache, since I updated movepiece.js.

It seems to not be possible to undo an illegal first move by reverting to the starting position. Could this possibly be changed?

When using the table rendering method, highlighted squares don't stay the same size as unhighlighted squares so the board ends up shifting around a lot when looking at move options. Is this fixable? At least the css rendering doesn't have this problem

When using the table rendering method, highlighted squares don't stay the same size as unhighlighted squares so the board ends up shifting around a lot when looking at move options.

This depends on the size of the individual piece, though some sets, such as Alfaerie, maximize the dimensions of the piece images, so that you may see this effect for every piece.

Is this fixable?

If you made your spaces larger than the largest pieces, you might leave enough room for a border around the piece image without expanding the size of the space. 54x54 might work better than 50x50, for example. However, the square size for the Table method is determined by the $height and $width values, which are provided in the set file, and these are usually set to 50 for the Alfaerie sets.

At least the css rendering doesn't have this problem

One of the reasons to start favoring the CSS rendering method.

Is this fixable?

It is easily fixable, and I think fixing it is long overdue, as it looks very amateurish.

The fix is to display the piece images not as content of the table cells, but as background. So instead of something like

<td style="width:50px;height:50px"><img src="xxx"/></td>

you would generate something like

<td style="width:50px;height:50px;background-repeat:no-repeat;background-position:center center;background-image=url(\"xxx\")"></td>

(where the extensive style specification can of course be achieved through a CSS class). You can then highlight through a border with negative margins. This is how I got rid of these annoying expansion/contraction effects in the Interactive Diagram. (But there I highlight by small symbol images displayed as content of the cell.)

If the cell backgrounds have transparent parts, you see either the specified cell background color there. Or, when no valid color is defined, the background of the surrounding (<table>) element. So you can still use full-board images as background.

The problem is that browsers refuse to fit 50x50 images in 50x50 cells, because they align the bottom of the image with the text line it is on, and text lines need extra space below them for the 'true descenders' on letters like j, p and q. So they always leave some space below the image, even if there is no text at all in the cell. How much depends on the font size that currently applies, but it is not possible to set that to 0.

The fix is to display the piece images not as content of the table cells, but as background.

I saw you doing that for Interactive Diagrams and applied this solution to the Square CSS format. But I did not apply it to the Square Table format, because this is supposed to be an HTML format that will continue to work with older browsers. So, to fix this, I have employed an entirely HTML solution.

The solution in place now is that it reduces the height and width values in the img tag used to display a piece that is too large for the square size. The maximum height or width a piece may now have in the Square Table format is ten pixels less than the $height and $width values. I had to work out some kinks with pieces displayed with showpiece.php. The getimgsize() function, an alternative to GD's getimagesize() function that will work with script-generated images, was not using the correct file name, and I corrected that.

The problem is that browsers refuse to fit 50x50 images in 50x50 cells, because they align the bottom of the image with the text line it is on, and text lines need extra space below them for the 'true descenders' on letters like j, p and q.

I don't think this is true. Each piece image is centered in its table cell. The problem was that when borders are used to highlight pieces, the borders sometimes extend beyond the size of the table cell, causing it to expand in size. By putting a cap on the size of the images, I have stopped this from happening.

That does look better for smaller games. For larger games (like 16x16 Bigorra) where the scale might need to be reduced to see the whole board at once, the images can look too tiny with Table, but that wouldn't matter except that with CSS they don't scale down at all. PNG does scale the pieces correctly, but with that the highlight squares don't line up with the board squares.

If you set the scale to 120, and you're using a set of pieces that are all 50x50, such as Alfaerie, it should give you normal size pieces on a slightly larger board. So, now, there are three options for keeping the image borders confined to the space the piece is on.

1. Using Square Table at scale 100, the board will remain the same size, but the pieces will be smaller.
2. Using Square Table at scale 120, the pieces will be normal size, but the board will be a bit bigger.
3. Using Square CSS at scale 100, the pieces and the board will be normal size, but there will sometimes be overlap between the border used to highlight a space and the piece on that space.

Each option produces a side effect, and it's a matter of choosing which one is least disagreeable to you.

but that wouldn't matter except that with CSS they don't scale down at all.

Since you pointed it out, I have fixed scaling for Square CSS.

PNG does scale the pieces correctly, but with that the highlight squares don't line up with the board squares.

I fixed that too.

Thanks! Much better now

Another strange css thing: in this game using Alfaerie: Many CSS rendering results in some of the black pieces being white.

It's too late for me to work on this tonight. Many Black pieces turned white, and I examined the Black King, which had this code:

grid-area: r12 / f6; background-image: url(/play/pbm/showpiece.php?image%3D%2Fgraphics.dir%2Falfaerie%2Fbking.gif%26size%3D50)

The strange thing is that there is nothing in the query string about changing color, and the piece is originally black. And here is an image link to the piece just to confirm:

And it looks like the piece is transparent. I'll look into that more tomorrow.

This happened because of changes I made to make sure that Square CSS did resizing correctly. To resize a piece, it uses the CSS property "background-size: contain", which will stretch or reduce a piece to fit the space. But this works correctly only if all the pieces have the exact same dimensions. But the pieces I have made for my own sets, such as Abstract, Motif, and Magnetic, are optimized to the dimensions of the actual image drawn, which will vary from piece to piece. For small pieces, such as Pawns, a background-size of contain will cause them to appear as large as other pieces. To prevent this, I employed showpiece.php to pad pieces whose dimensions fall below the $height and $width values specified in the set. This makes them all the same size, so that using a background-size of contain is an appropriate way to resize them.

The problem with these old Alfaerie pieces is two-fold. First, many of them have dimensions of 49x49 instead of the 50x50 specified for the Alfaerie: Many set. Because of this, they are now being sent to showpiece.php for padding. The other problem was that they were not following the convention of using pure green (#00FF00) for the background color. Because of this, the script was losing track of which color was supposed to be transparent, and it was making the wrong color transparent. I corrected this with code that finds the transparent color and sets it to green before the padding of the image is done. That code looks like this:

    // Assure that background is green
    $trans = imagecolortransparent($img);
    if ($trans == -1) {
        $trans = imagecolorat($img, 0, 0);
    }
    imagecolorset ($img, $trans, 0, 255, 0);

With this change made, the pieces are now showing up properly.

The fix I made for Alfaerie GIFs being transparent is now broken thanks to a fix I made yesterday for Alfaerie PNGs with black borders.

Due to the way the Square CSS method handles resizing, both are being passed to showpiece.php for padding due to being slightly undersized. Padding involves the creation of a second larger image onto which the original image is copied to the center. Before yesterday's fix for the PNGs, it would first fill the new image with the transparent color. Since that fix, it will first copy the image, find the transparent color again, and fill in the edges. But something is going wrong with the GIFs, and I am working on trying to fix it.

In both instances, the images are not following the conventions Game Courier expects from piece images. Neither the GIFs not the PNGs are following the convention of using pure green (#00ff00) for the transparent color, and the PNGs are truecolor instead of palette images, which prevents the use of imagecolortransparent for finding out which color is transparent.

Both appear to be fixed now. I had to color the new image green before copying the original image to it. Otherwise, some pixels in the original image might match the background color of the new image. Taking out the lines for filling it with the transparent color after copying the image fixed the problem with the PNG King's cross being partially transparent. What I needed to keep were the lines for identifying the transparent color in the new image.

So, the padding works like this.

1. If the image is true color, it gets converted to a palette image.
2. It identifies the transparent color in the original image. It first tries imagecolortransparent, then it looks for pure green, and if neither of those work, it assumes the color at (0,0) is transparent.
3. It changes the RGB values of the transparent color to green (#00ff00).
4. If either dimension of the image is below the value of $size, it creates a new $size x $size palette image.
   1. It colors this image green.
   2. It copies the palette of the original image to the new image.
   3. It copies the original image to the new image at a centered location.
   4. It recalculates the new image's transparent color in the same manner as before.
   5. It copies the variable for the new image to that of the original image.
   6. It destroys the original image.
5. When it outputs the image, it assigns the transparent color to what was previously calculated to be the transparent color.

Currently, when I have changed the appearance settings for a game, after I confirm a move or if I cancel a previewed move, the appearance reverts to the default settings.

Currently, when I have changed the appearance settings for a game, after I confirm a move or if I cancel a previewed move, the appearance reverts to the default settings.

The Cancel button is on its own form, and it will cancel everything except the comment you wrote. This includes any changes to the appearance.

The Confirm button was being missed by some new code fixing another problem, because the value of the Confirm button is still Send, and I was checking for a value of Confirm. When I changed it to check for a value of Send, it worked.

Many alfaerie pieces are invisible now using css rendering.

Many alfaerie pieces are invisible now using css rendering.

I just looked at the page you pointed me to last time Alfaerie pieces were transparent, and I saw no problem with them when I switched it to CSS. So, where are you seeing this?

This game and also this for example.

What I saw happening in the first example is that many images were broken. While they were invisible on the board, I could see the broken image icon littering the Captured Pieces area. This is because I had replaced GD's imagetruecolortopalette with my own imagetruecolortopalette2, which I noticed I had written to do the same thing while preserving the alpha values of individual pixels. But I had forgotten and didn't notice that these two functions took different parameters. So, just changing the function name broke the script whenever it was called. When I also filled in the correct parameters, it worked. I downloaded one of the images it produced, and when I examined it in Ultimate Paint, I could see that individual edge pixels had different alpha values, which makes the piece look smoother, and it was a 50x50 palette image with a smaller file size than the 48x48 true color image it was based on. When I checked the second example, there was no longer any problem.

thanks!

I made an inventory of the Alfaerie PNG pieces we currently have, in particulare what is the difference between the set in the alfaeriePNG directory (which are mostly 48x48) and that in the alfaeriePNG50 directory (which is the entire alfaerieSVG directory rendered as 50x50 PNG). By first redirecting the output of an 'ls' command to a file in each of these directories, then letting the 'diff -u' command compare them, and finally extract the omisisons and additions by using 'grep' for lines starting with + or -, I created the following table. The + refers to files that are in alfaeriePNG50, but not in alfaeriePNG, the - means the opposit.

-bbishopinv.png
-bcamelknightferz.png
-bcardinalinv.png
-bchancellorinv.png
-bcircle2.png
-bcircle.png
-bcobra.png
-bcoordinator2.png

-belephantknight.png
-belephantrook.png
-belephantwazirbishop.png
-belephantwazircamel.png
-belephantwazirknight.png
-belephantwazirrook.png
-bfiredragon.png
-bgnu.png
-bkinginv.png
-bknightdabbabah.png
-bknightferzdabbabahrider.png
-bknightinv.png
-bpawninv.png

-bqueeninv.png
-brookinv.png
-bvao2.png
-bviper.png
-bwarmachineriderferzcamel.png
-bwarmachineriderferzrook.png
-bwarmachinerider...
...generalelephant.png
-bzebrawazir.png
-gcircle2.png
-gcircle.png
-rcircle2.png
-rcircle.png

-wbishopinv.png
-wcamelknightferz.png
-wcardinalinv.png
-wchancellorinv.png
-wcircle2.png
-wcircle.png
-wcobra.png
-wcoordinator2.png
-wcrooked.png
-welephantknight.png
-welephantrook.png
-welephantwazirbishop.png
-welephantwazircamel.png
-welephantwazirknight.png
-welephantwazirrook.png
-wfiredragon.png
-wgnu.png
-wkinginv.png
-wknightdabbabah.png
-wknightferzdabbabahrider.png
-wknightinv.png
-wpawninv.png
-wpegasus.svg
-wqueeninv.png
-wrookinv.png
-wvao2.png
-wviper.png
-wwarmachineriderferzcamel.png
-wwarmachineriderferzrook.png
-wwarmachinerider...
...generalelephant.png
-wzebrawazir.png

+bcamelbishopwazir.png
+bcamelgeneral.png
+bcamelriderferz.png
+bcamelridergeneral.png
+bcamelriderguard.png
+bcamelriderwazir.png
+bcamelrookferz.png
+bcamelzebra.png
+bchancellor_test.png

+belephantferzhero.png
+belephantgeneral.png
+belephantridergeneral.png
+belephantwazirwarmachine.png
+bgeneral2.png
+bgreatwarmachinegeneral.png
+bknightgeneraldabbabah.png
+bknightgeneral.png
+blemurianelephantferz.png
+blemurianwarmachinewazir.png
+bnarrowknightgeneral.png
+bnarrowknightwarmachine.png
+bnarrowknightwazir.png
+bnightriderferz.png
+bnightridergeneral.png
+bnightriderguard.png
+bnightriderwazir.png
+bsquirrelferz.png
+bsquirrelwazir.png
+btank.png
+bwarmachinegeneral.png
+bwarmachineridergeneral.png
+bwideknightferz.png
+bwideknightgeneral.png
+bwideknightwarmachine.png
+bwideknightwazir.png
+bzebrageneral.png
+bzebraguard.png
+bzebrarook.png

+wcamelbishopwazir.png
+wcamelgeneral.png
+wcamelriderferz.png
+wcamelridergeneral.png
+wcamelriderguard.png
+wcamelriderwazir.png
+wcamelrookferz.png
+wcamelzebra.png
+wchancellor_test.png
+wcrookedbishop.png
+welephantferzhero.png
+welephantgeneral.png
+welephantridergeneral.png
+welephantwazirwarmachine.png
+wgeneral2.png
+wgreatwarmachinegeneral.png
+wknightgeneraldabbabah.png

+wlemurianelephantferz.png
+wlemurianwarmachinewazir.png
+wnarrowknightgeneral.png
+wnarrowknightwarmachine.png
+wnarrowknightwazir.png
+wnightriderferz.png
+wnightridergeneral.png
+wnightriderguard.png
+wnightriderwazir.png
+wsquirrelferz.png
+wsquirrelwazir.png
+wtank.png
+wwarmachinegeneral.png
+wwarmachineridergeneral.png
+wwideknightferz.png
+wwideknightgeneral.png
+wwideknightwarmachine.png
+wwideknightwazir.png
+wzebrageneral.png
+wzebraguard.png
+wzebrarook.png

There are quite some more differences than I would have expected. Apparently there are a lot of SVG images that have not been incorporated in the PNG set. Mostly 'ferzed' or 'wazired' versions of existing mimages, by drawing a cross on those.

The PNG set has a number of inverted images, which were no doubt made by rendering the normal SVG upside-down with the aid of fen2.php. It has also a gnu, as a knight-camel composit, and many elephant composits. These were probably all made with the aid of fen2.php's ability to combine two images.

The white crookedbishop was wrongly named in the PNG set. The bknightgeneral is missing from the PNG set, which has a wknightgeneral. There is a wpegasus.svg file in the PNG directory, which doesn't belong there.

The best approach is probably to just copy all the PNG50 files to the PNG directory, which will make all the files in the rightmost two columns available, and replace every image not in the left two columns by their 50x50 equivalent. Then only the images in the left two columns might have to be reconstructed at 50x50 through a more dedicated action than just rendering an SVG. Although some of these already are 50x50.

[Edit] I remade all the remaining images, so all alfaeriePNG are now 50x50.

On my mobile, Samsung, the piece icons on Game Courier on ongoing games have become very small. Barely visible. I think it was not like that before.

On my mobile, Samsung, the piece icons on Game Courier on ongoing games have become very small. Barely visible. I think it was not like that before.

Are you using Alfaerie pieces with the Table rendering method? To stop borders from expanding beyond the space a piece is in, this method will now reduce pieces in size just enough to make room for the borders. For pieces with optimized dimensions, such as Abstract, Magnetic, and Motif, this affects only the largest of pieces. But since Alfaerie pieces have uniform dimensions no matter how big the visible image is, they are all reduced in size. If this makes pieces too small for you, you can switch to the CSS rendering method, which does things in a manner better suited for piece images with uniform dimensions.

Yes the games I'm playing are made with Alfaerie. The rendering method is Table. If I change and set it to CSS, when I re-load, it comes again to Table with very tiny icons.

So I can't play with my mobile. I discovered this this morning. Until that day, I was able to play. I don't know what you have changed and for which reason, but for me it is not good.

If I change and set it to CSS, when I re-load, it comes again to Table with very tiny icons.

If you're literally reloading the page, that would be a mistake. You should submit the form and load a new page.

I don't know what you have changed and for which reason

I just told you in my previous comment.

Anyway, I have modified it to crop images with extra space, and now the pieces are showing up at normal size. The only downside is that the image cropping seems to take a few moments to complete. At least I saw a delay between showing the Black pieces and the White pieces in Chess.

There is also an issue where the spaces increase in height from 50 to 60 when I deselect a piece. I have not figured out why this is happening, but it does seem to be unrelated to my new code for cropping piece images.

"If you're literally reloading the page, that would be a mistake. You should submit the form and load a new page."

I don't see how I can do otherwise. I go to Rendering box, I get a menu. I select CSS instead of Table, then nothing change with the diagram. I see no special button to "submit" or something like that, so I reload and the diagram has still small icons and the rendering is back to Table.

"I just told you in my previous comment"

Where?

"Are you using Alfaerie pieces with the Table rendering method? To stop borders from expanding beyond the space a piece is in, this method will now reduce pieces in size just enough to make room for the borders. For pieces with optimized dimensions, such as Abstract, Magnetic, and Motif, this affects only the largest of pieces. But since Alfaerie pieces have uniform dimensions no matter how big the visible image is, they are all reduced in size. If this makes pieces too small for you, you can switch to the CSS rendering method, which does things in a manner better suited for piece images with uniform dimensions."

Sorry I don't see where in this text what you have changed and why.

The pieces are about 1/3 in L and 1/3 in h compare to one square dimensions. So too small for me but also too small for anyone with a similar mobile I think.

I don't see how I can do otherwise. I go to Rendering box, I get a menu. I select CSS instead of Table, then nothing change with the diagram.

Of course nothing changes. This is an HTML form that calls a PHP script to redraw the board. If you reload the page, it will just reset the form, which is the opposite of what you are trying to do. For the values in the form to do anything, you must submit the form.

I see no special button to "submit" or something like that, so I reload and the diagram has still small icons and the rendering is back to Table.

Yes, you do see the submit button, but you are overlooking it because it doesn't say "Submit". It is the same button you would use to submit your move. During the course of playing a game, this may be "Preview" or "Move". When viewing a game, it would be "View".

The pieces are about 1/3 in L and 1/3 in h compare to one square dimensions.

I'm looking at it on a small phone, and I see what you mean. While the code I added will fix the display on my desktop, it doesn't fix things when the squares are greatly reduced in size.

"I just told you in my previous comment"

Where?

"Are you using Alfaerie pieces with the Table rendering method? To stop borders from expanding beyond the space a piece is in, this method will now reduce pieces in size just enough to make room for the borders. For pieces with optimized dimensions, such as Abstract, Magnetic, and Motif, this affects only the largest of pieces. But since Alfaerie pieces have uniform dimensions no matter how big the visible image is, they are all reduced in size. If this makes pieces too small for you, you can switch to the CSS rendering method, which does things in a manner better suited for piece images with uniform dimensions."

Since reducing the size of a piece does not work well for spaces that are already reduced in size, I have turned off this behavior when the board is already being displayed at a smaller size. I tested this on the small phone, and the pieces became appreciably larger.

"Of course nothing changes. This is an HTML form that calls a PHP script to redraw the board."

@Fergus: I'm not an informatician. I come here to read and play about chess variants not to discuss computer science. I don't know what PHP script is and I don't think it is necessary to know to play Tigrey or Timurid chess.

Today I play with my McBook and what I see is that is has become very slow to display a 10x10 or 12x12 board on my screen.

The important thing for you to know about PHP is that it is a server-side language. That means it runs on the web site, not in your web browser. Game Courier uses forms to pass data to programmable web pages. These pages run their code on the server and send only their output to your web browser. While Game Courier is enhanced by JavaScript, a client-side language that does run in your browser, it does not use it to entirely redraw the board.

While you don't need to know how to program, it is basic computer literacy to understand the difference between server-side and client-side scripts. Server-side scripts produce web pages, and bscause they run on the server, they can output the same web pages to any web browser. Client-side scripts run on web pages. They rely on your browser knowing the language, and because of differences between browsers, code that works in one browser might not work in another.

You are a bit too hard on our non-programmer users. Since Game Courier is partly implemented server side through PHP, and partly client side through JavaScript it is not really possible to know what task is done where if you don't know the exact details of the implementation.

For clarity: the rendering method is decided server side, (so communication with the server is needed to chage it), and only the Table and CSS rendering method, once provided by the server, would allow you to move pieces through mouse clicks.

BTW,  isn't it possible to make the system more user friendly by automatically requesting a new page load when someone changes the setting of the render method? It should be possible to attach a JavaScript event handler to such a change of the selected item.

Since you moved the pieces from alfaeriePNG50 to alfaeriePNG, I used the alfaeriePNG50 directory for my own conversions with showpiece.php. The main difference is that the images it produced are palette images instead of true color. However, they still have varying alpha values for the edge pixels, and in many cases, they may appear identical to your pieces. After downloading and examining the individual pieces, I found that some black pieces were not recolored properly. These include

• bbadger.png, which looks grainy in its coloring.
• bcamelrook.png, which has a white rook.
• bcamelrookferz.png, which has a white rook.
• bchancellor.png, which has a white rook.
• bchancellorferz.png, which has a white rook.
• bchancellorrider.png, which has a white rook.
• bforwardchancellorprince.png, which has a white rook.
• bforwardrookbackwardsprince.png, which is white.
• bkingrook.png, which has a white rook.
• bzebrarook.png, which has a white rook.

Since it's consistently the rook part that is white in most of these, I'm thinking there is a problem with the SVG files. However, when I checked some of your conversions, I did not find the same problem. And when I checked the SVG code for some of these, I couldn't spot where a different color than #f9f9f9 was used for the fill color. So I'm not sure what is causing this.

Just to be sure I understand what is going on: showpiece.php also renders the white SVG files as a raster bitmap, after replacing the #f9f9f9 by some other color? And then saves this bitmap as a PNG image with palette encoding?

I know for sure that all areas of the images you mention that must be recolored are filled with #f9f9f9. Otherwise the rendering of the black pieces with fen2.php would not have worked. But there the inside of the Rook is always blue.

So the problem is not in the SVG; it must be in showpiece. It must overlook one of the #f9f9f9 strings when it replaces those. That it always does it in the Rook part suggests that the string is in some special context there that prevents it from being recognized by the substitute command. These images are all composits, and they were probably made by Greg (I usually relied on fen2.php's ability to combine SVGs on the fly, without first making SVG for those) with Inkscape by combining the existing SVG images of the pieces they combine. Perhaps this combining created the context that prevents the recognition of the color string.

The bbadger.png looks weird. I suspect something has gone wrong in creating the palette. Perhaps an overflow of the number of colors. It is all the pixels that would interpolate blue and black that seem to be missing.

To get a better idea of what's going on, I used showpiece.php to make SVG pieces for the black pieces. These were all colored appropriately. However, looking at the SVG for the black badger, I do see white outlines around most of the blue areas.

Since showpiece.php handles conversion of SVGs to PNGs with different code than it handles mere processing of SVGs, I looked at the difference between these. Each used str_replace for changing the color of the SVG, but each used it with a different condition. I changed the condition for converting to PNG from ($oc != $nc) to !samecolor($oc, $nc), but when I converted the SVGs to new PNGs, I still had the same miscoloring issues.

Since I now had black SVGs, I changed my script to convert each SVG into only one PNG. When I downloaded the results, I still found the same miscoloring issues. This time, though, I knew the SVGs they were based on were not miscolored. I may try to make my imagecreatefromimagick2 function simpler and see if that makes a difference.

If you open the newly made black badger in a text editor, do you see a white color anywhere in the text? When I look at the original SVG the stroke color around the eyes is #f9f9f9. All other stroke colors are #000000, but there are a few areas that specify "stroke:none". Perhaps the latter cause the problem?

If you open the newly made black badger in a text editor, do you see a white color anywhere in the text? When I look at the original SVG the stroke color around the eyes is #f9f9f9. All other stroke colors are #000000, but there are a few areas that specify "stroke:none". Perhaps the latter cause the problem?

I did a search and replace on the black badger, and that fixed it.

So what did you replace, and by what?

I finally got all my size 50x50 PNGs to display correctly. One of the things that was stopping me from seeing any progress was that it had cached the images I had created previously, and it was giving me those instead of creating new images. I got around this by adding a uniqid to the query string for showpiece.php.

I then saw that bknightferz.png and bknightgeneral.png were white. Checking the SVG files, I found them using #ffffff for the fill color. So I changed this to #f9f9f9 for the white images and #5984bd for the black images and uploaded them. After redoing these, the PNGs looked correct.

The one remaining issue is that desertferz and desertwazir each have a gray piece, though maybe this is intentional. So I left these alone.

So what did you replace, and by what?

I replaced "fill:none" with "fill:#5984bd" in bbadger.svg and "fill:#f9f9f9" in wbadger.svg. I uploaded both corrected files and used them to generate new PNG files.

I replaced "fill:none" with "fill:#5984bd" in bbadger.svg and "fill:#f9f9f9" in wbadger.svg. I uploaded both corrected files and used them to generate new PNG files.

That is not the correct thing to do, and will alter the image. To figure out what these invisible strokes are, I replaced 'none' by #ff0000, and then I get:

So it seems these invisible outlines cover partly the black, and partly the white areas. It would be less critical if you would first reduce the stroke width to 1.

There must be a bug in the SVG rendering routine that it cannot handle the 'none'.

That is not the correct thing to do, and will alter the image.

Here are the badger PNGs I made:

And here are the ones you made:

They look the same.

To figure out what these invisible strokes are, I replaced 'none' by #ff0000, and then I get:

By replacing every remaining none with the fill color, I get these:

By replacing every remaining none with #000000, I get these:

In my opinion, the first ones look best. So I don't think I made any mistake here.