Single Comment

| No, that doesn't follow. You could win me over by providing better 
| graphics. Besides, all I want is the ability for me to provide you 
| with better graphics. I am not asking you to provide any additional 
| graphics. I have the graphics. I want the ability to use them with 
| Winboard.

It would be very nice to add other graphics to WinBoard, but I want to
avoid unlimited bloating, so I think te requirements should stay within
reason. In particular I want to avoid providing a zillion different
mechanisms for doing exactly the same thing, especially if each of them
would only work in different situations. (E.g. colors working only with
bitmaps, and scaling working only with fonts.)

| No, it would not be a waste of time at all. The only programs with 
| the kind of graphics capability I want are Zillions of Games and a 
| couple Chinese Chess programs with customizable graphics. Everything 
| else comes up short, even ChessV, because it doesn't use images for 
| boards.

Well, non of the graphics code in WinBoard is of my own hand, but I have
taken a peek at it. At the WinBoard part at least. This code is platform
dependent, and the Linux version, xboard, has completely different code
for this. WinBoard has built-in bitmaps (2-color for black pieces, 3-color
for white, one of the colors being 'transparent') for each size, and
scalable tri-color font-based pieces which are customizable. Xboard has
2-color built-in 'bitmaps' (transparent + color; no outline), and
4-color 'pixmaps' (including the square in the 4th color, so that a
duplicate set is needed), both non-scalable, but both customizable.

I consider it a very undesirable that WinBoard and xboard are so different
here, but phasing out customizability options in which sers might have
heavily invested is something that is 'not done'. My prevference would
be to switch to a single, platform-independent graphics package and format
for internal use (built-ins), and convert the obsolete customization input
formats to this internal format. In WinBoard things basically lready work
that way, MicroSoft monochrome bitmaps being the internal format (using 2
layers to create the white pieces), and font-based rendering converting
the given font to such bitmaps.

In the WinBoard graphcs code, there seems noting that resticts it to
monochrome bitmaps; the number of colors is part of the bitmap definition
in MicroSoft format. I am not sure if the MicroSoft graphics library
supports transparent color. Currently this is emlated by anding and orring
bitmaps together, wchich in black and white has a well-defined effect, but
with multiple bits per pixel might not always do what you want. If a
solution can be found for this, there would be nothing against using
many-color bitmaps as internal format.

Such bitmaps would then also be suitable as customization input (like
xboard already does for monochrome bitmaps), PROVIDED an acceptable way
for scaling the user input to the current disply size can be found.

Of course people having very special desires that are to uncommon to make
it likely to be supported can always customize their own private version
of WinBoard by changing the built-in bitmaps, and recompiling it. WinBoard
is open source.

| That is not an option. It is a commercial program that only plays Shogi
| and does not include any graphics for the Kamikaze piece.

That is what I mean. If WinBoard were the only program that remotely
supports what you want to do, you would use it despite the perceived minor
shortcomings.

| Since Winboard already supports fonts, you do have the option of 
| using fonts instead of rescaled bitmaps. Adding a new feature to 
| your program does not force you to use it. And if you added the 
| feature, you could avoid the need to rescale altogether by creating 
| some smaller bitmap pieces.

Like I explained above, I don't want to add too many features aimed at
doing the same task.

| That depends on the set. I would not use the same images for a 
| Japanese set, and my Symbolic set uses different images, but the 
| set I based on the Chess Motif font uses standard Chess piece images, 
| and it makes sense for this set to just change the color for the 
| promoted pieces.

I don't understand this. Promoted pieces in Shogi move completely
different from their unpromoted counterpart, so the symbol for a
corresponding standard Chess piece would be completely different. I would
think it made sense to represent pieces that move the same by the same
symbol.

| I would not know if this is true, because Winboard would not let 
| me make a single move when I tried to use it for Shogi.

This is strange. Was that because you could not select Shogi at all,
because you had no engine? If you click 'view or edit games' in the
startup dialog, you should not need any engne, and it sould accept all
moves. Be sure to use board size middling or bulky if you want to see al
the pieces, though, as for Shogi, not all sizes have built-in bitmaps.