Converting old SGF files to FF[4]
Converting properties
This is a short list of properties that frequently occur in old SGF
files and how they should be converted to FF[4].
Property: M
Propvalue: list of point
Function: Simple board markup
Conversion: M should be converted to MA if used on empty board points
and to TR if used on stones.
Property: L
Propvalue: list of point
Function: Label the given points with uppercase letters.
Conversion: L should be converted to LB.
Example: L[fg][es][jk] -> LB[fg:A][es:B][jk:C]
Property: TE then BM within a node
Propvalue: double
Function: Move annotation
Conversion: Should be converted to IT.
Property: BM then TE within a node
Propvalue: double
Function: Move annotation
Conversion: Should be converted to DO.
Property: VW
Propvalue: point, point
Function: Restrict view (just like in FF[4]).
VW wasn't an official property in FF[3] but was used by two
applications (SGB & xgoban)
Conversion: In FF[3] the two given points specified the upper
left and the lower right corner. To convert it to FF[4] either
make a compose type value out of it or write the uncompressed
point list.
Example: VW[ba][db] -> VW[ba:db]
or -> VW[ba][ca][da][bb][cb][db]
Other conversion issues
Property identifiers
In FF[1]-FF[3] lowercase letters where allowed in property identifiers, but
in FF[4] only uppercase letters are allowed. I.e. the application has to remove all
lowercase letters from the file.
Example: Black[qd];thisisaWhitemove[kk]bbrWyryrerwLerreoi[10.3] --> B[qd];W[kk]WL[10.3]
Property types move & setup
The old fileformats didn't make this distinction, i.e. these files may have mixed
setup and move-properties in one node.
In that case an application should split that node into two nodes: all setup,
root and game-info properties and the node name ('N[]') into the first
node, all other properties
into the second. The node name should be in the first node because the node
to be split might be the start of a variation.
Illegal & errornous files
There are a lot of corrupt files out there. If you want to write a robust
application you should be able to deal with the following cases:
- Line breaks & whitespaces within moves or values: just remove all whitespaces
in property values except in text values.
- Empty values e.g. 'DT[]N[]': remove those properties
- Properties without values e.g. 'LB B[aa]': remove the property identifiers
- Properties with too many values e.g. 'B[aa][bb]': this one is critical because
it might be caused by a missing ']' e.g. 'B[aa LB[aa][bb]'
- Empty variations e.g. '()': such a construct is illegal because a variation
has to have at least one node - remove '()'
- Files not starting with '(;' e.g. the ';' is missing - this one is tricky if
you want to skip junk in front of the SGF file.
- Faulty game-info values (e.g. RE, DT): the application should correct
those values if possible, otherwise leave them as they are.
These are just some frequent errors that occur.
Have a look at the SGF Syntax Checker &
Converter for more sophisticated errors and how to handle them.