Castling and Black Moves

[spinetrak]

For whatever reason, some PGN files tolerate 0-0 (instead of O-O) for castling and say 10....Qd4 (instead of 10...Qd4) for black moves. See, for example, some of the games at https://www.hsk1830.de/pages/mannschaften/17-18/bundesligen/berichte/hsk1/Bl-Haeppchen_1718.htm - this site uses the Chessbase PGN viewer (and probably chessbase-generated PGN files, not sure).

For castling, the PGN standard is pretty clear (http://www.saremba.de/chessgml/standards/pgn/pgn-complete.htm#c8.2.3), don't know for black moves. Either way, when using such PGNs, I get parsing errors in the RPB Chessboard, and I have to fix them manually. So my question is, could the parser be a bit more fault-tolerant?

[yo35]

Hi,
As you mentioned, the PGN standard is pretty clear, on both issues:

• regarding castling in section 8.2.3.3: "the upper case letter "O" is used, not the digit zero" (http://www.saremba.de/chessgml/standards/pgn/pgn-complete.htm#AEN237),
• regarding move number notation in section 8.2.2.2: "a black move number indication is formed from the integer giving the fullmove number with three period characters appended" (http://www.saremba.de/chessgml/standards/pgn/pgn-complete.htm#AEN219).

I'm not sure it is a good idea to make the parser tolerant to this kind of errors in the PGN, as it would introduce some additional complexity to it, meaning additional maintenance effort, possibly more bugs.

The question is: how these faulty PGN files have been generated?

• by a software (which one?): in this case, the bug is on the side of the software that has generated the PGN.
• through manual edition: in this case, the PGN parser does its job by raising an error to warn the user that his/her input PGN text is invalid.

[spinetrak]

I should have been more specific - the malformed parts are in the respective comments sections (i.e. within curly brackets).

1. I believe these PGNs were commented using Chessbase, or at least Chessbase's own PGN viewer can deal with these PGNs (again, see the source of https://www.hsk1830.de/pages/mannschaften/17-18/bundesligen/berichte/hsk1/Bl-Haeppchen_1718.htm as an example
2. yes, manually, in the comments sections

I understand completely that it may not be a good idea to support non-standard/non-compliant PGNs. I wanted to bring it up anyways (in particular since Chessbase is very commonly used), but pls feel free to close this Issue as Won't Fix

[yo35]

Hi,

Chessbase PGN viewer behaves in weird manner regarding these issues: from what I guess, it renders castling moves with the 0 (zero) character, but it's actually a O (capital o) that is used in the underlying PGN files.

Definitively, I prefer not to allow these syntaxes, as the PGN standard is pretty clear on what is expected to be the correct syntax on these topics. If such an ill-formed PGN file is submitted to the RPB Chessboard, an error is displayed to the user highlighting what he/she must fix. And even if there are a large number of such errors in the file, automatic text replacement can be applied to fix them all at once.

[yo35]

It appears that the FIDE handbook recommends to use character 0 (zero) for castling moves: see https://handbook.fide.com/chapter/E012018 (section C.13). This may explain why the PGN files generated by some software disobey the PGN norm on this point.

Since this convention appears in an official normalization document, and since I received several queries regarding the support of zero-encoded castling moves, I changed my mind, and I will make RPB Chessboard support that.

[yo35]

Fixed in version 6.2.1