Comments/Ratings for a Single Item

I think changes in the script (probably the background for brouhaha squares) broke the resizing as it was done on this page, as not all board-sized arrays were extended in size. I hope I fixed this now.

Let me move this discussion to a more applicable thread. Are you changing the color after you rendered it as PGN, through a flood fill? That would indeed not work, because the anti-aliasing would produce all kind of average shades where the color touches the outline, some very close to white but not exactly so, and the flood fill would not capture those. You would have to change the color when it is still SVG.

The way I do it in the renderer is that I load the SVG in a memory buffer, search it for #FFFFF (or whatever I know the original color to be), and substitute that for the desired color, (it is a text file!) before I pass it to the routine that renders it as a bitmap. And then use a routine to save bitmaps as PNG.

I suppose it should be very little work to change the renderer (which now parses CGI query strings handed to it as 'environment' variables) to take its requests from the normal (argc, argv) command-line arguments (or even hard-code what color / size / orientation we want), and then run it in a shell script to render every SVG file. But I guess we should be a bit selective in what we render; we probably only want rotated versions of the orthodox pieces. And I am not sure whether we would want to have complete alfaerie sets in red or green.

OK, even easier. I did use the on-line renderer. I just transformed the directory listing of http://winboard.nl/graphics.dir/svg/alfaerie, obtained through wget, into a shell script that used wget to download the piece image directly from the renderer, and save them on a file bpiecename.png.

A tar ball with all the black 50x50 PNGs is now at http://hgm.nubati.net/black50.tar.gz .

Now that I have that script, it is even more trivial to turn it into a script for doing white, or red, or 35x35, or upside-down. What shade of red would we want?

[Edit] Now also a complete 35x35 set (white and 'black') at http://hgm.nubati.net/alfaerie35.tar.gz .

Are you changing the color after you rendered it as PGN, through a flood fill?

Oh no, I know that won't work.  I was trying to change the SVG itself with Inkscape.  Replacing the text didn't occur to me.  But it seems you've a more automated way to generate them.  Much better than what I was doing.

A tar ball with all the black 50x50 PNGs is now at http://hgm.nubati.net/black50.tar.gz .

Now that I have that script, it is even more trivial to turn it into a script for doing white, or red, or 35x35, or upside-down. What shade of red would we want?

The red should be #FF0000.  And your black isn't quite right - it's kinda purple.  It should be #5984BD to match the existing graphics...

Strange, I do see some imperfections in the black pieces with the renderer as well. I don't understand how that can happen; the white seems to cover anything. Could there be color indicators in the SVG that I somehow fail to substitute? Perhaps the Rooks are just sloppily drawn, so that the background leaks through. This is much more visible on a dark piece: 0 to 10% is a huge contrast, 100% to 90% barely visible.

It is very odd - your pieces seem fine, it is those that were converted from the font. I think the SVG might need to be edited a little bit - the "inside" is a separate object from the path that is the border, which is odd, and it doesn't quite reach the outside. What is stranger is that it works correctly for the white pieces ...

Let me play around a bit ...

Actually, the background shows through on the white pieces as well, it is just very hard to see ...

Ok, I fixed the queen but perhaps not by the best method. (The SVG is now larger than it needs to be.) I deleted the objects that were the "insides" and drew a new, rough enclosed path that overlaps with the existing black path and set the color of it. It doesn't line up exactly, putting it behind the black path and you can't tell.

Here's the altered file. I will try to find a more elegant solution, but since I think only a few pieces are affected by this, this solution will work if need be.

http://www.chessvariants.com/graphics.dir/svg/alfaerie/newqueen.svg

Ok, now I've figured out how to do it a better way. I've updated that file to be correct now. It is still two objects, a solid one below an outline, but at least the paths are the same.

I will fix the other files tonight ...

I think the bottom-line cause is that the original font was made a little sloppy

OK, I rendered all pieces with dark color on light backround as 100x100, so that we can easily judge which have imperfections that should first be cured. If you fix those, I will put the fixed SVG on the winboard.nl server so that the renderer uses those, and then query the renderer to make the complete sets we want.

We should also think about which forward-backward compounds we want; the renderer can also compose these on the fly.

Ok, it's 2:45 in the morning and I've been at it for about 8 hours but have made enormous progress...

First, I think I better understand the original issue. This was a chess font and it was never intended to be used in the way we were using it. The black pieces weren't supposed to be colored in. Like a typical chess font, the black pieces have both black outlines and black fills with thin white lines separating them. I think the gaps we were seeing were supposed to be the white from the page that shows through when the piece is turned black.

Anyway, that's neither here nor there. For our purposes, they needed to be edited. It was a bit of a pain but I got better with practice. It wasn't just the standard pieces that needed to be changed though. A lot of the pieces are modified chess pieces or have components from them, so, sensibly, you copied those elements (preserving the artifacts). So about half needed modification in order to be colorable.

Beyond that, as I was going through them anyway and had to zoom way in, I spent time cleaning up some tiny anomalies... things that probably wouldn't be visible in normal usage but stand out when blown way up... line segments that didn't connect perfectly, things not perfectly centered, small asymmetries in pieces that should be symmetric, etc. Not criticizing your work at all - you were able to crank out a very large number of pieces in record time. And they were probably fine, but I'm kind of anal, and if I'm messing with something I tend to obsess and go overboard.

Anyway, I'm really excited. These are going to look great and will be a huge improvement! So far, I have 74 pieces ready to go. There were a couple of yours that I had difficulty with or need more time to get to where I want them. (E.g., the SVG for the Cannon piece is really messed up.) But I also added a couple of extras.

So here is delivery one: http://www.chessvariants.com/graphics.dir/alfaerieSVG/GS-2020-07-25.zip

Will do more tomorrow, but it's now time to pass out :)

Didn't see your message until after I had posted mine... either you are up far later than I, or you get up far earlier than I :)

Well, I posted it just minutes ago, and it is 9 am here, and I did actually have a sound night of sleep. I will move your new pieces to winboard.nl now.

[Edit] OK, I unpacked your zip file in a directory 'newalfa' on winboard.nl, which means the renderer will now use them if you add the extra argument t=newalfa in the query string. It doesn't entirely work as expected, though. For one, some of the pieces stay white. (I used exactly the same FEN as for the old pieces.) Which probably means the SVG has given them a shade of white that is slightly different from what it was before, and for which the renderer scans the file to substitute it. The rendering also stops at some point. (Probably a missing file, haven't figured that out yet.)

[Edit] OK, FEN rendering stops at the first missing SVG. I copied a few missing ones from the old set (lion, cannon, paovao, nightrider), but very many are still missing.

So the pieces that are still white in your picture are the ones it didn't successfully change the color?

EDIT: I see - I assumed it was supposed to be pure white, #ffffff, which is what I used. But your fills are #f9f9f9. Is that intentional? Does it convert them to pure white when rendering?

Indeed. The others have color #f9f9f9, and the renderer is configured (through the http://winboard.nl/graphics.dir/svg/newalfa/defaults.ini file) to replace that by the color requested in the query string. Since not all pieces are shown I cannot exclude that there aren't any others.

[Edit] Our messages crossed. It was what the others had: some had already been done (those we have to repair now), and they used this color. I just copied that for the pieces I made.

How it converts them is determined by the deaults.ini file in their directory. This specifies the color to replacem the white and black default filling colors, and the default light and dark square shades. Plus some parameters for making compounds.

Ok, I didn't realize that part. I'll use a text editor to change to f9f9f9.

Also, a couple had the filenames changed to match their name in alfaerie. But given the way you are doing this, I can change them back to match your naming and then just rename the PGNs that are produced.

And, yes, there are several still to do. A few of them will be very tricky because the paths are very strange.

I think it is best to stick to the original alfaerie naming; I just accidentally misnamed the knightwazir and knightferz. The renderer just uses the names of the SVGs. And the Applet shows the SVG names as they are in /graphics.dir/svg/alfaerie.

The defaults.ini file for alfaerie contains:

f9f9f9
f9f9f9
a0a0ff
e0c080
A89060
compound 64 52 0 3 40
B~ = knight,N-B
R~ = knight+rook,N-R
Q~ = knight+queen,N-Q
C~ = gnu,C-Q
S = silvergeneral
G = goldgeneral
P^ = lance
N~ = horse

Ok, new update:

http://www.chessvariants.com/graphics.dir/alfaerieSVG/GS-2020-07-26.zip

This file includes versions of all 79 of your graphics plus 4 more. The colors should all be standardized to #f9f9f9. The file naming is consistent with the Alfaerie graphics set naming.

The new pieces are wcamelferz, wcamelwazir, wnarrowknightferz and welephantferzwarmachine. The last one will be a real test for your renderer - it was an incredible pain in the butt and uses many layers.

Updated again. Several more small tweaks, a brand new tiger graphic I made (that I think is pretty awesome), and a couple new pieces: wcoppergeneral, wforwardrookbackwardsprince (charging rook), and wgreatwarmachineferz.

NOTE: That last one I am differing from the alfaerie name because the alfaerie name is just wrong and apparently has been all along. That is the graphic for the Half-Duck, but in alfaerie it is called wgreatwarmachinewazir despite the fact that it is a ferz and not a wazir.

OK, I rendered the entire improved set, including some compounds, as 50x50 and 35x35 PNG. In (nearly) white and in standard blue. The files are at winboard.nl/graphics.dir/svg/newalfa/alfaeriePNG35.tar.gz and winboard.nl/graphics.dir/svg/newalfa/alfaeriePNG35.tar.gz .

It would be nice if they could be unpacked somewhere in chessvariants.com/graphics.dir/.../ . Once they are there I can have the Play-Test Applet use the 35x35 PNG set instead of directly accessing the off-site renderer. But to really have any impact, it would be necessary to allow them to be selected from scripts that ask for a piece theme. Like the diagram designer and the Game Courier preset editor.

It should be easy to also produce PNGs in other colors and orientations.

P.S. The Tiger is indeed  very nice.

I have uploaded the graphics to /graphics.dir/alfaerieSVG and /graphics.dir/alfaerieSVG35 but they don't work for some reason.

This file definitely exists, but the link gives a 404:

https://www.chessvariants.com/graphics.dir/alfaerieSVG/wking.pgn

And it doesn't seem to be a file ownership/permissions issue, so I'm not sure what the problem could be.

Use extension png instead of pgn.

Whoops!

Ok, now the images are found, but unfortunately whatever the diagram designer uses to render doesn't seem to support PNG correctly ...

It does seem to work in Game Courier though!