'Pieces' PGN Tag?

[hgm]

I think I'd go for "BoardSize" myself, or just do what XBoard does (I'd replace the "_" with " " though).

I am inclined to go for the prefixed name, like [Variant "16x16 normal"] for Big Chess. Perhaps XBoard ideosyncracies like 'normal' and 'fischerandom' (with one 'r'!) should be replaced by 'chess' and 'chess960', though. The 'normal' so far was not a problem, because no variant tag would be written in that case, but if overridden board size would force writing it, it becomes relevant.

I am in doubt whether 'HoldingsSize' is meaningful data. It is more an XBoard display thing, which in a kludgy way affects which pieces will demote to Pawn on capture. This should already be clear from the basic rules of the variant, however, and you should be allowed to hold everything that you acquire this way. But it would be useful to indicate in some way whether piece drops are allowed at all, e.g. a Crazyhouse version of Capablanca Chess. This is not necessary info for decoding the SAN in the PGN, though. If you see drop moves, the game was apparently played with drops, if not, you don't know. But that only would be a problem for understanding why the players moved as they did, not for decoding the SAN. Similar arguments hold for the size of the promotion zone.

BUT

a non-standard board size seems to always need a FEN, for the standard opening position won't fit. And from a FEN it is pretty obvious what the board size is. So perhaps there is no need at all to piggyback it on the Variant tag?

What is a much more hairy problem is the graphical piece representation. A VariantMan tag can make the GUI associate the correct moves with each piece name, but it has no idea what pictogram to display for non-standard pieces. XBoard has the pieceToCharTable for that. And this is info that definitely does not belong in any PGN, as it is very XBoard-specific.

So if I want XBoard to do anything useful with the VariantMen tag, I must assume that the user will supply the pieceToCharTable, if there is no engine that did that. Or have XBoard make assignments itself, based on some fixed letter -> pictogram assignment, or, more cleverly, look at the moves described in the VariantMen tag, (plus the standard pieces for the mentioned variant), and have a heuristic for looking which available pictogram has standard moves that are 'most similar' to that.

[Evert]

I am inclined to go for the prefixed name, like [Variant "16x16 normal"] for Big Chess. Perhaps XBoard ideosyncracies like 'normal' and 'fischerandom' (with one 'r'!) should be replaced by 'chess' and 'chess960', though. The 'normal' so far was not a problem, because no variant tag would be written in that case, but if overridden board size would force writing it, it becomes relevant.

Definitely change "normal" and "fischerandom". In fact, it might be nice if XBoard understood "chess" and "chess960" as well...

I am in doubt whether 'HoldingsSize' is meaningful data.

Probably not, for the reason you give.

a non-standard board size seems to always need a FEN, for the standard opening position won't fit. And from a FEN it is pretty obvious what the board size is. So perhaps there is no need at all to piggyback it on the Variant tag?

Yes, good point!

What is a much more hairy problem is the graphical piece representation. A VariantMan tag can make the GUI associate the correct moves with each piece name, but it has no idea what pictogram to display for non-standard pieces. XBoard has the pieceToCharTable for that. And this is info that definitely does not belong in any PGN, as it is very XBoard-specific.

So if I want XBoard to do anything useful with the VariantMen tag, I must assume that the user will supply the pieceToCharTable, if there is no engine that did that. Or have XBoard make assignments itself, based on some fixed letter -> pictogram assignment, or, more cleverly, look at the moves described in the VariantMen tag, (plus the standard pieces for the mentioned variant), and have a heuristic for looking which available pictogram has standard moves that are 'most similar' to that.

As you say, that's an XBoard-specific problem (well, not really - any other GUI would have the same problem).
I would definitely go with default pictographs for known variants, falling back on the move type for a particular piece if unknown and assigning some "close enough" when none is available. Perhaps alert the user in that case.

[stegemma]

[...]What is a much more hairy problem is the graphical piece representation. A VariantMan tag can make the GUI associate the correct moves with each piece name, but it has no idea what pictogram to display for non-standard pieces.[...]

Maybe it could be usefull to pass, in the PGN, not only the character associated to any piece type but even the name of that piece. The name would not be used to know the moves but only to give an hint to the interface on wich image to use. A piece named "Monkey", for sample, could be easy translated to a monkey drawing selection. Imperator, soldier, captain, tank, sword and so on could be expected by the interface designer, the same as various animals. yes, you need an hundred pictures for your interface and still you can't solve the problem, if i call a piece "Double-monster" but the most of them could be seen with the interface and the other could be associated asking the user.

This would led to another interesting result: anyone would like to invent a new variant, would know that WinBoard already has a picture called "BlackPhantom" and would choose to use that name instead of "BlackMonster", for sample, for its new piece.

Giving the piece name, with the character and the moves, will help blind people that can use an interface that can spell the correct name (even if not visually known). It is just one more information but maybe very important, IMHO. It could be embedded in VariantMen:

Monkey=fldmdfr;Captain=fldSMDFR...

[hgm]

That is an interesting idea. It might be quite hard to implement it, however. I guess you would have to give both ID letter and name, like A(Archbishop):BN, as we cannot rely on the first letter of the name to be the ID (as in kNight...), and I need the upper/lower-case distinction in cases where white and black could have different armies, where the same ID letter could stand for a different piece.

[stegemma]

That is an interesting idea. It might be quite hard to implement it, however. I guess you would have to give both ID letter and name, like A(Archbishop):BN, as we cannot rely on the first letter of the name to be the ID (as in kNight...), and I need the upper/lower-case distinction in cases where white and black could have different armies, where the same ID letter could stand for a different piece.

Yes, of course you need the initial too. It costs almost nothing and the (name) could be ignored by the interface or omitted by the PGN creator.