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.

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

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.

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.

Fixed in version 6.2.1