There still is a problem in the notation. Because the diagram doesn't support location-dependent moving, I implemented it through automatic non-standard promotion through a small additional script embedded in the page, which defines a function WeirdPromotion. And defined 5 different Pawn types, which all promote depending on the rank they land on.
But the SAN generator adds a promotion suffix when the type after the move isn't the same as before the move, and all the 5 Pawn types currently havetheir ID defined as P. So the promotion suffix is ambiguous, and this might lead to problems when, on pasting a game, the diagram encounters a move like e5=P. Besides, in the context of this game it looks silly to have promotion suffixes, when promotion is automatic. Not sure how I can address that in general, though.
[Edit]
The notation problem seems solved. I now suppress writing a promotion suffix when the promoted piece has the same ID as the original piece, even when it actually is a different piece type. In principle the SAN generator + parser should be resistant against different piece types having the same ID; its decision to add disambiguators is not based on the piece type, but the piece ID. So if two pieces that have the same ID can move to the same square, it will add the disambiguator necessary to distinguish the moves. Such ambiguous piece labeling cannot work if the ID appears as a promotion suffix, though; the SAN parser would always take it to be the first piece type (in the legend table) that has that ID. But if there is no promotion suffix, and the only pseudo-legal move with the specified piece to the specified square is a promotion, the SAN parser will interpret the move as that promotion even in the absence of a promotion suffix.
This should in general allow position-dependent moving to be emulated through a custom promotion routine switching the type between types with the same ID, in a transparent way. The only peculiarity here is that the piece with position-dependent move is a Pawn, and that only the first alternative will get the P suppressed in the move notation. The alternative Pawn types will all specify the P in their move notation. E.g.
Ah yes, I mixed it up. Fixed that now.
There still is a problem in the notation. Because the diagram doesn't support location-dependent moving, I implemented it through automatic non-standard promotion through a small additional script embedded in the page, which defines a function WeirdPromotion. And defined 5 different Pawn types, which all promote depending on the rank they land on.
But the SAN generator adds a promotion suffix when the type after the move isn't the same as before the move, and all the 5 Pawn types currently havetheir ID defined as P. So the promotion suffix is ambiguous, and this might lead to problems when, on pasting a game, the diagram encounters a move like e5=P. Besides, in the context of this game it looks silly to have promotion suffixes, when promotion is automatic. Not sure how I can address that in general, though.
[Edit]
The notation problem seems solved. I now suppress writing a promotion suffix when the promoted piece has the same ID as the original piece, even when it actually is a different piece type. In principle the SAN generator + parser should be resistant against different piece types having the same ID; its decision to add disambiguators is not based on the piece type, but the piece ID. So if two pieces that have the same ID can move to the same square, it will add the disambiguator necessary to distinguish the moves. Such ambiguous piece labeling cannot work if the ID appears as a promotion suffix, though; the SAN parser would always take it to be the first piece type (in the legend table) that has that ID. But if there is no promotion suffix, and the only pseudo-legal move with the specified piece to the specified square is a promotion, the SAN parser will interpret the move as that promotion even in the absence of a promotion suffix.
This should in general allow position-dependent moving to be emulated through a custom promotion routine switching the type between types with the same ID, in a transparent way. The only peculiarity here is that the piece with position-dependent move is a Pawn, and that only the first alternative will get the P suppressed in the move notation. The alternative Pawn types will all specify the P in their move notation. E.g.
1. e4 h5 2. e5 h4 3. Pe6 f5 4. Pxf5 Ph3 5. Pf6 Pxg2 6. Pxg7