It turns out I misunderstood how these font piece colors work. They are not describing the gradient, but the 'BackColor' gives the color of the symbols of the font (the 'outline'), while the 'ForeColor' specifies the color with which the open spaces with them are filled. The latter is used as a gradient dropping to half the brightness in the shadowed part (in the lower-right square corner). This is rather opposite from usual terminology for font coloring, where 'foreground color' means the color of the symbols, and background everything in or around them.
Since piece fonts usually depict white pieces with thin lines, and black pieces as ultra-bold blobs, this means that one percieves the white pieces as having the ForeColorWhite, and black pieces as having the BackColorBlack. The outline of the white pieces (conventionally black) is then in the BackColorWhite, while the details on black pieces (conventionally transparent in WinBoard and the whitePieceColor in XBoard) are inscribed in the ForeColorBlack (with gradient).
So it would be logical to associate -fontPieceForeColorWhite with -whitePieceColor, and -fontPieceBackColorBlack with -blackPieceColor (i.e. set them through the same color controls in the View -> Board dialog), and define -fontPieceBackColorWhite as black and -fontPieceForeColorBlack as white (as transparency is not an option). There probably is little demand for altering the latter two, so leaving a command-line option as the only way to do it doesn't sem to bad.
There is only one snag: with the option 'All White', (or in a Shogi font), the 'black' pieces would also have thin outlines, and would be percieved as having the ForeColorBlack, while the BackColorBlack should preferably be fixed to black. Rather than forcing the user to swap the colors when he is using pieces with thin outline for both sides, it would be better to let WinBoard do this automatically, and use the BackColorBlack for filling the inner area (which normaly would be used for the fat symbol), and use the BackColorWhite for drawing the outline. This would force white and black to always use the same color for the narrow outline, however. I am not sure this is a problem; in fact it seems the option 'All White' is superfluous for font-based pieces, as one could simply define the -fontPieceToCharTable such that black pieces map to the same font symbol as the corresponding white pieces. A Shogi font would also not really need the option 'All White', as it usually provides the upside-down pieces as different symbols of the font. Coloring their outline black, and their interior white, is actually exactly what you need to give them the same colors as the white pieces.
So the bottom line seems to be:
* Use the -whitePieceColor control in View -> Board to set -fontPieceForeColorWhite when 'Use piece font' is ticked
* Use the -blackPieceColor control in View -> Board to set -fontPieceBackColorBlack when 'Use piece font' is ticked
* Use the white-piece outline color and black-piece outline color for black-piece outline and interior when rendering in 'All white' mode
[edit] Oh sh*t... I messed up! When I ported the WinBoard option handling to XBoard (I think that was in 4.5.0), I had to account for the completely different representations of colors in the two. So the color options do not directly point to a color variable, but contain a number, which is then passed to a function that uses it as index in a table with pointers to the actual color variables, which then does the conversion to the required format, and stores it there. In WinBoard I accidentally swapped the Fore and Back colors in that table. So the ForeColor option now sets what internally was the BackColor, and vice versa... This is why the naming was so strange.
All the more reason to deprecate these options. I guess I will let the font pieces use the same -wpc and -bpc for their main color, and then introduce two new options -pieceOutlineColor and -pieceDetailsColor for the minor colors of font pieces.
TB Gaviota support and
