Comments/Ratings for a Single Item

oops, this is it

Your link is missing a query string.

something seems wrong with this game. The code is just copied from Chinese Chess with some pieces added, so I don't think I changed anything important, yet it's saying I'm in check when I'm not.

Since the fairychess include file uses a shortcode to display pieces, I changed how the shortcode works instead of any code in the fairychess include file. I modified it to include WIDTH and HEIGHT values in the IMG tag when the image is an SVG image. These will be equal to $width and $height when these variables have values, as they usually do in Game Courier, and they will be 50 otherwise.

When fairychess is allowed to fill in the rules section for a game that uses svg piece images, some of the pieces end up being much larger than the others. This seems to be because the image is sized according to the piece name, even if the name is very long. Having the css explicitly set the image size could solve this.

Okay, I fixed that. They're all now in the same span.

On firefox they line up, but on chromium and vivaldi they don't. It seems to be somehow because the Preview and Resign buttons are both inside a span but the Reset button is not.

Some recent change to game courier has the Preview Resign and Reset buttons differently sized and misaligned. I assume the bigger Preview button might be intentional, but Reset is positioned slightly higher than Resign and it looks awful.

The bigger Preview button is intentional so that users will more clearly know which button is the main submit button. The alignment of the buttons is a matter of how your browser and device happen to display them. I still see the Resign and Reset buttons at the same level as each other.

OK, sorry. I overlooked that you were not changing the stroke:none but the fill:none. (And I did not see any filenames, as I just copy-pasted them from your comment in WYSIWIG mode.)

But then the good result is entirely accidental, and cannot be generalized to other images that contain a 'none' filling or stroke.

I think I understand what was causing the problem, though: because this image did not have a black outline with white/blue fill, but had a black ouline without fill, and an exactly matching white/blue area without outline inside it, the latter gets white/blue pixels that are partly transparent when rendered as a raster image. Normally only the black outline touches the transparent background. Apparently the palette did not contain the white/blue with the required transparency, and rounding took place which either made the pixels entire white/blue, or entirely transparent. (Mostly the latter, it seems from the mottled result.) When you apply the fill to the outline, the holes in the inside area make this fill shine through, which camouflages them. In fact these stroke:none elements seem entirely redundant if the other elements are filled.

This SVG was probably generated automatically with the help of an edge-tracing function; these often do not treat the outlines as outlines, but as borderless black-filled areas, tracing both the inner and the outer side of the black lines. And then they create separate areas for the interior.

Some recent change to game courier has the Preview Resign and Reset buttons differently sized and misaligned. I assume the bigger Preview button might be intentional, but Reset is positioned slightly higher than Resign and it looks awful.

You're posting the wrong images. Did you notice that the second pair you posted are called wbadger2.png and bbadger2.png? Look at the first two pairs in my previous comment. The first pair is mine, the second pair is yours, and they look the same. You posted the second pair and the third pair, which I never said looked alike.

And if it's not, why do your badger pieces look exactly the same?

You really cannot see the difference between:

and these?:

This 'first one' has much to narrow outline compared to the other alfaerie pieces.

What are you talking about? It fits in better with them than the alternative badger pieces do.

It is not the original.

And if it's not, why do your badger pieces look exactly the same? And what do you think it should look like?

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

We have a proverb: "In the land of the blind, one-eye is king". The goal is not to be best, but to be good. This 'first one' has much to narrow outline compared to the other alfaerie pieces. It is not the original. As my math teacher used to say: "nearly correct. Thus faulty!"

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.

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

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.

So what did you replace, and by what?

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.

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?

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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

thanks!

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.

This game and also this for example.

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?

Many alfaerie pieces are invisible now using css rendering.

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.

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.

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.

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.

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.

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.

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

Thanks! Much better now

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

I fixed that too.

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.

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.