[XBoard-devel] piece-image naming

[H.G. Muller]

Currently the XBoard svg files have names like WhiteBishop.svg, 
BlackKing.svg. For fairy pieces the naming becomes a bit arbitrary, as 
there is no standard pictorial representation for unorthodox pieces. 
(Except for major variants like Xiangqi and Shogi, but there the 
standard representation is oriental, using kanji pieces, and not 
suitable for mixing with piece symbols for western Chess.) Now this 
isn't really a problem if these were only names used internally in 
XBoard, but it is an obstacle against sharing themes (such as Shogi 
pieces) with other GUIs. The names that XBoard now uses for the Shogi 
images look very obscure to Shogi players, e.g. a Silver General would 
be White/BlackAdvisor.

There also is another problem. If XBoard encounters a PGN record of a 
game in a variant it doesn't know (because it was an engine-defined 
variant), that PGN would contain info on how the pieces move. But it 
would not contain info on how they should look.

Now this problem could be solved by providing with each piece glyph of a 
theme information on how a piece that looks like that is supposed to 
move. And the filename would be an excellent place to encode such 
information, without having to break any standard format for image 
files. So instead of having a file WhiteArchbishop.svg we could have a 
file w_BN.svg, because BN is the standard notation for how an Archbishop 
moves: as Bishop or Knight. When someone then would want to implement 
some large Shogi variant with a 'Left Chariot' that moves like 
'fRbWlfrbB' the engine or PGN file would tell XBoard that the piece 
indicated by 'L' in the setup FEN or SAN moves would move that way, and 
XBoard could search its pieceImageDirectory for the current theme for a 
files named w_fRbWlfrbB.svg and b_fRbWlfrbB.svg to represent it. (And 
improvise otherwise.) Presumably someone providing an engine for this 
game would also provide a theme that provides glyphs for exactly the 
pieces he needs.

When there is no exact match, there could be a distance measure in the 
space of move patterns to decide what is the 'best match', e.g. by 
generating moves for all the available glyphs in a small number of test 
positions, as well as for the the piece we want to assign a glyph to, 
and giving penalty points for each move they do not have in common. This 
way you would get a 'distance matrix' between pieces in the game on the 
one hand, and glyphs in the theme on the other. This could then be used 
to find a best overall assignment of glyphs to pieces, based on 
minimizing the total mismatch. It could even be used tou automatically 
let the GUI pick the best available theme, by repeating the procedure 
for all of them. There still could be a fallback like we have now, that 
if the chosen theme would not supply sufficiently many pieces, the 
default theme would be used to supply the missing ones.

There are some tricky issues one would encounter in Shogi and some of 
its variants, where pieces with the same move would coexist in one game, 
and yet be different because they promote differently (or demote 
differently on capture). To allow unambiguous matching, the move of the 
promoted / demoted version would have to become part of the name. E.g. a 
Shogi Gold general would be w_WfF.svg, but a promoted Lance, which also 
moves like Gold, would be w_WfF+fR.svg (as fR is the Lance move), and a 
promoted Knight w_WfF+ffN.svg (currently WhiteGoldKnight.svg). The part 
of the name behind the + (or behind a - if the issue is pieces that move 
the same but promote differently) would then only be used as a tie 
breaker for matching pieces that do promote or demote.

Shall we switch to such a more universal system of glyph naming?