cheeplay

chess PGN replay in the terminal
git clone git://git.alexkarle.com.com/cheeplay
Log | Files | Refs | README | LICENSE

PGN_standard_1994-03-12.txt (121009B) [raw]


      1 Standard: Portable Game Notation Specification and Implementation Guide
      2 
      3 Revised: 1994.03.12
      4 
      5 Authors: Interested readers of the Internet newsgroup rec.games.chess
      6 
      7 Coordinator: Steven J. Edwards (send comments to sje@world.std.com)
      8 
      9 
     10 0: Preface
     11 
     12 From the Tower of Babel story:
     13 
     14 "If now, while they are one people, all speaking the same language, they have
     15 started to do this, nothing will later stop them from doing whatever they
     16 propose to do."
     17 
     18 Genesis XI, v.6, _New American Bible_
     19 
     20 
     21 1: Introduction
     22 
     23 PGN is "Portable Game Notation", a standard designed for the representation of
     24 chess game data using ASCII text files.  PGN is structured for easy reading and
     25 writing by human users and for easy parsing and generation by computer
     26 programs.  The intent of the definition and propagation of PGN is to facilitate
     27 the sharing of public domain chess game data among chessplayers (both organic
     28 and otherwise), publishers, and computer chess researchers throughout the
     29 world.
     30 
     31 PGN is not intended to be a general purpose standard that is suitable for every
     32 possible use; no such standard could fill all conceivable requirements.
     33 Instead, PGN is proposed as a universal portable representation for data
     34 interchange.  The idea is to allow the construction of a family of chess
     35 applications that can quickly and easily process chess game data using PGN for
     36 import and export among themselves.
     37 
     38 
     39 2: Chess data representation
     40 
     41 Computer usage among chessplayers has become quite common in recent years and a
     42 variety of different programs, both commercial and public domain, are used to
     43 generate, access, and propagate chess game data.  Some of these programs are
     44 rather impressive; most are now well behaved in that they correctly follow the
     45 Laws of Chess and handle users' data with reasonable care.  Unfortunately, many
     46 programs have had serious problems with several aspects of the external
     47 representation of chess game data.  Sometimes these problems become more
     48 visible when a user attempts to move significant quantities of data from one
     49 program to another; if there has been no real effort to ensure portability of
     50 data, then the chances for a successful transfer are small at best.
     51 
     52 
     53 2.1: Data interchange incompatibility
     54 
     55 The reasons for format incompatibility are easy to understand.  In fact, most
     56 of them are correlated with the same problems that have already been seen with
     57 commercial software offerings for other domains such as word processing,
     58 spreadsheets, fonts, and graphics.  Sometimes a manufacturer deliberately
     59 designs a data format using encryption or some other secret, proprietary
     60 technique to "lock in" a customer.  Sometimes a designer may produce a format
     61 that can be deciphered without too much difficulty, but at the same time
     62 publicly discourage third party software by claiming trade secret protection.
     63 Another software producer may develop a non-proprietary system, but it may work
     64 well only within the scope of a single program or application because it is not
     65 easily expandable.  Finally, some other software may work very well for many
     66 purposes, but it uses symbols and language not easily understood by people or
     67 computers available to those outside the country of its development.
     68 
     69 
     70 2.2: Specification goals
     71 
     72 A specification for a portable game notation must observe the lessons of
     73 history and be able to handle probable needs of the future.  The design
     74 criteria for PGN were selected to meet these needs.  These criteria include:
     75 
     76 1) The details of the system must be publicly available and free of unnecessary
     77 complexity.  Ideally, if the documentation is not available for some reason,
     78 typical chess software developers and users should be able to understand most
     79 of the data without the need for third party assistance.
     80 
     81 2) The details of the system must be non-proprietary so that users and software
     82 developers are unrestricted by concerns about infringing on intellectual
     83 property rights.  The idea is to let chess programmers compete in a free market
     84 where customers may choose software based on their real needs and not based on
     85 artificial requirements created by a secret data format.
     86 
     87 3) The system must work for a variety of programs.  The format should be such
     88 that it can be used by chess database programs, chess publishing programs,
     89 chess server programs, and chessplaying programs without being unnecessarily
     90 specific to any particular application class.
     91 
     92 4) The system must be easily expandable and scalable.  The expansion ability
     93 must include handling data items that may not exist currently but could be
     94 expected to emerge in the future.  (Examples: new opening classifications and
     95 new country names.)  The system should be scalable in that it must not have any
     96 arbitrary restrictions concerning the quantity of stored data.  Also, planned
     97 modes of expansion should either preserve earlier databases or at least allow
     98 for their automatic conversion.
     99 
    100 5) The system must be international.  Chess software users are found in many
    101 countries and the system should be free of difficulties caused by conventions
    102 local to a given region.
    103 
    104 6) Finally, the system should handle the same kinds and amounts of data that
    105 are already handled by existing chess software and by print media.
    106 
    107 
    108 2.3: A sample PGN game
    109 
    110 Although its description may seem rather lengthy, PGN is actually fairly
    111 simple.  A sample PGN game follows; it has most of the important features
    112 described in later sections of this document.
    113 
    114 [Event "F/S Return Match"]
    115 [Site "Belgrade, Serbia JUG"]
    116 [Date "1992.11.04"]
    117 [Round "29"]
    118 [White "Fischer, Robert J."]
    119 [Black "Spassky, Boris V."]
    120 [Result "1/2-1/2"]
    121 
    122 1. e4 e5 2. Nf3 Nc6 3. Bb5 a6 4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8. c3
    123 O-O 9. h3 Nb8 10. d4 Nbd7 11. c4 c6 12. cxb5 axb5 13. Nc3 Bb7 14. Bg5 b4 15.
    124 Nb1 h6 16. Bh4 c5 17. dxe5 Nxe4 18. Bxe7 Qxe7 19. exd6 Qf6 20. Nbd2 Nxd6 21.
    125 Nc4 Nxc4 22. Bxc4 Nb6 23. Ne5 Rae8 24. Bxf7+ Rxf7 25. Nxf7 Rxe1+ 26. Qxe1 Kxf7
    126 27. Qe3 Qg5 28. Qxg5 hxg5 29. b3 Ke6 30. a3 Kd6 31. axb4 cxb4 32. Ra5 Nd5 33.
    127 f3 Bc8 34. Kf2 Bf5 35. Ra7 g6 36. Ra6+ Kc5 37. Ke1 Nf4 38. g3 Nxh3 39. Kd2 Kb5
    128 40. Rd6 Kc5 41. Ra6 Nf2 42. g4 Bd3 43. Re6 1/2-1/2
    129 
    130 
    131 3: Formats: import and export
    132 
    133 There are two formats in the PGN specification.  These are the "import" format
    134 and the "export" format.  These are the two different ways of formatting the
    135 same PGN data according to its source.  The details of the two formats are
    136 described throughout the following sections of this document.
    137 
    138 Other than formats, there is the additional topic of PGN presentation.  While
    139 both PGN import and export formats are designed to be readable by humans, there
    140 is no recommendation that either of these be an ultimate mode of chess data
    141 presentation.  Rather, software developers are urged to consider all of the
    142 various techniques at their disposal to enhance the display of chess data at
    143 the presentation level (i.e., highest level) of their programs.  This means
    144 that the use of different fonts, character sizes, color, and other tools of
    145 computer aided interaction and publishing should be explored to provide a high
    146 quality presentation appropriate to the function of the particular program.
    147 
    148 
    149 3.1: Import format allows for manually prepared data
    150 
    151 The import format is rather flexible and is used to describe data that may have
    152 been prepared by hand, much like a source file for a high level programming
    153 language.  A program that can read PGN data should be able to handle the
    154 somewhat lax import format.
    155 
    156 
    157 3.2: Export format used for program generated output
    158 
    159 The export format is rather strict and is used to describe data that is usually
    160 prepared under program control, something like a pretty printed source program
    161 reformatted by a compiler.
    162 
    163 
    164 3.2.1: Byte equivalence
    165 
    166 For a given PGN data file, export format representations generated by different
    167 PGN programs on the same computing system should be exactly equivalent, byte
    168 for byte.
    169 
    170 
    171 3.2.2: Archival storage and the newline character
    172 
    173 Export format should also be used for archival storage.  Here, "archival"
    174 storage is defined as storage that may be accessed by a variety of computing
    175 systems.  The only extra requirement for archival storage is that the newline
    176 character have a specific representation that is independent of its value for a
    177 particular computing system's text file usage.  The archival representation of
    178 a newline is the ASCII control character LF (line feed, decimal value 10,
    179 hexadecimal value 0x0a).
    180 
    181 Sadly, there are some accidents of history that survive to this day that have
    182 baroque representations for a newline: multicharacter sequences, end-of-line
    183 record markers, start-of-line byte counts, fixed length records, and so forth.
    184 It is well beyond the scope of the PGN project to reconcile all of these to the
    185 unified world of ANSI C and the those enjoying the bliss of a single '\n'
    186 convention.  Some systems may just not be able to handle an archival PGN text
    187 file with native text editors.  In these cases, an indulgence of sorts is
    188 granted to use the local newline convention in non-archival PGN files for those
    189 text editors.
    190 
    191 
    192 3.2.3: Speed of processing
    193 
    194 Several parts of the export format deal with exact descriptions of line and
    195 field justification that are absent from the import format details.  The main
    196 reason for these restrictions on the export format are to allow the
    197 construction of simple data translation programs that can easily scan PGN data
    198 without having to have a full chess engine or other complex parsing routines.
    199 The idea is to encourage chess software authors to always allow for at least a
    200 limited PGN reading capability.  Even when a full chess engine parsing
    201 capability is available, it is likely to be at least two orders of magnitude
    202 slower than a simple text scanner.
    203 
    204 
    205 3.2.4: Reduced export format
    206 
    207 A PGN game represented using export format is said to be in "reduced export
    208 format" if all of the following hold: 1) it has no commentary, 2) it has only
    209 the standard seven tag roster identification information ("STR", see below), 3)
    210 it has no recursive annotation variations ("RAV", see below), and 4) it has no
    211 numeric annotation glyphs ("NAG", see below).  Reduced export format is used
    212 for bulk storage of unannotated games.  It represents a minimum level of
    213 standard conformance for a PGN exporting application.
    214 
    215 
    216 4: Lexicographical issues
    217 
    218 PGN data is composed of characters; non-overlapping contiguous sequences of
    219 characters form lexical tokens.
    220 
    221 
    222 4.1: Character codes
    223 
    224 PGN data is represented using a subset of the eight bit ISO 8859/1 (Latin 1)
    225 character set.  ("ISO" is an acronym for the International Standards
    226 Organization.)  This set is also known as ECMA-94 and is similar to other ISO
    227 Latin character sets.  ISO 8859/1 includes the standard seven bit ASCII
    228 character set for the 32 control character code values from zero to 31.  The 95
    229 printing character code values from 32 to 126 are also equivalent to seven bit
    230 ASCII usage.  (Code value 127, the ASCII DEL control character, is a graphic
    231 character in ISO 8859/1; it is not used for PGN data representation.)
    232 
    233 The 32 ISO 8859/1 code values from 128 to 159 are non-printing control
    234 characters.  They are not used for PGN data representation.  The 32 code values
    235 from 160 to 191 are mostly non-alphabetic printing characters and their use for
    236 PGN data is discouraged as their graphic representation varies considerably
    237 among other ISO Latin sets.  Finally, the 64 code values from 192 to 255 are
    238 mostly alphabetic printing characters with various diacritical marks; their use
    239 is encouraged for those languages that require such characters.  The graphic
    240 representations of this last set of 64 characters is fairly constant for the
    241 ISO Latin family.
    242 
    243 Printing character codes outside of the seven bit ASCII range may only appear
    244 in string data and in commentary.  They are not permitted for use in symbol
    245 construction.
    246 
    247 Because some PGN users' environments may not support presentation of non-ASCII
    248 characters, PGN game authors should refrain from using such characters in
    249 critical commentary or string values in game data that may be referenced in
    250 such environments.  PGN software authors should have their programs handle such
    251 environments by displaying a question mark ("?") for non-ASCII character codes.
    252 This is an important point because there are many computing systems that can
    253 display eight bit character data, but the display graphics may differ among
    254 machines and operating systems from different manufacturers.
    255 
    256 Only four of the ASCII control characters are permitted in PGN import format;
    257 these are the horizontal and vertical tabs along with the linefeed and carriage
    258 return codes.
    259 
    260 The external representation of the newline character may differ among
    261 platforms; this is an acceptable variation as long as the details of the
    262 implementation are hidden from software implementors and users.  When a choice
    263 is practical, the Unix "newline is linefeed" convention is preferred.
    264 
    265 
    266 4.2: Tab characters
    267 
    268 Tab characters, both horizontal and vertical, are not permitted in the export
    269 format.  This is because the treatment of tab characters is highly dependent
    270 upon the particular software in use on the host computing system.  Also, tab
    271 characters may not appear inside of string data.
    272 
    273 
    274 4.3: Line lengths
    275 
    276 PGN data are organized as simple text lines without any special bytes or
    277 markers for secondary record structure imposed by specific operating systems.
    278 Import format PGN text lines are limited to having a maximum of 255 characters
    279 per line including the newline character.  Lines with 80 or more printing
    280 characters are strongly discouraged because of the difficulties experienced by
    281 common text editors with long lines.
    282 
    283 In some cases, very long tag values will require 80 or more columns, but these
    284 are relatively rare.  An example of this is the "FEN" tag pair; it may have a
    285 long tag value, but this particular tag pair is only used to represent a game
    286 that doesn't start from the usual initial position.
    287 
    288 
    289 5: Commentary
    290 
    291 Comment text may appear in PGN data.  There are two kinds of comments.  The
    292 first kind is the "rest of line" comment; this comment type starts with a
    293 semicolon character and continues to the end of the line.  The second kind
    294 starts with a left brace character and continues to the next right brace
    295 character.  Comments cannot appear inside any token.
    296 
    297 Brace comments do not nest; a left brace character appearing in a brace comment
    298 loses its special meaning and is ignored.  A semicolon appearing inside of a
    299 brace comment loses its special meaning and is ignored.  Braces appearing
    300 inside of a semicolon comments lose their special meaning and are ignored.
    301 
    302 *** Export format representation of comments needs definition work.
    303 
    304 
    305 6: Escape mechanism
    306 
    307 There is a special escape mechanism for PGN data.  This mechanism is triggered
    308 by a percent sign character ("%") appearing in the first column of a line; the
    309 data on the rest of the line is ignored by publicly available PGN scanning
    310 software.  This escape convention is intended for the private use of software
    311 developers and researchers to embed non-PGN commands and data in PGN streams.
    312 
    313 A percent sign appearing in any other place other than the first position in a
    314 line does not trigger the escape mechanism.
    315 
    316 
    317 7: Tokens
    318 
    319 PGN character data is organized as tokens.  A token is a contiguous sequence of
    320 characters that represents a basic semantic unit.  Tokens may be separated from
    321 adjacent tokens by white space characters.  (White space characters include
    322 space, newline, and tab characters.)  Some tokens are self delimiting and do
    323 not require white space characters.
    324 
    325 A string token is a sequence of zero or more printing characters delimited by a
    326 pair of quote characters (ASCII decimal value 34, hexadecimal value 0x22).  An
    327 empty string is represented by two adjacent quotes.  (Note: an apostrophe is
    328 not a quote.)  A quote inside a string is represented by the backslash
    329 immediately followed by a quote.  A backslash inside a string is represented by
    330 two adjacent backslashes.  Strings are commonly used as tag pair values (see
    331 below).  Non-printing characters like newline and tab are not permitted inside
    332 of strings.  A string token is terminated by its closing quote.  Currently, a
    333 string is limited to a maximum of 255 characters of data.
    334 
    335 An integer token is a sequence of one or more decimal digit characters.  It is
    336 a special case of the more general "symbol" token class described below.
    337 Integer tokens are used to help represent move number indications (see below).
    338 An integer token is terminated just prior to the first non-symbol character
    339 following the integer digit sequence.
    340 
    341 A period character (".") is a token by itself.  It is used for move number
    342 indications (see below).  It is self terminating.
    343 
    344 An asterisk character ("*") is a token by itself.  It is used as one of the
    345 possible game termination markers (see below); it indicates an incomplete game
    346 or a game with an unknown or otherwise unavailable result.  It is self
    347 terminating.
    348 
    349 The left and right bracket characters ("[" and "]") are tokens.  They are used
    350 to delimit tag pairs (see below).  Both are self terminating.
    351 
    352 The left and right parenthesis characters ("(" and ")") are tokens.  They are
    353 used to delimit Recursive Annotation Variations (see below).  Both are self
    354 terminating.
    355 
    356 The left and right angle bracket characters ("<" and ">") are tokens.  They are
    357 reserved for future expansion.  Both are self terminating.
    358 
    359 A Numeric Annotation Glyph ("NAG", see below) is a token; it is composed of a
    360 dollar sign character ("$") immediately followed by one or more digit
    361 characters.  It is terminated just prior to the first non-digit character
    362 following the digit sequence.
    363 
    364 A symbol token starts with a letter or digit character and is immediately
    365 followed by a sequence of zero or more symbol continuation characters.  These
    366 continuation characters are letter characters ("A-Za-z"), digit characters
    367 ("0-9"), the underscore ("_"), the plus sign ("+"), the octothorpe sign ("#"),
    368 the equal sign ("="), the colon (":"),  and the hyphen ("-").  Symbols are used
    369 for a variety of purposes.  All characters in a symbol are significant.  A
    370 symbol token is terminated just prior to the first non-symbol character
    371 following the symbol character sequence.  Currently, a symbol is limited to a
    372 maximum of 255 characters in length.
    373 
    374 
    375 8: Parsing games
    376 
    377 A PGN database file is a sequential collection of zero or more PGN games.  An
    378 empty file is a valid, although somewhat uninformative, PGN database.
    379 
    380 A PGN game is composed of two sections.  The first is the tag pair section and
    381 the second is the movetext section.  The tag pair section provides information
    382 that identifies the game by defining the values associated with a set of
    383 standard parameters.  The movetext section gives the usually enumerated and
    384 possibly annotated moves of the game along with the concluding game termination
    385 marker.  The chess moves themselves are represented using SAN (Standard
    386 Algebraic Notation), also described later in this document.
    387 
    388 
    389 8.1: Tag pair section
    390 
    391 The tag pair section is composed of a series of zero or more tag pairs.
    392 
    393 A tag pair is composed of four consecutive tokens: a left bracket token, a
    394 symbol token, a string token, and a right bracket token.  The symbol token is
    395 the tag name and the string token is the tag value associated with the tag
    396 name.  (There is a standard set of tag names and semantics described below.)
    397 The same tag name should not appear more than once in a tag pair section.
    398 
    399 A further restriction on tag names is that they are composed exclusively of
    400 letters, digits, and the underscore character.  This is done to facilitate
    401 mapping of tag names into key and attribute names for use with general purpose
    402 database programs.
    403 
    404 For PGN import format, there may be zero or more white space characters between
    405 any adjacent pair of tokens in a tag pair.
    406 
    407 For PGN export format, there are no white space characters between the left
    408 bracket and the tag name, there are no white space characters between the tag
    409 value and the right bracket, and there is a single space character between the
    410 tag name and the tag value.
    411 
    412 Tag names, like all symbols, are case sensitive.  All tag names used for
    413 archival storage begin with an upper case letter.
    414 
    415 PGN import format may have multiple tag pairs on the same line and may even
    416 have a tag pair spanning more than a single line.  Export format requires each
    417 tag pair to appear left justified on a line by itself; a single empty line
    418 follows the last tag pair.
    419 
    420 Some tag values may be composed of a sequence of items.  For example, a
    421 consultation game may have more than one player for a given side.  When this
    422 occurs, the single character ":" (colon) appears between adjacent items.
    423 Because of this use as an internal separator in strings, the colon should not
    424 otherwise appear in a string.
    425 
    426 The tag pair format is designed for expansion; initially only strings are
    427 allowed as tag pair values.  Tag value formats associated with the STR (Seven
    428 Tag Roster, see below) will not change; they will always be string values.
    429 However, there are long term plans to allow general list structures as tag
    430 values for non-STR tag pairs.  Use of these expanded tag values will likely be
    431 restricted to special research programs.  In all events, the top level
    432 structure of a tag pair remains the same: left bracket, tag name, tag value,
    433 and right bracket.
    434 
    435 
    436 8.1.1: Seven Tag Roster
    437 
    438 There is a set of tags defined for mandatory use for archival storage of PGN
    439 data.  This is the STR (Seven Tag Roster).  The interpretation of these tags is
    440 fixed as is the order in which they appear.  Although the definition and use of
    441 additional tag names and semantics is permitted and encouraged when needed, the
    442 STR is the common ground that all programs should follow for public data
    443 interchange.
    444 
    445 For import format, the order of tag pairs is not important.  For export format,
    446 the STR tag pairs appear before any other tag pairs.  (The STR tag pairs must
    447 also appear in order; this order is described below).  Also for export format,
    448 any additional tag pairs appear in ASCII order by tag name.
    449 
    450 The seven tag names of the STR are (in order):
    451 
    452 1) Event (the name of the tournament or match event)
    453 
    454 2) Site (the location of the event)
    455 
    456 3) Date (the starting date of the game)
    457 
    458 4) Round (the playing round ordinal of the game)
    459 
    460 5) White (the player of the white pieces)
    461 
    462 6) Black (the player of the black pieces)
    463 
    464 7) Result (the result of the game)
    465 
    466 A set of supplemental tag names is given later in this document.
    467 
    468 For PGN export format, a single blank line appears after the last of the tag
    469 pairs to conclude the tag pair section.  This helps simple scanning programs to
    470 quickly determine the end of the tag pair section and the beginning of the
    471 movetext section.
    472 
    473 
    474 8.1.1.1: The Event tag
    475 
    476 The Event tag value should be reasonably descriptive.  Abbreviations are to be
    477 avoided unless absolutely necessary.  A consistent event naming should be used
    478 to help facilitate database scanning.  If the name of the event is unknown, a
    479 single question mark should appear as the tag value.
    480 
    481 Examples:
    482 
    483 [Event "FIDE World Championship"]
    484 
    485 [Event "Moscow City Championship"]
    486 
    487 [Event "ACM North American Computer Championship"]
    488 
    489 [Event "Casual Game"]
    490 
    491 
    492 8.1.1.2: The Site tag
    493 
    494 The Site tag value should include city and region names along with a standard
    495 name for the country.  The use of the IOC (International Olympic Committee)
    496 three letter names is suggested for those countries where such codes are
    497 available.  If the site of the event is unknown, a single question mark should
    498 appear as the tag value.  A comma may be used to separate a city from a region.
    499 No comma is needed to separate a city or region from the IOC country code.  A
    500 later section of this document gives a list of three letter nation codes along
    501 with a few additions for "locations" not covered by the IOC.
    502 
    503 Examples:
    504 
    505 [Site "New York City, NY USA"]
    506 
    507 [Site "St. Petersburg RUS"]
    508 
    509 [Site "Riga LAT"]
    510 
    511 
    512 8.1.1.3: The Date tag
    513 
    514 The Date tag value gives the starting date for the game.  (Note: this is not
    515 necessarily the same as the starting date for the event.)  The date is given
    516 with respect to the local time of the site given in the Event tag.  The Date
    517 tag value field always uses a standard ten character format: "YYYY.MM.DD".  The
    518 first four characters are digits that give the year, the next character is a
    519 period, the next two characters are digits that give the month, the next
    520 character is a period, and the final two characters are digits that give the
    521 day of the month.  If the any of the digit fields are not known, then question
    522 marks are used in place of the digits.
    523 
    524 Examples:
    525 
    526 [Date "1992.08.31"]
    527 
    528 [Date "1993.??.??"]
    529 
    530 [Date "2001.01.01"]
    531 
    532 
    533 8.1.1.4: The Round tag
    534 
    535 The Round tag value gives the playing round for the game.  In a match
    536 competition, this value is the number of the game played.  If the use of a
    537 round number is inappropriate, then the field should be a single hyphen
    538 character.  If the round is unknown, a single question mark should appear as
    539 the tag value.
    540 
    541 Some organizers employ unusual round designations and have multipart playing
    542 rounds and sometimes even have conditional rounds.  In these cases, a multipart
    543 round identifier can be made from a sequence of integer round numbers separated
    544 by periods.  The leftmost integer represents the most significant round and
    545 succeeding integers represent round numbers in descending hierarchical order.
    546 
    547 Examples:
    548 
    549 [Round "1"]
    550 
    551 [Round "3.1"]
    552 
    553 [Round "4.1.2"]
    554 
    555 
    556 8.1.1.5: The White tag
    557 
    558 The White tag value is the name of the player or players of the white pieces.
    559 The names are given as they would appear in a telephone directory.  The family
    560 or last name appears first.  If a first name or first initial is available, it
    561 is separated from the family name by a comma and a space.  Finally, one or more
    562 middle initials may appear.  (Wherever a comma appears, the very next character
    563 should be a space.  Wherever an initial appears, the very next character should
    564 be a period.)  If the name is unknown, a single question mark should appear as
    565 the tag value.
    566 
    567 The intent is to allow meaningful ASCII sorting of the tag value that is
    568 independent of regional name formation customs.  If more than one person is
    569 playing the white pieces, the names are listed in alphabetical order and are
    570 separated by the colon character between adjacent entries.  A player who is
    571 also a computer program should have appropriate version information listed
    572 after the name of the program.
    573 
    574 The format used in the FIDE Rating Lists is appropriate for use for player name
    575 tags.
    576 
    577 Examples:
    578 
    579 [White "Tal, Mikhail N."]
    580 
    581 [White "van der Wiel, Johan"]
    582 
    583 [White "Acme Pawngrabber v.3.2"]
    584 
    585 [White "Fine, R."]
    586 
    587 
    588 8.1.1.6: The Black tag
    589 
    590 The Black tag value is the name of the player or players of the black pieces.
    591 The names are given here as they are for the White tag value.
    592 
    593 Examples:
    594 
    595 [Black "Lasker, Emmanuel"]
    596 
    597 [Black "Smyslov, Vasily V."]
    598 
    599 [Black "Smith, John Q.:Woodpusher 2000"]
    600 
    601 [Black "Morphy"]
    602 
    603 
    604 8.1.1.7: The Result tag
    605 
    606 The Result field value is the result of the game.  It is always exactly the
    607 same as the game termination marker that concludes the associated movetext.  It
    608 is always one of four possible values: "1-0" (White wins), "0-1" (Black wins),
    609 "1/2-1/2" (drawn game), and "*" (game still in progress, game abandoned, or
    610 result otherwise unknown).  Note that the digit zero is used in both of the
    611 first two cases; not the letter "O".
    612 
    613 All possible examples:
    614 
    615 [Result "0-1"]
    616 
    617 [Result "1-0"]
    618 
    619 [Result "1/2-1/2"]
    620 
    621 [Result "*"]
    622 
    623 
    624 8.2: Movetext section
    625 
    626 The movetext section is composed of chess moves, move number indications,
    627 optional annotations, and a single concluding game termination marker.
    628 
    629 Because illegal moves are not real chess moves, they are not permitted in PGN
    630 movetext.  They may appear in commentary, however.  One would hope that illegal
    631 moves are relatively rare in games worthy of recording.
    632 
    633 
    634 8.2.1: Movetext line justification
    635 
    636 In PGN import format, tokens in the movetext do not require any specific line
    637 justification.
    638 
    639 In PGN export format, tokens in the movetext are placed left justified on
    640 successive text lines each of which has less than 80 printing characters.  As
    641 many tokens as possible are placed on a line with the remainder appearing on
    642 successive lines.  A single space character appears between any two adjacent
    643 symbol tokens on the same line in the movetext.  As with the tag pair section,
    644 a single empty line follows the last line of data to conclude the movetext
    645 section.
    646 
    647 Neither the first or the last character on an export format PGN line is a
    648 space.  (This may change in the case of commentary; this area is currently
    649 under development.)
    650 
    651 
    652 8.2.2: Movetext move number indications
    653 
    654 A move number indication is composed of one or more adjacent digits (an integer
    655 token) followed by zero or more periods.  The integer portion of the indication
    656 gives the move number of the immediately following white move (if present) and
    657 also the immediately following black move (if present).
    658 
    659 
    660 8.2.2.1: Import format move number indications
    661 
    662 PGN import format does not require move number indications.  It does not
    663 prohibit superfluous move number indications anywhere in the movetext as long
    664 as the move numbers are correct.
    665 
    666 PGN import format move number indications may have zero or more period
    667 characters following the digit sequence that gives the move number; one or more
    668 white space characters may appear between the digit sequence and the period(s).
    669 
    670 
    671 8.2.2.2: Export format move number indications
    672 
    673 There are two export format move number indication formats, one for use
    674 appearing immediately before a white move element and one for use appearing
    675 immediately before a black move element.  A white move number indication is
    676 formed from the integer giving the fullmove number with a single period
    677 character appended.  A black move number indication is formed from the integer
    678 giving the fullmove number with three period characters appended.
    679 
    680 All white move elements have a preceding move number indication.  A black move
    681 element has a preceding move number indication only in two cases: first, if
    682 there is intervening annotation or commentary between the black move and the
    683 previous white move; and second, if there is no previous white move in the
    684 special case where a game starts from a position where Black is the active
    685 player.
    686 
    687 There are no other cases where move number indications appear in PGN export
    688 format.
    689 
    690 
    691 8.2.3: Movetext SAN (Standard Algebraic Notation)
    692 
    693 SAN (Standard Algebraic Notation) is a representation standard for chess moves
    694 using the ASCII Latin alphabet.
    695 
    696 Examples of SAN recorded games are found throughout most modern chess
    697 publications.  SAN as presented in this document uses English language single
    698 character abbreviations for chess pieces, although this is easily changed in
    699 the source.  English is chosen over other languages because it appears to be
    700 the most widely recognized.
    701 
    702 An alternative to SAN is FAN (Figurine Algebraic Notation).  FAN uses miniature
    703 piece icons instead of single letter piece abbreviations.  The two notations
    704 are otherwise identical.
    705 
    706 
    707 8.2.3.1: Square identification
    708 
    709 SAN identifies each of the sixty four squares on the chessboard with a unique
    710 two character name.  The first character of a square identifier is the file of
    711 the square; a file is a column of eight squares designated by a single lower
    712 case letter from "a" (leftmost or queenside) up to and including "h" (rightmost
    713 or kingside).  The second character of a square identifier is the rank of the
    714 square; a rank is a row of eight squares designated by a single digit from "1"
    715 (bottom side [White's first rank]) up to and including "8" (top side [Black's
    716 first rank]).  The initial squares of some pieces are: white queen rook at a1,
    717 white king at e1, black queen knight pawn at b7, and black king rook at h8.
    718 
    719 
    720 8.2.3.2: Piece identification
    721 
    722 SAN identifies each piece by a single upper case letter.  The standard English
    723 values: pawn = "P", knight = "N", bishop = "B", rook = "R", queen = "Q", and
    724 king = "K".
    725 
    726 The letter code for a pawn is not used for SAN moves in PGN export format
    727 movetext.  However, some PGN import software disambiguation code may allow for
    728 the appearance of pawn letter codes.  Also, pawn and other piece letter codes
    729 are needed for use in some tag pair and annotation constructs.
    730 
    731 It is admittedly a bit chauvinistic to select English piece letters over those
    732 from other languages.  There is a slight justification in that English is a de
    733 facto universal second language among most chessplayers and program users.  It
    734 is probably the best that can be done for now.  A later section of this
    735 document gives alternative piece letters, but these should be used only for
    736 local presentation software and not for archival storage or for dynamic
    737 interchange among programs.
    738 
    739 
    740 8.2.3.3: Basic SAN move construction
    741 
    742 A basic SAN move is given by listing the moving piece letter (omitted for
    743 pawns) followed by the destination square.  Capture moves are denoted by the
    744 lower case letter "x" immediately prior to the destination square; pawn
    745 captures include the file letter of the originating square of the capturing
    746 pawn immediately prior to the "x" character.
    747 
    748 SAN kingside castling is indicated by the sequence "O-O"; queenside castling is
    749 indicated by the sequence "O-O-O".  Note that the upper case letter "O" is
    750 used, not the digit zero.  The use of a zero character is not only incompatible
    751 with traditional text practices, but it can also confuse parsing algorithms
    752 which also have to understand about move numbers and game termination markers.
    753 Also note that the use of the letter "O" is consistent with the practice of
    754 having all chess move symbols start with a letter; also, it follows the
    755 convention that all non-pwn move symbols start with an upper case letter.
    756 
    757 En passant captures do not have any special notation; they are formed as if the
    758 captured pawn were on the capturing pawn's destination square.  Pawn promotions
    759 are denoted by the equal sign "=" immediately following the destination square
    760 with a promoted piece letter (indicating one of knight, bishop, rook, or queen)
    761 immediately following the equal sign.  As above, the piece letter is in upper
    762 case.
    763 
    764 
    765 8.2.3.4: Disambiguation
    766 
    767 In the case of ambiguities (multiple pieces of the same type moving to the same
    768 square), the first appropriate disambiguating step of the three following steps
    769 is taken:
    770 
    771 First, if the moving pieces can be distinguished by their originating files,
    772 the originating file letter of the moving piece is inserted immediately after
    773 the moving piece letter.
    774 
    775 Second (when the first step fails), if the moving pieces can be distinguished
    776 by their originating ranks, the originating rank digit of the moving piece is
    777 inserted immediately after the moving piece letter.
    778 
    779 Third (when both the first and the second steps fail), the two character square
    780 coordinate of the originating square of the moving piece is inserted
    781 immediately after the moving piece letter.
    782 
    783 Note that the above disambiguation is needed only to distinguish among moves of
    784 the same piece type to the same square; it is not used to distinguish among
    785 attacks of the same piece type to the same square.  An example of this would be
    786 a position with two white knights, one on square c3 and one on square g1 and a
    787 vacant square e2 with White to move.  Both knights attack square e2, and if
    788 both could legally move there, then a file disambiguation is needed; the
    789 (nonchecking) knight moves would be "Nce2" and "Nge2".  However, if the white
    790 king were at square e1 and a black bishop were at square b4 with a vacant
    791 square d2 (thus an absolute pin of the white knight at square c3), then only
    792 one white knight (the one at square g1) could move to square e2: "Ne2".
    793 
    794 
    795 8.2.3.5: Check and checkmate indication characters
    796 
    797 If the move is a checking move, the plus sign "+" is appended as a suffix to
    798 the basic SAN move notation; if the move is a checkmating move, the octothorpe
    799 sign "#" is appended instead.
    800 
    801 Neither the appearance nor the absence of either a check or checkmating
    802 indicator is used for disambiguation purposes.  This means that if two (or
    803 more) pieces of the same type can move to the same square the differences in
    804 checking status of the moves does not allieviate the need for the standard rank
    805 and file disabiguation described above.  (Note that a difference in checking
    806 status for the above may occur only in the case of a discovered check.)
    807 
    808 Neither the checking or checkmating indicators are considered annotation as
    809 they do not communicate subjective information.  Therefore, they are
    810 qualitatively different from move suffix annotations like "!" and "?".
    811 Subjective move annotations are handled using Numeric Annotation Glyphs as
    812 described in a later section of this document.
    813 
    814 There are no special markings used for double checks or discovered checks.
    815 
    816 There are no special markings used for drawing moves.
    817 
    818 
    819 8.2.3.6: SAN move length
    820 
    821 SAN moves can be as short as two characters (e.g., "d4"), or as long as seven
    822 characters (e.g., "Qa6xb7#", "fxg1=Q+").  The average SAN move length seen in
    823 realistic games is probably just fractionally longer than three characters.  If
    824 the SAN rules seem complicated, be assured that the earlier notation systems of
    825 LEN (Long English Notation) and EDN (English Descriptive Notation) are much
    826 more complex, and that LAN (Long Algebraic Notation, the predecessor of SAN) is
    827 unnecessarily bulky.
    828 
    829 
    830 8.2.3.7: Import and export SAN
    831 
    832 PGN export format always uses the above canonical SAN to represent moves in the
    833 movetext section of a PGN game.  Import format is somewhat more relaxed and it
    834 makes allowances for moves that do not conform exactly to the canonical format.
    835 However, these allowances may differ among different PGN reader programs.  Only
    836 data appearing in export format is in all cases guaranteed to be importable
    837 into all PGN readers.
    838 
    839 There are a number of suggested guidelines for use with implementing PGN reader
    840 software for permitting non-canonical SAN move representation.  The idea is to
    841 have a PGN reader apply various transformations to attempt to discover the move
    842 that is represented by non-canonical input.  Some suggested transformations
    843 include: letter case remapping, capture indicator insertion, check indicator
    844 insertion, and checkmate indicator insertion.
    845 
    846 
    847 8.2.3.8: SAN move suffix annotations
    848 
    849 Import format PGN allows for the use of traditional suffix annotations for
    850 moves.  There are exactly six such annotations available: "!", "?", "!!", "!?",
    851 "?!", and "??".  At most one such suffix annotation may appear per move, and if
    852 present, it is always the last part of the move symbol.
    853 
    854 When exported, a move suffix annotation is translated into the corresponding
    855 Numeric Annotation Glyph as described in a later section of this document.  For
    856 example, if the single move symbol "Qxa8?" appears in an import format PGN
    857 movetext, it would be replaced with the two adjacent symbols "Qxa8 $2".
    858 
    859 
    860 8.2.4: Movetext NAG (Numeric Annotation Glyph)
    861 
    862 An NAG (Numeric Annotation Glyph) is a movetext element that is used to
    863 indicate a simple annotation in a language independent manner.  An NAG is
    864 formed from a dollar sign ("$") with a non-negative decimal integer suffix.
    865 The non-negative integer must be from zero to 255 in value.
    866 
    867 
    868 8.2.5: Movetext RAV (Recursive Annotation Variation)
    869 
    870 An RAV (Recursive Annotation Variation) is a sequence of movetext containing
    871 one or more moves enclosed in parentheses.  An RAV is used to represent an
    872 alternative variation.  The alternate move sequence given by an RAV is one that
    873 may be legally played by first unplaying the move that appears immediately
    874 prior to the RAV.  Because the RAV is a recursive construct, it may be nested.
    875 
    876 *** The specification for import/export representation of RAV elements needs
    877 further development.
    878 
    879 
    880 8.2.6: Game Termination Markers
    881 
    882 Each movetext section has exactly one game termination marker; the marker
    883 always occurs as the last element in the movetext.  The game termination marker
    884 is a symbol that is one of the following four values: "1-0" (White wins), "0-1"
    885 (Black wins), "1/2-1/2" (drawn game), and "*" (game in progress, result
    886 unknown, or game abandoned).  Note that the digit zero is used in the above;
    887 not the upper case letter "O".  The game termination marker appearing in the
    888 movetext of a game must match the value of the game's Result tag pair.  (While
    889 the marker appears as a string in the Result tag, it appears as a symbol
    890 without quotes in the movetext.)
    891 
    892 
    893 9: Supplemental tag names
    894 
    895 The following tag names and their associated semantics are recommended for use
    896 for information not contained in the Seven Tag Roster.
    897 
    898 
    899 9.1: Player related information
    900 
    901 Note that if there is more than one player field in an instance of a player
    902 (White or Black) tag, then there will be corresponding multiple fields in any
    903 of the following tags.  For example, if the White tag has the three field value
    904 "Jones:Smith:Zacharias" (a consultation game), then the WhiteTitle tag could
    905 have a value of "IM:-:GM" if Jones was an International Master, Smith was
    906 untitled, and Zacharias was a Grandmaster.
    907 
    908 
    909 9.1.1: Tags: WhiteTitle, BlackTitle
    910 
    911 These use string values such as "FM", "IM", and "GM"; these tags are used only
    912 for the standard abbreviations for FIDE titles.  A value of "-" is used for an
    913 untitled player.
    914 
    915 
    916 9.1.2: Tags: WhiteElo, BlackElo
    917 
    918 These tags use integer values; these are used for FIDE Elo ratings.  A value of
    919 "-" is used for an unrated player.
    920 
    921 
    922 9.1.3: Tags: WhiteUSCF, BlackUSCF
    923 
    924 These tags use integer values; these are used for USCF (United States Chess
    925 Federation) ratings.  Similar tag names can be constructed for other rating
    926 agencies.
    927 
    928 
    929 9.1.4: Tags: WhiteNA, BlackNA
    930 
    931 These tags use string values; these are the e-mail or network addresses of the
    932 players.  A value of "-" is used for a player without an electronic address.
    933 
    934 
    935 9.1.5: Tags: WhiteType, BlackType
    936 
    937 These tags use string values; these describe the player types.  The value
    938 "human" should be used for a person while the value "program" should be used
    939 for algorithmic (computer) players.
    940 
    941 
    942 9.2: Event related information
    943 
    944 The following tags are used for providing additional information about the
    945 event.
    946 
    947 
    948 9.2.1: Tag: EventDate
    949 
    950 This uses a date value, similar to the Date tag field, that gives the starting
    951 date of the Event.
    952 
    953 
    954 9.2.2: Tag: EventSponsor
    955 
    956 This uses a string value giving the name of the sponsor of the event.
    957 
    958 
    959 9.2.3: Tag: Section
    960 
    961 This uses a string; this is used for the playing section of a tournament (e.g.,
    962 "Open" or "Reserve").
    963 
    964 
    965 9.2.4: Tag: Stage
    966 
    967 This uses a string; this is used for the stage of a multistage event (e.g.,
    968 "Preliminary" or "Semifinal").
    969 
    970 
    971 9.2.5: Tag: Board
    972 
    973 This uses an integer; this identifies the board number in a team event and also
    974 in a simultaneous exhibition.
    975 
    976 
    977 9.3: Opening information (locale specific)
    978 
    979 The following tag pairs are used for traditional opening names.  The associated
    980 tag values will vary according to the local language in use.
    981 
    982 
    983 9.3.1: Tag: Opening
    984 
    985 This uses a string; this is used for the traditional opening name.  This will
    986 vary by locale.  This tag pair is associated with the use of the EPD opcode
    987 "v0" described in a later section of this document.
    988 
    989 
    990 9.3.2: Tag: Variation
    991 
    992 This uses a string; this is used to further refine the Opening tag.  This will
    993 vary by locale.  This tag pair is associated with the use of the EPD opcode
    994 "v1" described in a later section of this document.
    995 
    996 
    997 9.3.3: Tag: SubVariation
    998 
    999 This uses a string; this is used to further refine the Variation tag.  This
   1000 will vary by locale.  This tag pair is associated with the use of the EPD
   1001 opcode "v2" described in a later section of this document.
   1002 
   1003 
   1004 9.4: Opening information (third party vendors)
   1005 
   1006 The following tag pairs are used for representing opening identification
   1007 according to various third party vendors and organizations.  References to
   1008 these organizations does not imply any endorsement of them or any endorsement
   1009 by them.
   1010 
   1011 
   1012 9.4.1: Tag: ECO
   1013 
   1014 This uses a string of either the form "XDD" or the form "XDD/DD" where the "X"
   1015 is a letter from "A" to "E" and the "D" positions are digits; this is used for
   1016 an opening designation from the five volume _Encyclopedia of Chess Openings_.
   1017 This tag pair is associated with the use of the EPD opcode "eco" described in a
   1018 later section of this document.
   1019 
   1020 
   1021 9.4.2: Tag: NIC
   1022 
   1023 This uses a string; this is used for an opening designation from the _New in
   1024 Chess_ database.  This tag pair is associated with the use of the EPD opcode
   1025 "nic" described in a later section of this document.
   1026 
   1027 
   1028 9.5: Time and date related information
   1029 
   1030 The following tags assist with further refinement of the time and data
   1031 information associated with a game.
   1032 
   1033 
   1034 9.5.1: Tag: Time
   1035 
   1036 This uses a time-of-day value in the form "HH:MM:SS"; similar to the Date tag
   1037 except that it denotes the local clock time (hours, minutes, and seconds) of
   1038 the start of the game.  Note that colons, not periods, are used for field
   1039 separators for the Time tag value.  The value is taken from the local time
   1040 corresponding to the location given in the Site tag pair.
   1041 
   1042 
   1043 9.5.2: Tag: UTCTime
   1044 
   1045 This tag is similar to the Time tag except that the time is given according to
   1046 the Universal Coordinated Time standard.
   1047 
   1048 
   1049 9.5.3: Tag:; UTCDate
   1050 
   1051 This tag is similar to the Date tag except that the date is given according to
   1052 the Universal Coordinated Time standard.
   1053 
   1054 
   1055 9.6: Time control
   1056 
   1057 The follwing tag is used to help describe the time control used with the game.
   1058 
   1059 
   1060 9.6.1: Tag: TimeControl
   1061 
   1062 This uses a list of one or more time control fields.  Each field contains a
   1063 descriptor for each time control period; if more than one descriptor is present
   1064 then they are separated by the colon character (":").  The descriptors appear
   1065 in the order in which they are used in the game.  The last field appearing is
   1066 considered to be implicitly repeated for further control periods as needed.
   1067 
   1068 There are six kinds of TimeControl fields.
   1069 
   1070 The first kind is a single question mark ("?") which means that the time
   1071 control mode is unknown.  When used, it is usually the only descriptor present.
   1072 
   1073 The second kind is a single hyphen ("-") which means that there was no time
   1074 control mode in use.  When used, it is usually the only descriptor present.
   1075 
   1076 The third Time control field kind is formed as two positive integers separated
   1077 by a solidus ("/") character.  The first integer is the number of moves in the
   1078 period and the second is the number of seconds in the period.  Thus, a time
   1079 control period of 40 moves in 2 1/2 hours would be represented as "40/9000".
   1080 
   1081 The fourth TimeControl field kind is used for a "sudden death" control period.
   1082 It should only be used for the last descriptor in a TimeControl tag value.  It
   1083 is sometimes the only descriptor present.  The format consists of a single
   1084 integer that gives the number of seconds in the period.  Thus, a blitz game
   1085 would be represented with a TimeControl tag value of "300".
   1086 
   1087 The fifth TimeControl field kind is used for an "incremental" control period.
   1088 It should only be used for the last descriptor in a TimeControl tag value and
   1089 is usually the only descriptor in the value.  The format consists of two
   1090 positive integers separated by a plus sign ("+") character.  The first integer
   1091 gives the minimum number of seconds allocated for the period and the second
   1092 integer gives the number of extra seconds added after each move is made.  So,
   1093 an incremental time control of 90 minutes plus one extra minute per move would
   1094 be given by "4500+60" in the TimeControl tag value.
   1095 
   1096 The sixth TimeControl field kind is used for a "sandclock" or "hourglass"
   1097 control period.  It should only be used for the last descriptor in a
   1098 TimeControl tag value and is usually the only descriptor in the value.  The
   1099 format consists of an asterisk ("*") immediately followed by a positive
   1100 integer.  The integer gives the total number of seconds in the sandclock
   1101 period.  The time control is implemented as if a sandclock were set at the
   1102 start of the period with an equal amount of sand in each of the two chambers
   1103 and the players invert the sandclock after each move with a time forfeit
   1104 indicated by an empty upper chamber.  Electronic implementation of a physical
   1105 sandclock may be used.  An example sandclock specification for a common three
   1106 minute egg timer sandclock would have a tag value of "*180".
   1107 
   1108 Additional TimeControl field kinds will be defined as necessary.
   1109 
   1110 
   1111 9.7: Alternative starting positions
   1112 
   1113 There are two tags defined for assistance with describing games that did not
   1114 start from the usual initial array.
   1115 
   1116 
   1117 9.7.1: Tag: SetUp
   1118 
   1119 This tag takes an integer that denotes the "set-up" status of the game.  A
   1120 value of "0" indicates that the game has started from the usual initial array.
   1121 A value of "1" indicates that the game started from a set-up position; this
   1122 position is given in the "FEN" tag pair.  This tag must appear for a game
   1123 starting with a set-up position.  If it appears with a tag value of "1", a FEN
   1124 tag pair must also appear.
   1125 
   1126 
   1127 9.7.2: Tag: FEN
   1128 
   1129 This tag uses a string that gives the Forsyth-Edwards Notation for the starting
   1130 position used in the game.  FEN is described in a later section of this
   1131 document.  If a SetUp tag appears with a tag value of "1", the FEN tag pair is
   1132 also required.
   1133 
   1134 
   1135 9.8: Game conclusion
   1136 
   1137 There is a single tag that discusses the conclusion of the game.
   1138 
   1139 
   1140 9.8.1: Tag: Termination
   1141 
   1142 This takes a string that describes the reason for the conclusion of the game.
   1143 While the Result tag gives the result of the game, it does not provide any
   1144 extra information and so the Termination tag is defined for this purpose.
   1145 
   1146 Strings that may appear as Termination tag values:
   1147 
   1148 * "abandoned": abandoned game.
   1149 
   1150 * "adjudication": result due to third party adjudication process.
   1151 
   1152 * "death": losing player called to greater things, one hopes.
   1153 
   1154 * "emergency": game concluded due to unforeseen circumstances.
   1155 
   1156 * "normal": game terminated in a normal fashion.
   1157 
   1158 * "rules infraction": administrative forfeit due to losing player's failure to
   1159 observe either the Laws of Chess or the event regulations.
   1160 
   1161 * "time forfeit": loss due to losing player's failure to meet time control
   1162 requirements.
   1163 
   1164 * "unterminated": game not terminated.
   1165 
   1166 
   1167 9.9: Miscellaneous
   1168 
   1169 These are tags that can be briefly described and that doon't fit well inother
   1170 sections.
   1171 
   1172 
   1173 9.9.1: Tag: Annotator
   1174 
   1175 This tag uses a name or names in the format of the player name tags; this
   1176 identifies the annotator or annotators of the game.
   1177 
   1178 
   1179 9.9.2: Tag: Mode
   1180 
   1181 This uses a string that gives the playing mode of the game.  Examples: "OTB"
   1182 (over the board), "PM" (paper mail), "EM" (electronic mail), "ICS" (Internet
   1183 Chess Server), and "TC" (general telecommunication).
   1184 
   1185 
   1186 9.9.3: Tag: PlyCount
   1187 
   1188 This tag takes a single integer that gives the number of ply (moves) in the
   1189 game.
   1190 
   1191 
   1192 10: Numeric Annotation Glyphs
   1193 
   1194 NAG zero is used for a null annotation; it is provided for the convenience of
   1195 software designers as a placeholder value and should probably not be used in
   1196 external PGN data.
   1197 
   1198 NAGs with values from 1 to 9 annotate the move just played.
   1199 
   1200 NAGs with values from 10 to 135 modify the current position.
   1201 
   1202 NAGs with values from 136 to 139 describe time pressure.
   1203 
   1204 Other NAG values are reserved for future definition.
   1205 
   1206 Note: the number assignments listed below should be considered preliminary in
   1207 nature; they are likely to be changed as a result of reviewer feedback.
   1208 
   1209 NAG    Interpretation
   1210 ---    --------------
   1211   0    null annotation
   1212   1    good move (traditional "!")
   1213   2    poor move (traditional "?")
   1214   3    very good move (traditional "!!")
   1215   4    very poor move (traditional "??")
   1216   5    speculative move (traditional "!?")
   1217   6    questionable move (traditional "?!")
   1218   7    forced move (all others lose quickly)
   1219   8    singular move (no reasonable alternatives)
   1220   9    worst move
   1221  10    drawish position
   1222  11    equal chances, quiet position
   1223  12    equal chances, active position
   1224  13    unclear position
   1225  14    White has a slight advantage
   1226  15    Black has a slight advantage
   1227  16    White has a moderate advantage
   1228  17    Black has a moderate advantage
   1229  18    White has a decisive advantage
   1230  19    Black has a decisive advantage
   1231  20    White has a crushing advantage (Black should resign)
   1232  21    Black has a crushing advantage (White should resign)
   1233  22    White is in zugzwang
   1234  23    Black is in zugzwang
   1235  24    White has a slight space advantage
   1236  25    Black has a slight space advantage
   1237  26    White has a moderate space advantage
   1238  27    Black has a moderate space advantage
   1239  28    White has a decisive space advantage
   1240  29    Black has a decisive space advantage
   1241  30    White has a slight time (development) advantage
   1242  31    Black has a slight time (development) advantage
   1243  32    White has a moderate time (development) advantage
   1244  33    Black has a moderate time (development) advantage
   1245  34    White has a decisive time (development) advantage
   1246  35    Black has a decisive time (development) advantage
   1247  36    White has the initiative
   1248  37    Black has the initiative
   1249  38    White has a lasting initiative
   1250  39    Black has a lasting initiative
   1251  40    White has the attack
   1252  41    Black has the attack
   1253  42    White has insufficient compensation for material deficit
   1254  43    Black has insufficient compensation for material deficit
   1255  44    White has sufficient compensation for material deficit
   1256  45    Black has sufficient compensation for material deficit
   1257  46    White has more than adequate compensation for material deficit
   1258  47    Black has more than adequate compensation for material deficit
   1259  48    White has a slight center control advantage
   1260  49    Black has a slight center control advantage
   1261  50    White has a moderate center control advantage
   1262  51    Black has a moderate center control advantage
   1263  52    White has a decisive center control advantage
   1264  53    Black has a decisive center control advantage
   1265  54    White has a slight kingside control advantage
   1266  55    Black has a slight kingside control advantage
   1267  56    White has a moderate kingside control advantage
   1268  57    Black has a moderate kingside control advantage
   1269  58    White has a decisive kingside control advantage
   1270  59    Black has a decisive kingside control advantage
   1271  60    White has a slight queenside control advantage
   1272  61    Black has a slight queenside control advantage
   1273  62    White has a moderate queenside control advantage
   1274  63    Black has a moderate queenside control advantage
   1275  64    White has a decisive queenside control advantage
   1276  65    Black has a decisive queenside control advantage
   1277  66    White has a vulnerable first rank
   1278  67    Black has a vulnerable first rank
   1279  68    White has a well protected first rank
   1280  69    Black has a well protected first rank
   1281  70    White has a poorly protected king
   1282  71    Black has a poorly protected king
   1283  72    White has a well protected king
   1284  73    Black has a well protected king
   1285  74    White has a poorly placed king
   1286  75    Black has a poorly placed king
   1287  76    White has a well placed king
   1288  77    Black has a well placed king
   1289  78    White has a very weak pawn structure
   1290  79    Black has a very weak pawn structure
   1291  80    White has a moderately weak pawn structure
   1292  81    Black has a moderately weak pawn structure
   1293  82    White has a moderately strong pawn structure
   1294  83    Black has a moderately strong pawn structure
   1295  84    White has a very strong pawn structure
   1296  85    Black has a very strong pawn structure
   1297  86    White has poor knight placement
   1298  87    Black has poor knight placement
   1299  88    White has good knight placement
   1300  89    Black has good knight placement
   1301  90    White has poor bishop placement
   1302  91    Black has poor bishop placement
   1303  92    White has good bishop placement
   1304  93    Black has good bishop placement
   1305  84    White has poor rook placement
   1306  85    Black has poor rook placement
   1307  86    White has good rook placement
   1308  87    Black has good rook placement
   1309  98    White has poor queen placement
   1310  99    Black has poor queen placement
   1311 100    White has good queen placement
   1312 101    Black has good queen placement
   1313 102    White has poor piece coordination
   1314 103    Black has poor piece coordination
   1315 104    White has good piece coordination
   1316 105    Black has good piece coordination
   1317 106    White has played the opening very poorly
   1318 107    Black has played the opening very poorly
   1319 108    White has played the opening poorly
   1320 109    Black has played the opening poorly
   1321 110    White has played the opening well
   1322 111    Black has played the opening well
   1323 112    White has played the opening very well
   1324 113    Black has played the opening very well
   1325 114    White has played the middlegame very poorly
   1326 115    Black has played the middlegame very poorly
   1327 116    White has played the middlegame poorly
   1328 117    Black has played the middlegame poorly
   1329 118    White has played the middlegame well
   1330 119    Black has played the middlegame well
   1331 120    White has played the middlegame very well
   1332 121    Black has played the middlegame very well
   1333 122    White has played the ending very poorly
   1334 123    Black has played the ending very poorly
   1335 124    White has played the ending poorly
   1336 125    Black has played the ending poorly
   1337 126    White has played the ending well
   1338 127    Black has played the ending well
   1339 128    White has played the ending very well
   1340 129    Black has played the ending very well
   1341 130    White has slight counterplay
   1342 131    Black has slight counterplay
   1343 132    White has moderate counterplay
   1344 133    Black has moderate counterplay
   1345 134    White has decisive counterplay
   1346 135    Black has decisive counterplay
   1347 136    White has moderate time control pressure
   1348 137    Black has moderate time control pressure
   1349 138    White has severe time control pressure
   1350 139    Black has severe time control pressure
   1351 
   1352 
   1353 11: File names and directories
   1354 
   1355 File names chosen for PGN data should be both informative and portable.  The
   1356 directory names and arrangements should also be chosen for the same reasons and
   1357 also for ease of navigation.
   1358 
   1359 Some of suggested file and directory names may be difficult or impossible to
   1360 represent on certain computing systems.  Use of appropriate conversion customs
   1361 is encouraged.
   1362 
   1363 
   1364 11.1: File name suffix for PGN data
   1365 
   1366 The use of the file suffix ".pgn" is encouraged for ASCII text files containing
   1367 PGN data.
   1368 
   1369 
   1370 11.2: File name formation for PGN data for a specific player
   1371 
   1372 PGN games for a specific player should have a file name consisting of the
   1373 player's last name followed by the ".pgn" suffix.
   1374 
   1375 
   1376 11.3: File name formation for PGN data for a specific event
   1377 
   1378 PGN games for a specific event should have a file name consisting of the
   1379 event's name followed by the ".pgn" suffix.
   1380 
   1381 
   1382 11.4: File name formation for PGN data for chronologically ordered games
   1383 
   1384 PGN data files used for chronologically ordered (oldest first) archives use
   1385 date information as file name root strings.  A file containing all the PGN
   1386 games for a given year would have an eight character name in the format
   1387 "YYYY.pgn".  A file containing PGN data for a given month would have a ten
   1388 character name in the format "YYYYMM.pgn".  Finally, a file for PGN games for a
   1389 single day would have a twelve character name in the format "YYYYMMDD.pgn".
   1390 Large files are split into smaller files as needed.
   1391 
   1392 As game files are commonly arranged by chronological order, games with missing
   1393 or incomplete Date tag pair data are to be avoided.  Any question mark
   1394 characters in a Date tag value will be treated as zero digits for collation
   1395 within a file and also for file naming.
   1396 
   1397 Large quantities of PGN data arranged by chronological order should be
   1398 organized into hierarchical directories.  A directory containing all PGN data
   1399 for a given year would have a four character name in the format "YYYY";
   1400 directories containing PGN files for a given month would have a six character
   1401 name in the format "YYYYMM".
   1402 
   1403 
   1404 11.5: Suggested directory tree organization
   1405 
   1406 A suggested directory arrangement for ftp sites and CD-ROM distributions:
   1407 
   1408 * PGN: master directory of the PGN subtree (pub/chess/Game-Databases/PGN)
   1409 
   1410 * PGN/Events: directory of PGN files, each for a specific event
   1411 
   1412 * PGN/Events/News: news and status of the event collection
   1413 
   1414 * PGN/Events/ReadMe: brief description of the local directory contents
   1415 
   1416 * PGN/MGR: directory of the Master Games Repository subtree
   1417 
   1418 * PGN/MGR/News: news and status of the entire PGN/MGR subtree
   1419 
   1420 * PGN/MGR/ReadMe: brief description of the local directory contents
   1421 
   1422 * PGN/MGR/YYYY: directory of games or subtrees for the year YYYY
   1423 
   1424 * PGN/MGR/YYYY/ReadMe: description of local directory for year YYYY
   1425 
   1426 * PGN/MGR/YYYY/News: news and status for year YYYY data
   1427 
   1428 * PGN/News: news and status of the entire PGN subtree
   1429 
   1430 * PGN/Players: directory of PGN files, each for a specific player
   1431 
   1432 * PGN/Players/News: news and status of the player collection
   1433 
   1434 * PGN/Players/ReadMe: brief description of the local directory contents
   1435 
   1436 * PGN/ReadMe: brief description of the local directory contents
   1437 
   1438 * PGN/Standard: the PGN standard (this document)
   1439 
   1440 * PGN/Tools: software utilities that access PGN data
   1441 
   1442 
   1443 12: PGN collating sequence
   1444 
   1445 There is a standard sorting order for PGN games within a file.  This collation
   1446 is based on eight keys; these are the seven tag values of the STR and also the
   1447 movetext itself.
   1448 
   1449 The first (most important, primary key) is the Date tag.  Earlier dated games
   1450 appear prior to games played at a later date.  This field is sorted by
   1451 ascending numeric value first with the year, then the month, and finally the
   1452 day of the month.  Query characters used for unknown date digit values will be
   1453 treated as zero digit characters for ordering comparison.
   1454 
   1455 The second key is the Event tag.  This is sorted in ascending ASCII order.
   1456 
   1457 The third key is the Site tag.  This is sorted in ascending ASCII order.
   1458 
   1459 The fourth key is the Round tag.  This is sorted in ascending numeric order
   1460 based on the value of the integer used to denote the playing round.  A query or
   1461 hyphen used for the round is ordered before any integer value.  A query
   1462 character is ordered before a hyphen character.
   1463 
   1464 The fifth key is the White tag.  This is sorted in ascending ASCII order.
   1465 
   1466 The sixth key is the Black tag.  This is sorted in ascending ASCII order.
   1467 
   1468 The seventh key is the Result tag.  This is sorted in ascending ASCII order.
   1469 
   1470 The eighth key is the movetext itself.  This is sorted in ascending ASCII order
   1471 with the entire text including spaces and newline characters.
   1472 
   1473 
   1474 13: PGN software
   1475 
   1476 This section describes some PGN software that is either currently available or
   1477 expected to be available in the near future.  The entries are presented in
   1478 rough chronological order of their being made known to the PGN standard
   1479 coordinator.  Authors of PGN capable software are encouraged to contact the
   1480 coordinator (e-mail address listed near the start of this document) so that the
   1481 information may be included here in this section.
   1482 
   1483 In addition to the PGN standard, there are two more chess standards of interest
   1484 to the chess software community.  These are the FEN standard (Forsyth-Edwards
   1485 Notation) for position notation and the EPD standard (Extended Position
   1486 Description) for comprehensive position description for automated interprogram
   1487 processing.  These are described in a later section of this document.
   1488 
   1489 Some PGN software is freeware and can be gotten from ftp sites and other
   1490 sources.  Other PGN software is payware and appears as part of commercial
   1491 chessplaying programs and chess database managers.  Those who are interested in
   1492 the propagation of the PGN standard are encouraged to support manufacturers of
   1493 chess software that use the standard.  If a particular vendor does not offer
   1494 PGN compatibility, it is likely that a few letters to them along with a copy of
   1495 this specification may help them decide to include PGN support in their next
   1496 release.
   1497 
   1498 The staff at the University of Oklahoma at Norman (USA) have graciously
   1499 provided an ftp site (chess.uoknor.edu) for the storage of chess related data
   1500 and programs.  Because file names change over time, those accessing the site
   1501 are encouraged to first retrieve the file "pub/chess/ls-lR.gz" for a current
   1502 listing.  A scan of this listing will also help locate versions of PGN programs
   1503 for machine types and operating systems other than those listed below.  Further
   1504 information about this archive can be gotten from its administrator, Chris
   1505 Petroff (chris@uoknor.edu).
   1506 
   1507 For European users, the kind staff at the University of Hamburg (Germany) have
   1508 provided the ftp site ftp.math.uni-hamburg.de; this carries a daily mirror of
   1509 the pub/chess directory at the chess.uoknor.edu site.
   1510 
   1511 
   1512 13.1: The SAN Kit
   1513 
   1514 The "SAN Kit" is an ANSI C source chess programming toolkit available for free
   1515 from the ftp site chess.uoknor.edu in the directory pub/chess/Unix as the file
   1516 "SAN.tar.gz" (a gzip tar archive).  This kit contains code for PGN import and
   1517 export and can be used to "regularize" PGN data into reduced export format by
   1518 use of its "tfgg" command.  The SAN Kit also supports FEN I/O.  Code from this
   1519 kit is freely redistributable for anyone as long as future distribution is
   1520 unhindered for everyone.  The SAN Kit is undergoing continuous development,
   1521 although dates of future deliveries are quite difficult to predict and releases
   1522 sometimes appear months apart.  Suggestions and comments should be directed to
   1523 its author, Steven J. Edwards (sje@world.std.com).
   1524 
   1525 
   1526 13.2: pgnRead
   1527 
   1528 The program "pgnRead" runs under MS Windows 3.1 and provides an interactive
   1529 graphical user interface for scanning PGN data files.  This program includes a
   1530 colorful figurine chessboard display and scrolling controls for game and game
   1531 text selection.  It is available from the chess.uoknor.edu ftp site in the
   1532 pub/chess/DOS directory; several versions are available with names of the form
   1533 "pgnrd**.exe"; the latest at this writing is "PGNRD130.EXE".  Suggestions and
   1534 comments should be directed to its author, Keith Fuller (keithfx@aol.com).
   1535 
   1536 
   1537 13.3: mail2pgn/GIICS
   1538 
   1539 The program "mail2pgn" produces a PGN version of chess game data generated by
   1540 the ICS (Internet Chess Server).  It can be found at the chess.uoknor.edu ftp
   1541 site in the pub/chess/DOS directory as the file "mail2pgn.zip"  A C language
   1542 version is in the directory pub/chess/Unix as the file "mail2pgn.c".
   1543 Suggestions and comments should be directed to its author, John Aronson
   1544 (aronson@helios.ece.arizona.edu).  This code has been reportedly incorporated
   1545 into the GIICS (Graphical Interface for the ICS); suggestions and comments
   1546 should be directed to its author, Tony Acero (ace3@midway.uchicago.edu).
   1547 
   1548 There is a report that mail2pgn has been superseded by the newer program
   1549 "MV2PGN" described below.
   1550 
   1551 
   1552 13.4: XBoard
   1553 
   1554 "XBoard" is a comprehensive chess utility running under the X Window System
   1555 that provides a graphical user interface in a portable manner.  A new version
   1556 now handles PGN data.  It is available from the chess.uoknor.edu ftp site in
   1557 the pub/chess/X directory as the file "xboard-3.0.pl9.tar.gz".  Suggestions and
   1558 comments should be directed to its author, Tim Mann (mann@src.dec.com).
   1559 
   1560 
   1561 13.5: cupgn
   1562 
   1563 The program "cupgn" converts game data stored in the ChessBase format into PGN.
   1564 It is available from the chess.uoknor.edu ftp site in the
   1565 pub/chess/Game-Databases/CBUFF directory as the file "cupgn.tar.gz".  Another
   1566 version is in the directory pub/chess/DOS as the file "cupgn120.exe".
   1567 Suggestions and comments should be directed to its author, Anjo Anjewierden
   1568 (anjo@swi.psy.uva.nl).
   1569 
   1570 
   1571 13.6: Zarkov
   1572 
   1573 The current version (3.0) of the commercial chessplaying program "Zarkov" can
   1574 read and write games using PGN.  This program can also use the EPD standard for
   1575 communication with other EPD capable programs.  Historically, Zarkov is the
   1576 very first program to use EPD.  Suggestions and comments should be directed to
   1577 its author, John Stanback (jhs@icbdfcs1.fc.hp.com).
   1578 
   1579 A vendor for North America is:
   1580 
   1581     International Chess Enterprises
   1582     P.O. Box 19457
   1583     Seattle, WA 98109
   1584     USA
   1585     (800) 262-4277
   1586 
   1587 A vendor for Europe is:
   1588 
   1589     Gambit-Soft
   1590     Feckenhauser Strasse 27
   1591     D-78628 Rottweil
   1592     GERMANY
   1593     49-741-21573
   1594 
   1595 
   1596 13.7: Chess Assistant
   1597 
   1598 The upcoming version of the multifunction commercial database program "Chess
   1599 Assistant" will be able to use the PGN standard as an import and export option.
   1600 There is a report of a freeware program, "PGN2CA", that will convert PGN
   1601 databases into Chess Assistant format.  For more information, the contact is
   1602 Victor Zakharov, one of the members of the Chess Assistant development team
   1603 (VICTOR@ldis.cs.msu.su).
   1604 
   1605 A vendor for North America is:
   1606 
   1607     International Chess Enterprises
   1608     P.O. Box 19457
   1609     Seattle, WA 98109
   1610     USA
   1611     (800) 262-4277
   1612 
   1613 
   1614 13.8: BOOKUP
   1615 
   1616 The MS-DOS edition of the multifunction commercial program BOOKUP, version 8.1,
   1617 is able to use the EPD standard for communication with other EPD capable
   1618 programs.  It may also be PGN capable as well.
   1619 
   1620 The BOOKUP 8.1.1 Addenda notes dated 1993.12.17 provide comprehensive
   1621 information on how to use EPD in conjunction with "analyst" programs such as
   1622 Zarkov and HIARCS.  Specifically, the search and evaluation abilities of an
   1623 analyst program are combined with the information organization abilities of the
   1624 BOOKUP database program to provide position scoring.  This is done by first
   1625 having BOOKUP export a database in EPD format, then having an analyst program
   1626 annotate each EPD record with a numeric score, and then having BOOKUP import
   1627 the changed EPD file.  BOOKUP can then apply minimaxing to the imported
   1628 database; this results in scores from terminal positions being propagated back
   1629 to earlier positions and even back to moves from the starting array.
   1630 
   1631 For some reason, BOOKUP calls this process "backsolving", but it's really just
   1632 standard minimaxing.  In any case, it's a good example of how different
   1633 programs from different authors performing different types of tasks can be
   1634 integrated by use of a common, non-proprietary standard.  This allows for a new
   1635 set of powerful features that are beyond the capabilities of any one of the
   1636 individual component programs.
   1637 
   1638 BOOKUP allows for some customizing of EPD actions.  One such customization is
   1639 to require the positional evaluations to follow the EPD standard; this means
   1640 that the score is always given from the viewpoint of the active player.  This
   1641 is explained more fully in the section on the "ce" (centipawn evaluation)
   1642 opcode in the EPD description in a later section of this document.  To ensure
   1643 that BOOKUP handles the centipawn evaluations in the "right" way, the EPD
   1644 setting "Positive for White" must be set to "N".  This makes BOOKUP work
   1645 correctly with Zarkov and with all other programs that use the "right"
   1646 centipawn evaluation convention.  There is an apparent problem with HIARCS that
   1647 requires this option to be set to "Y"; but this really means that, if true,
   1648 HIARCS needs to be adjusted to use the "right" centipawn evaluation convention.
   1649 
   1650 A vendor in North America is:
   1651 
   1652     BOOKUP
   1653     2763 Kensington Place West
   1654     Columbus, OH 43202
   1655     USA
   1656     (800) 949-5445
   1657     (614) 263-7219
   1658 
   1659 
   1660 13.9: HIARCS
   1661 
   1662 The current version (2.1) of the commercial chessplaying program "HIARCS" is
   1663 able to use the EPD standard for communication with other EPD capable programs.
   1664 It may also be PGN capable as well.  More details will appear here as they
   1665 become available.
   1666 
   1667 A vendor in North America is:
   1668 
   1669     HIARCS
   1670     c/o BOOKUP
   1671     2763 Kensington Place West
   1672     Columbus, OH 43202
   1673     USA
   1674     (800) 949-5445
   1675     (614) 263-7219
   1676 
   1677 
   1678 13.10: Deja Vu
   1679 
   1680 The chess database "Deja Vu" from ChessWorks is a PGN compatible collection of
   1681 over 300,000 games.  It is available only on CD-ROM and is scheduled for
   1682 release in 1994.05 with periodic revisions thereafter.  The introductory price
   1683 is US$329.  For further information, the authors are John Crayton and Eric
   1684 Schiller and they can be contacted via e-mail (chesswks@netcom.com).
   1685 
   1686 
   1687 13.11: MV2PGN
   1688 
   1689 The program "MV2PGN" can be used to convert game data generated by both current
   1690 and older versions of the GIICS (Graphical Interface - Internet Chess Server).
   1691 The program is included in the self extracting archive available from
   1692 chess.uoknor.edu in the directory pub/chess/DOS as the file "ics2pgn.exe".
   1693 Source code is also included.  This program is reported to supersede the older
   1694 "mail2pgn" and was needed due to a change in ICS recording format in late 1993.
   1695 For further information about MV2PGN, the contact person is Gary Bastin
   1696 (gbastin@x102a.ess.harris.com).
   1697 
   1698 
   1699 13.12: The Hansen utilities (cb2pgn, nic2pgn, pgn2cb, pgn2nic)
   1700 
   1701 The Hansen utilities are used to convert among various chess data
   1702 representation formats.  The PGN related programs include: "cb2pgn.exe"
   1703 (convert ChessBase to PGN), "nic2pgn.exe" (convert NIC to PGN), "pgn2cb.exe"
   1704 (convert PGN to ChessBase), and "pgn2nic.exe" (convert PGN to NIC).
   1705 
   1706 The ChessBase related utilities (cb2pgn/pgn2cb) are found at chess.uoknor.edu
   1707 in the pub/chess/Game-Databases/ChessBase directory.
   1708 
   1709 The NIC related utilities (nic2pgn/pgn2nic) are found at chess.uoknor.edu in
   1710 the pub/chess/Game-Databases/NIC directory.
   1711 
   1712 For further information about the Hansen utilities, the contact person is the
   1713 author, Carsten Hansen (ch0506@hdc.hha.dk).
   1714 
   1715 
   1716 13.13: Slappy the Database
   1717 
   1718 "Slappy the Database" is a commercial chess database and translation program
   1719 scheduled for release no sooner than late 1994.  It is a low cost utility with
   1720 a simple character interface intended for those who want a supported product
   1721 but who do not need (or cannot afford) a comprehensive, feature-laden program
   1722 with a graphical user interface.  Slappy's two most important features are its
   1723 batch processing ability and its full implementation of each and every standard
   1724 described in this document.  Versions of Slappy the Database will be provided
   1725 for various platforms including: Intel 386/486 Unix, Apple Macintosh, and
   1726 MS-DOS.
   1727 
   1728 Slappy may also be useful to those who have a full feature program who also
   1729 need to run time consuming chess database tasks on a spare computer.
   1730 
   1731 Suggestions and comments should be directed to its author, Steven J. Edwards
   1732 (sje@world.std.com).  More details will appear here as they become available.
   1733 
   1734 
   1735 13.14: CBASCII
   1736 
   1737 "CBASCII" is a general utility for converting chess data between ChessBase
   1738 format and ASCII representations.  It has PGN capability, and it is available
   1739 from the chess.uoknor.edu ftp site in the pub/chess/DOS directory as the file
   1740 "cba1_2.zip".  The contact person is the program's author, Andy Duplain
   1741 (duplain@btcs.bt.co.uk).
   1742 
   1743 
   1744 13.15: ZZZZZZ
   1745 
   1746 "ZZZZZZ" is a chessplaying program, complete with source, that also includes
   1747 some database functions.  A recent version is reported to have both PGN and EPD
   1748 capabilities.  It is available from the chess.uoknor.edu ftp site in the
   1749 pub/chess/Unix directory as the file "zzzzzz-3.2b1.tar.gz".  The contact person
   1750 is its author, Gijsbert Wiesenecker (wiesenecker@sara.nl).
   1751 
   1752 
   1753 13.16: icsconv
   1754 
   1755 The program "icsconv" can be used to convert Internet Chess Server games, both
   1756 old and new format, to PGN.  It is available from the chess.uoknor.edu site in
   1757 the pub/chess/Game-Databases/PGN/Tools directory as the file "icsconv.exe".
   1758 The contact person is the author, Kevin Nomura (chow@netcom.com).
   1759 
   1760 
   1761 13.17: CHESSOP (CHESSOPN/CHESSOPG)
   1762 
   1763 CHESSOP is an openings database and viewing tool with support for reading PGN
   1764 games.  It runs under MS-DOS and displays positions rather than games.  For
   1765 each position, both good and bad moves are listed with appropriate annotation.
   1766 Transpositions are handled as well.  The distributed database contains over
   1767 100,000 positions covering all the common openings.  Users can feed in their
   1768 own PGN data as well.  CHESSOP takes 3 Mbyte of hard disk, costs US$39 and can
   1769 be obtained from:
   1770 
   1771     CHESSX Software
   1772     12 Bluebell Close
   1773     Glenmore Park
   1774     AUSTRALIA 2745.
   1775 
   1776 The ideas behind CHESSOP can be seen in CHESSOPN (alias CHESSOPG), a free
   1777 version on the ICS server which has a reduced openings database (25,000
   1778 positions) and no PGN or transposition support but is otherwise the same as
   1779 CHESSOP.  (These are the files "chessopg.zip" in the directory pub/chess/DOS at
   1780 the chess.uoknor.edu ftp site.)
   1781 
   1782 
   1783 13.18: CAT2PGN
   1784 
   1785 The program "CAT2PGN" is a utility that translates data from the format used by
   1786 Chess Assistant into PGN.  It is available from the chess.uoknor.edu ftp site.
   1787 The contact person for CAT2PGN is its author, David Myers
   1788 (myers@frodo.biochem.duke.edu).
   1789 
   1790 
   1791 13.19: pgn2opg
   1792 
   1793 The utility "pgn2opg" can be used to convert PGN files into a text format used
   1794 by the "CHESSOPG" program mentioned above.  Although it does not perform any
   1795 semantic analysis on PGN input, it has been demonstrated to handle known
   1796 correct PGN input properly.  The file can be found in the pub/chess/PGN/Tools
   1797 directory at the chess.uoknor.edu ftp site.  For more information, the author
   1798 is David Barnes (djb@ukc.ac.uk).
   1799 
   1800 
   1801 14: PGN data archives
   1802 
   1803 The primary PGN data archive repository is located at the ftp site
   1804 chess.uoknor.edu as the directory "pub/chess/Game-Databases/PGN".  It is
   1805 organized according to the description given in section C.5 of this document.
   1806 The European site ftp.math.uni-hamburg.de is also reported to carry a regularly
   1807 updated copy of the repository.
   1808 
   1809 
   1810 15: International Olympic Committee country codes
   1811 
   1812 International Olympic Committee country codes are employed for Site nation
   1813 information because of their traditional use with the reporting of
   1814 international sporting events.  Due to changes in geography and linguistic
   1815 custom, some of the following may be incorrect or outdated.  Corrections and
   1816 extensions should be sent via e-mail to the PGN coordinator whose address
   1817 listed near the start of this document.
   1818 
   1819 AFG: Afghanistan
   1820 AIR: Aboard aircraft
   1821 ALB: Albania
   1822 ALG: Algeria
   1823 AND: Andorra
   1824 ANG: Angola
   1825 ANT: Antigua
   1826 ARG: Argentina
   1827 ARM: Armenia
   1828 ATA: Antarctica
   1829 AUS: Australia
   1830 AZB: Azerbaijan
   1831 BAN: Bangladesh
   1832 BAR: Bahrain
   1833 BHM: Bahamas
   1834 BEL: Belgium
   1835 BER: Bermuda
   1836 BIH: Bosnia and Herzegovina
   1837 BLA: Belarus
   1838 BLG: Bulgaria
   1839 BLZ: Belize
   1840 BOL: Bolivia
   1841 BRB: Barbados
   1842 BRS: Brazil
   1843 BRU: Brunei
   1844 BSW: Botswana
   1845 CAN: Canada
   1846 CHI: Chile
   1847 COL: Columbia
   1848 CRA: Costa Rica
   1849 CRO: Croatia
   1850 CSR: Czechoslovakia
   1851 CUB: Cuba
   1852 CYP: Cyprus
   1853 DEN: Denmark
   1854 DOM: Dominican Republic
   1855 ECU: Ecuador
   1856 EGY: Egypt
   1857 ENG: England
   1858 ESP: Spain
   1859 EST: Estonia
   1860 FAI: Faroe Islands
   1861 FIJ: Fiji
   1862 FIN: Finland
   1863 FRA: France
   1864 GAM: Gambia
   1865 GCI: Guernsey-Jersey
   1866 GEO: Georgia
   1867 GER: Germany
   1868 GHA: Ghana
   1869 GRC: Greece
   1870 GUA: Guatemala
   1871 GUY: Guyana
   1872 HAI: Haiti
   1873 HKG: Hong Kong
   1874 HON: Honduras
   1875 HUN: Hungary
   1876 IND: India
   1877 IRL: Ireland
   1878 IRN: Iran
   1879 IRQ: Iraq
   1880 ISD: Iceland
   1881 ISR: Israel
   1882 ITA: Italy
   1883 IVO: Ivory Coast
   1884 JAM: Jamaica
   1885 JAP: Japan
   1886 JRD: Jordan
   1887 JUG: Yugoslavia
   1888 KAZ: Kazakhstan
   1889 KEN: Kenya
   1890 KIR: Kyrgyzstan
   1891 KUW: Kuwait
   1892 LAT: Latvia
   1893 LEB: Lebanon
   1894 LIB: Libya
   1895 LIC: Liechtenstein
   1896 LTU: Lithuania
   1897 LUX: Luxembourg
   1898 MAL: Malaysia
   1899 MAU: Mauritania
   1900 MEX: Mexico
   1901 MLI: Mali
   1902 MLT: Malta
   1903 MNC: Monaco
   1904 MOL: Moldova
   1905 MON: Mongolia
   1906 MOZ: Mozambique
   1907 MRC: Morocco
   1908 MRT: Mauritius
   1909 MYN: Myanmar
   1910 NCG: Nicaragua
   1911 NET: The Internet
   1912 NIG: Nigeria
   1913 NLA: Netherlands Antilles
   1914 NLD: Netherlands
   1915 NOR: Norway
   1916 NZD: New Zealand
   1917 OST: Austria
   1918 PAK: Pakistan
   1919 PAL: Palestine
   1920 PAN: Panama
   1921 PAR: Paraguay
   1922 PER: Peru
   1923 PHI: Philippines
   1924 PNG: Papua New Guinea
   1925 POL: Poland
   1926 POR: Portugal
   1927 PRC: People's Republic of China
   1928 PRO: Puerto Rico
   1929 QTR: Qatar
   1930 RIN: Indonesia
   1931 ROM: Romania
   1932 RUS: Russia
   1933 SAF: South Africa
   1934 SAL: El Salvador
   1935 SCO: Scotland
   1936 SEA: At Sea
   1937 SEN: Senegal
   1938 SEY: Seychelles
   1939 SIP: Singapore
   1940 SLV: Slovenia
   1941 SMA: San Marino
   1942 SPC: Aboard spacecraft
   1943 SRI: Sri Lanka
   1944 SUD: Sudan
   1945 SUR: Surinam
   1946 SVE: Sweden
   1947 SWZ: Switzerland
   1948 SYR: Syria
   1949 TAI: Thailand
   1950 TMT: Turkmenistan
   1951 TRK: Turkey
   1952 TTO: Trinidad and Tobago
   1953 TUN: Tunisia
   1954 UAE: United Arab Emirates
   1955 UGA: Uganda
   1956 UKR: Ukraine
   1957 UNK: Unknown
   1958 URU: Uruguay
   1959 USA: United States of America
   1960 UZB: Uzbekistan
   1961 VEN: Venezuela
   1962 VGB: British Virgin Islands
   1963 VIE: Vietnam
   1964 VUS: U.S. Virgin Islands
   1965 WLS: Wales
   1966 YEM: Yemen
   1967 YUG: Yugoslavia
   1968 ZAM: Zambia
   1969 ZIM: Zimbabwe
   1970 ZRE: Zaire
   1971 
   1972 
   1973 16: Additional chess data standards
   1974 
   1975 While PGN is used for game storage, there are other data representation
   1976 standards for other chess related purposes.  Two important standards are FEN
   1977 and EPD, both described in this section.
   1978 
   1979 
   1980 16.1: FEN
   1981 
   1982 FEN is "Forsyth-Edwards Notation"; it is a standard for describing chess
   1983 positions using the ASCII character set.
   1984 
   1985 A single FEN record uses one text line of variable length composed of six data
   1986 fields.  The first four fields of the FEN specification are the same as the
   1987 first four fields of the EPD specification.
   1988 
   1989 A text file composed exclusively of FEN data records should have a file name
   1990 with the suffix ".fen".
   1991 
   1992 
   1993 16.1.1: History
   1994 
   1995 FEN is based on a 19th century standard for position recording designed by the
   1996 Scotsman David Forsyth, a newspaper journalist.  The original Forsyth standard
   1997 has been slightly extended for use with chess software by Steven Edwards with
   1998 assistance from commentators on the Internet.  This new standard, FEN, was
   1999 first implemented in Edwards' SAN Kit.
   2000 
   2001 
   2002 16.1.2: Uses for a position notation
   2003 
   2004 Having a standard position notation is particularly important for chess
   2005 programmers as it allows them to share position databases.  For example, there
   2006 exist standard position notation databases with many of the classical benchmark
   2007 tests for chessplaying programs, and by using a common position notation format
   2008 many hours of tedious data entry can be saved.  Additionally, a position
   2009 notation can be useful for page layout programs and for confirming position
   2010 status for e-mail competition.
   2011 
   2012 Many interesting chess problem sets represented using FEN can be found at the
   2013 chess.uoknor.edu ftp site in the directory pub/chess/SAN_testsuites.
   2014 
   2015 
   2016 16.1.3: Data fields
   2017 
   2018 FEN specifies the piece placement, the active color, the castling availability,
   2019 the en passant target square, the halfmove clock, and the fullmove number.
   2020 These can all fit on a single text line in an easily read format.  The length
   2021 of a FEN position description varies somewhat according to the position. In
   2022 some cases, the description could be eighty or more characters in length and so
   2023 may not fit conveniently on some displays.  However, these positions aren't too
   2024 common.
   2025 
   2026 A FEN description has six fields.  Each field is composed only of non-blank
   2027 printing ASCII characters.  Adjacent fields are separated by a single ASCII
   2028 space character.
   2029 
   2030 
   2031 16.1.3.1: Piece placement data
   2032 
   2033 The first field represents the placement of the pieces on the board.  The board
   2034 contents are specified starting with the eighth rank and ending with the first
   2035 rank.  For each rank, the squares are specified from file a to file h.  White
   2036 pieces are identified by uppercase SAN piece letters ("PNBRQK") and black
   2037 pieces are identified by lowercase SAN piece letters ("pnbrqk").  Empty squares
   2038 are represented by the digits one through eight; the digit used represents the
   2039 count of contiguous empty squares along a rank.  A solidus character "/" is
   2040 used to separate data of adjacent ranks.
   2041 
   2042 
   2043 16.1.3.2: Active color
   2044 
   2045 The second field represents the active color.  A lower case "w" is used if
   2046 White is to move; a lower case "b" is used if Black is the active player.
   2047 
   2048 
   2049 16.1.3.3: Castling availability
   2050 
   2051 The third field represents castling availability.  This indicates potential
   2052 future castling that may of may not be possible at the moment due to blocking
   2053 pieces or enemy attacks.  If there is no castling availability for either side,
   2054 the single character symbol "-" is used.  Otherwise, a combination of from one
   2055 to four characters are present.  If White has kingside castling availability,
   2056 the uppercase letter "K" appears.  If White has queenside castling
   2057 availability, the uppercase letter "Q" appears.  If Black has kingside castling
   2058 availability, the lowercase letter "k" appears.  If Black has queenside
   2059 castling availability, then the lowercase letter "q" appears.  Those letters
   2060 which appear will be ordered first uppercase before lowercase and second
   2061 kingside before queenside.  There is no white space between the letters.
   2062 
   2063 
   2064 16.1.3.4: En passant target square
   2065 
   2066 The fourth field is the en passant target square.  If there is no en passant
   2067 target square then the single character symbol "-" appears.  If there is an en
   2068 passant target square then is represented by a lowercase file character
   2069 immediately followed by a rank digit.  Obviously, the rank digit will be "3"
   2070 following a white pawn double advance (Black is the active color) or else be
   2071 the digit "6" after a black pawn double advance (White being the active color).
   2072 
   2073 An en passant target square is given if and only if the last move was a pawn
   2074 advance of two squares.  Therefore, an en passant target square field may have
   2075 a square name even if there is no pawn of the opposing side that may
   2076 immediately execute the en passant capture.
   2077 
   2078 
   2079 16.1.3.5: Halfmove clock
   2080 
   2081 The fifth field is a nonnegative integer representing the halfmove clock.  This
   2082 number is the count of halfmoves (or ply) since the last pawn advance or
   2083 capturing move.  This value is used for the fifty move draw rule.
   2084 
   2085 
   2086 16.1.3.6: Fullmove number
   2087 
   2088 The sixth and last field is a positive integer that gives the fullmove number.
   2089 This will have the value "1" for the first move of a game for both White and
   2090 Black.  It is incremented by one immediately after each move by Black.
   2091 
   2092 
   2093 16.1.4: Examples
   2094 
   2095 Here's the FEN for the starting position:
   2096 
   2097 rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
   2098 
   2099 And after the move 1. e4:
   2100 
   2101 rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq e3 0 1
   2102 
   2103 And then after 1. ... c5:
   2104 
   2105 rnbqkbnr/pp1ppppp/8/2p5/4P3/8/PPPP1PPP/RNBQKBNR w KQkq c6 0 2
   2106 
   2107 And then after 2. Nf3:
   2108 
   2109 rnbqkbnr/pp1ppppp/8/2p5/4P3/5N2/PPPP1PPP/RNBQKB1R b KQkq - 1 2
   2110 
   2111 For two kings on their home squares and a white pawn on e2 (White to move) with
   2112 thirty eight full moves played with five halfmoves since the last pawn move or
   2113 capture:
   2114 
   2115 4k3/8/8/8/8/8/4P3/4K3 w - - 5 39
   2116 
   2117 
   2118 16.2: EPD
   2119 
   2120 EPD is "Extended Position Description"; it is a standard for describing chess
   2121 positions along with an extended set of structured attribute values using the
   2122 ASCII character set.  It is intended for data and command interchange among
   2123 chessplaying programs.  It is also intended for the representation of portable
   2124 opening library repositories.
   2125 
   2126 A single EPD uses one text line of variable length composed of four data field
   2127 followed by zero or more operations.  The four fields of the EPD specification
   2128 are the same as the first four fields of the FEN specification.
   2129 
   2130 A text file composed exclusively of EPD data records should have a file name
   2131 with the suffix ".epd".
   2132 
   2133 
   2134 16.2.1: History
   2135 
   2136 EPD is based in part on the earlier FEN standard; it has added extensions for
   2137 use with opening library preparation and also for general data and command
   2138 interchange among advanced chess programs.  EPD was developed by John Stanback
   2139 and Steven Edwards; its first implementation is in Stanback's master strength
   2140 chessplaying program Zarkov.
   2141 
   2142 
   2143 16.2.2: Uses for an extended position notation
   2144 
   2145 Like FEN, EPD can also be used for general position description.  However,
   2146 unlike FEN, EPD is designed to be expandable by the addition of new operations
   2147 that provide new functionality as needs arise.
   2148 
   2149 Many interesting chess problem sets represented using EPD can be found at the
   2150 chess.uoknor.edu ftp site in the directory pub/chess/SAN_testsuites.
   2151 
   2152 
   2153 16.2.3: Data fields
   2154 
   2155 EPD specifies the piece placement, the active color, the castling availability,
   2156 and the en passant target square of a position.  These can all fit on a single
   2157 text line in an easily read format.  The length of an EPD position description
   2158 varies somewhat according to the position and any associated operations. In
   2159 some cases, the description could be eighty or more characters in length and so
   2160 may not fit conveniently on some displays.  However, most EPD descriptions pass
   2161 among programs only and these are not usually seen by program users.
   2162 
   2163 (Note: due to the likelihood of future expansion of EPD, implementors are
   2164 encouraged to have their programs handle EPD text lines of up to 1024
   2165 characters long.)
   2166 
   2167 Each EPD data field is composed only of non-blank printing ASCII characters.
   2168 Adjacent data fields are separated by a single ASCII space character.
   2169 
   2170 
   2171 16.2.3.1: Piece placement data
   2172 
   2173 The first field represents the placement of the pieces on the board.  The board
   2174 contents are specified starting with the eighth rank and ending with the first
   2175 rank.  For each rank, the squares are specified from file a to file h.  White
   2176 pieces are identified by uppercase SAN piece letters ("PNBRQK") and black
   2177 pieces are identified by lowercase SAN piece letters ("pnbrqk").  Empty squares
   2178 are represented by the digits one through eight; the digit used represents the
   2179 count of contiguous empty squares along a rank.  A solidus character "/" is
   2180 used to separate data of adjacent ranks.
   2181 
   2182 
   2183 16.2.3.2: Active color
   2184 
   2185 The second field represents the active color.  A lower case "w" is used if
   2186 White is to move; a lower case "b" is used if Black is the active player.
   2187 
   2188 
   2189 16.2.3.3: Castling availability
   2190 
   2191 The third field represents castling availability.  This indicates potential
   2192 future castling that may or may not be possible at the moment due to blocking
   2193 pieces or enemy attacks.  If there is no castling availability for either side,
   2194 the single character symbol "-" is used.  Otherwise, a combination of from one
   2195 to four characters are present.  If White has kingside castling availability,
   2196 the uppercase letter "K" appears.  If White has queenside castling
   2197 availability, the uppercase letter "Q" appears.  If Black has kingside castling
   2198 availability, the lowercase letter "k" appears.  If Black has queenside
   2199 castling availability, then the lowercase letter "q" appears.  Those letters
   2200 which appear will be ordered first uppercase before lowercase and second
   2201 kingside before queenside.  There is no white space between the letters.
   2202 
   2203 
   2204 16.2.3.4: En passant target square
   2205 
   2206 The fourth field is the en passant target square.  If there is no en passant
   2207 target square then the single character symbol "-" appears.  If there is an en
   2208 passant target square then is represented by a lowercase file character
   2209 immediately followed by a rank digit.  Obviously, the rank digit will be "3"
   2210 following a white pawn double advance (Black is the active color) or else be
   2211 the digit "6" after a black pawn double advance (White being the active color).
   2212 
   2213 An en passant target square is given if and only if the last move was a pawn
   2214 advance of two squares.  Therefore, an en passant target square field may have
   2215 a square name even if there is no pawn of the opposing side that may
   2216 immediately execute the en passant capture.
   2217 
   2218 
   2219 16.2.4: Operations
   2220 
   2221 An EPD operation is composed of an opcode followed by zero or more operands and
   2222 is concluded by a semicolon.
   2223 
   2224 Multiple operations are separated by a single space character.  If there is at
   2225 least one operation present in an EPD line, it is separated from the last
   2226 (fourth) data field by a single space character.
   2227 
   2228 
   2229 16.2.4.1: General format
   2230 
   2231 An opcode is an identifier that starts with a letter character and may be
   2232 followed by up to fourteen more characters.  Each additional character may be a
   2233 letter or a digit or the underscore character.
   2234 
   2235 An operand is either a set of contiguous non-white space printing characters or
   2236 a string.  A string is a set of contiguous printing characters delimited by a
   2237 quote character at each end.  A string value must have less than 256 bytes of
   2238 data.
   2239 
   2240 If at least one operand is present in an operation, there is a single space
   2241 between the opcode and the first operand.  If more than one operand is present
   2242 in an operation, there is a single blank character between every two adjacent
   2243 operands.  If there are no operands, a semicolon character is appended to the
   2244 opcode to mark the end of the operation.  If any operands appear, the last
   2245 operand has an appended semicolon that marks the end of the operation.
   2246 
   2247 Any given opcode appears at most once per EPD record.  Multiple operations in a
   2248 single EPD record should appear in ASCII order of their opcode names
   2249 (mnemonics).  However, a program reading EPD records may allow for operations
   2250 not in ASCII order by opcode mnemonics; the semantics are the same in either
   2251 case.
   2252 
   2253 Some opcodes that allow for more than one operand may have special ordering
   2254 requirements for the operands.  For example, the "pv" (predicted variation)
   2255 opcode requires its operands (moves) to appear in the order in which they would
   2256 be played.  All other opcodes that allow for more than one operand should have
   2257 operands appearing in ASCII order.  An example of the latter set is the "bm"
   2258 (best move[s]) opcode; its operands are moves that are all immediately playable
   2259 from the current position.
   2260 
   2261 Some opcodes require one or more operands that are chess moves.  These moves
   2262 should be represented using SAN.  If a different representation is used, there
   2263 is no guarantee that the EPD will be read correctly during subsequent
   2264 processing.
   2265 
   2266 Some opcodes require one or more operands that are integers.  Some opcodes may
   2267 require that an integer operand must be within a given range; the details are
   2268 described in the opcode list given below.  A negative integer is formed with a
   2269 hyphen (minus sign) preceding the integer digit sequence.  An optional plus
   2270 sign may be used for indicating a non-negative value, but such use is not
   2271 required and is indeed discouraged.
   2272 
   2273 Some opcodes require one or more operands that are floating point numbers.
   2274 Some opcodes may require that a floating point operand must be within a given
   2275 range; the details are described in the opcode list given below.  A floating
   2276 point operand is constructed from an optional sign character ("+" or "-"), a
   2277 digit sequence (with at least one digit), a radix point (always "."), and a
   2278 final digit sequence (with at least one digit).
   2279 
   2280 
   2281 16.2.4.2: Opcode mnemonics
   2282 
   2283 An opcode mnemonic used for archival storage and for interprogram communication
   2284 starts with a lower case letter and is composed of only lower case letters,
   2285 digits, and the underscore character (i.e., no upper case letters).  These
   2286 mnemonics will also all be at least two characters in length.
   2287 
   2288 Opcode mnemonics used only by a single program or an experimental suite of
   2289 programs should start with an upper case letter.  This is so they may be easily
   2290 distinguished should they be inadvertently be encountered by other programs.
   2291 When a such a "private" opcode be demonstrated to be widely useful, it should
   2292 be brought into the official list (appearing below) in a lower case form.
   2293 
   2294 If a given program does not recognize a particular opcode, that operation is
   2295 simply ignored; it is not signaled as an error.
   2296 
   2297 
   2298 16.2.5: Opcode list
   2299 
   2300 The opcodes are listed here in ASCII order of their mnemonics.  Suggestions for
   2301 new opcodes should be sent to the PGN standard coordinator listed near the
   2302 start of this document.
   2303 
   2304 
   2305 16.2.5.1: Opcode "acn": analysis count: nodes
   2306 
   2307 The opcode "acn" takes a single non-negative integer operand.  It is used to
   2308 represent the number of nodes examined in an analysis.  Note that the value may
   2309 be quite large for some extended searches and so use of (at least) a long (four
   2310 byte) representation is suggested.
   2311 
   2312 
   2313 16.2.5.2: Opcode "acs": analysis count: seconds
   2314 
   2315 The opcode "acs" takes a single non-negative integer operand.  It is used to
   2316 represent the number of seconds used for an analysis.  Note that the value may
   2317 be quite large for some extended searches and so use of (at least) a long (four
   2318 byte) representation is suggested.
   2319 
   2320 
   2321 16.2.5.3: Opcode "am": avoid move(s)
   2322 
   2323 The opcode "am" indicates a set of zero or more moves, all immediately playable
   2324 from the current position, that are to be avoided in the opinion of the EPD
   2325 writer.  Each operand is a SAN move; they appear in ASCII order.
   2326 
   2327 
   2328 16.2.5.4: Opcode "bm": best move(s)
   2329 
   2330 The opcode "bm" indicates a set of zero or more moves, all immediately playable
   2331 from the current position, that are judged to the best available by the EPD
   2332 writer.  Each operand is a SAN move; they appear in ASCII order.
   2333 
   2334 
   2335 16.2.5.5: Opcode "c0": comment (primary, also "c1" though "c9")
   2336 
   2337 The opcode "c0" (lower case letter "c", digit character zero) indicates a top
   2338 level comment that applies to the given position.  It is the first of ten
   2339 ranked comments, each of which has a mnemonic formed from the lower case letter
   2340 "c" followed by a single decimal digit.  Each of these opcodes takes either a
   2341 single string operand or no operand at all.
   2342 
   2343 This ten member comment family of opcodes is intended for use as descriptive
   2344 commentary for a complete game or game fragment.  The usual processing of these
   2345 opcodes are as follows:
   2346 
   2347 1) At the beginning of a game (or game fragment), a move sequence scanning
   2348 program initializes each element of its set of ten comment string registers to
   2349 be null.
   2350 
   2351 2) As the EPD record for each position in the game is processed, the comment
   2352 operations are interpreted from left to right.  (Actually, all operations in n
   2353 EPD record are interpreted from left to right.)  Because operations appear in
   2354 ASCII order according to their opcode mnemonics, opcode "c0" (if present) will
   2355 be handled prior to all other opcodes, then opcode "c1" (if present), and so
   2356 forth until opcode "c9" (if present).
   2357 
   2358 3) The processing of opcode "cN" (0 <= N <= 9) involves two steps.  First, all
   2359 comment string registers with an index equal to or greater than N are set to
   2360 null.  (This is the set "cN" though "c9".)  Second, and only if a string
   2361 operand is present, the value of the corresponding comment string register is
   2362 set equal to the string operand.
   2363 
   2364 
   2365 16.2.5.6: Opcode "ce": centipawn evaluation
   2366 
   2367 The opcode "ce" indicates the evaluation of the indicated position in centipawn
   2368 units.  It takes a single operand, an optionally signed integer that gives an
   2369 evaluation of the position from the viewpoint of the active player; i.e., the
   2370 player with the move.  Positive values indicate a position favorable to the
   2371 moving player while negative values indicate a position favorable to the
   2372 passive player; i.e., the player without the move.  A centipawn evaluation
   2373 value close to zero indicates a neutral positional evaluation.
   2374 
   2375 Values are restricted to integers that are equal to or greater than -32767 and
   2376 are less than or equal to 32766.
   2377 
   2378 A value greater than 32000 indicates the availability of a forced mate to the
   2379 active player.  The number of plies until mate is given by subtracting the
   2380 evaluation from the value 32767.  Thus, a winning mate in N fullmoves is a mate
   2381 in ((2 * N) - 1) halfmoves (or ply) and has a corresponding centipawn
   2382 evaluation of (32767 - ((2 * N) - 1)).  For example, a mate on the move (mate
   2383 in one) has a centipawn evaluation of 32766 while a mate in five has a
   2384 centipawn evaluation of 32758.
   2385 
   2386 A value less than -32000 indicates the availability of a forced mate to the
   2387 passive player.  The number of plies until mate is given by subtracting the
   2388 evaluation from the value -32767 and then negating the result.  Thus, a losing
   2389 mate in N fullmoves is a mate in (2 * N) halfmoves (or ply) and has a
   2390 corresponding centipawn evaluation of (-32767 + (2 * N)).  For example, a mate
   2391 after the move (losing mate in one) has a centipawn evaluation of -32765 while
   2392 a losing mate in five has a centipawn evaluation of -32757.
   2393 
   2394 A value of -32767 indicates an illegal position.  A stalemate position has a
   2395 centipawn evaluation of zero as does a position drawn due to insufficient
   2396 mating material.  Any other position known to be a certain forced draw also has
   2397 a centipawn evaluation of zero.
   2398 
   2399 
   2400 16.2.5.7: Opcode "dm": direct mate fullmove count
   2401 
   2402 The "dm" opcode is used to indicate the number of fullmoves until checkmate is
   2403 to be delivered by the active color for the indicated position.  It always
   2404 takes a single operand which is a positive integer giving the fullmove count.
   2405 For example, a position known to be a "mate in three" would have an operation
   2406 of "dm 3;" to indicate this.
   2407 
   2408 This opcode is intended for use with problem sets composed of positions
   2409 requiring direct mate answers as solutions.
   2410 
   2411 
   2412 16.2.5.8: Opcode "draw_accept": accept a draw offer
   2413 
   2414 The opcode "draw_accept" is used to indicate that a draw offer made after the
   2415 move that lead to the indicated position is accepted by the active player.
   2416 This opcode takes no operands.
   2417 
   2418 
   2419 16.2.5.9: Opcode "draw_claim": claim a draw
   2420 
   2421 The opcode "draw_claim" is used to indicate claim by the active player that a
   2422 draw exists.  The draw is claimed because of a third time repetition or because
   2423 of the fifty move rule or because of insufficient mating material.  A supplied
   2424 move (see the opcode "sm") is also required to appear as part of the same EPD
   2425 record.  The draw_claim opcode takes no operands.
   2426 
   2427 
   2428 16.2.5.10: Opcode "draw_offer": offer a draw
   2429 
   2430 The opcode "draw_offer" is used to indicate that a draw is offered by the
   2431 active player.  A supplied move (see the opcode "sm") is also required to
   2432 appear as part of the same EPD record; this move is considered played from the
   2433 indicated position.  The draw_offer opcode takes no operands.
   2434 
   2435 
   2436 16.2.5.11: Opcode "draw_reject": reject a draw offer
   2437 
   2438 The opcode "draw_reject" is used to indicate that a draw offer made after the
   2439 move that lead to the indicated position is rejected by the active player.
   2440 This opcode takes no operands.
   2441 
   2442 
   2443 16.2.5.12: Opcode "eco": _Encyclopedia of Chess Openings_ opening code
   2444 
   2445 The opcode "eco" is used to associate an opening designation from the
   2446 _Encyclopedia of Chess Openings_ taxonomy with the indicated position.  The
   2447 opcode takes either a single string operand (the ECO opening name) or no
   2448 operand at all.  If an operand is present, its value is associated with an
   2449 "ECO" string register of the scanning program.  If there is no operand, the ECO
   2450 string register of the scanning program is set to null.
   2451 
   2452 The usage is similar to that of the "ECO" tag pair of the PGN standard.
   2453 
   2454 
   2455 16.2.5.13: Opcode "fmvn": fullmove number
   2456 
   2457 The opcode "fmvn" represents the fullmove n umber associated with the position.
   2458 It always takes a single operand that is the positive integer value of the move
   2459 number.
   2460 
   2461 This opcode is used to explicitly represent the fullmove number in EPD that is
   2462 present by default in FEN as the sixth field.  Fullmove number information is
   2463 usually omitted from EPD because it does not affect move generation (commonly
   2464 needed for EPD-using tasks) but it does affect game notation (commonly needed
   2465 for FEN-using tasks).  Because of the desire for space optimization for large
   2466 EPD files, fullmove numbers were dropped from EPD's parent FEN.  The halfmove
   2467 clock information was similarly dropped.
   2468 
   2469 
   2470 16.2.5.14: Opcode "hmvc": halfmove clock
   2471 
   2472 The opcode "hmvc" represents the halfmove clock associated with the position.
   2473 The halfmove clock of a position is equal to the number of plies since the last
   2474 pawn move or capture.  This information is used to implement the fifty move
   2475 draw rule.  It always takes a single operand that is the non-negative integer
   2476 value of the halfmove clock.
   2477 
   2478 This opcode is used to explicitly represent the halfmove clock in EPD that is
   2479 present by default in FEN as the fifth field.  Halfmove clock information is
   2480 usually omitted from EPD because it does not affect move generation (commonly
   2481 needed for EPD-using tasks) but it does affect game termination issues
   2482 (commonly needed for FEN-using tasks).  Because of the desire for space
   2483 optimization for large EPD files, halfmove clock values were dropped from EPD's
   2484 parent FEN.  The fullmove number information was similarly dropped.
   2485 
   2486 
   2487 16.2.5.15: Opcode "id": position identification
   2488 
   2489 The opcode "id" is used to provide a simple identifying label for the indicated
   2490 position.  It takes a single string operand.
   2491 
   2492 This opcode is intended for use with test suites used for measuring
   2493 chessplaying program strength.  An example "id" operand for the seven hundred
   2494 fifty seventh position of the one thousand one problems in Reinfeld's _1001
   2495 Winning Chess Sacrifices and Combinations_ would be "WCSAC.0757" while the
   2496 fifteenth position in the twenty four problem Bratko-Kopec test suite would
   2497 have an "id" operand of "BK.15".
   2498 
   2499 
   2500 16.2.5.16: Opcode "nic": _New In Chess_ opening code
   2501 
   2502 The opcode "nic" is used to associate an opening designation from the _New In
   2503 Chess_ taxonomy with the indicated position.  The opcode takes either a single
   2504 string operand (the NIC opening name) or no operand at all.  If an operand is
   2505 present, its value is associated with an "NIC" string register of the scanning
   2506 program.  If there is no operand, the NIC string register of the scanning
   2507 program is set to null.
   2508 
   2509 The usage is similar to that of the "NIC" tag pair of the PGN standard.
   2510 
   2511 
   2512 16.2.5.17: Opcode "noop": no operation
   2513 
   2514 The "noop" opcode is used to indicate no operation.  It takes zero or more
   2515 operands, each of which may be of any type.  The operation involves no
   2516 processing.  It is intended for use by developers for program testing purposes.
   2517 
   2518 
   2519 16.2.5.18: Opcode "pm": predicted move
   2520 
   2521 The "pm" opcode is used to provide a single predicted move for the indicated
   2522 position.  It has exactly one operand, a move playable from the position.  This
   2523 move is judged by the EPD writer to represent the best move available to the
   2524 active player.
   2525 
   2526 If a non-empty "pv" (predicted variation) line of play is also present in the
   2527 same EPD record, the first move of the predicted variation is the same as the
   2528 predicted move.
   2529 
   2530 The "pm" opcode is intended for use as a general "display hint" mechanism.
   2531 
   2532 
   2533 16.2.5.19: Opcode "pv": predicted variation
   2534 
   2535 The "pv" opcode is used to provide a predicted variation for the indicated
   2536 position.  It has zero or more operands which represent a sequence of moves
   2537 playable from the position.  This sequence is judged by the EPD writer to
   2538 represent the best play available.
   2539 
   2540 If a "pm" (predicted move) operation is also present in the same EPD record,
   2541 the predicted move is the same as the first move of the predicted variation.
   2542 
   2543 
   2544 16.2.5.20: Opcode "rc": repetition count
   2545 
   2546 The "rc" opcode is used to indicate the number of occurrences of the indicated
   2547 position.  It takes a single, positive integer operand.  Any position,
   2548 including the initial starting position, is considered to have an "rc" value of
   2549 at least one.  A value of three indicates a candidate for a draw claim by the
   2550 position repetition rule.
   2551 
   2552 
   2553 16.2.5.21: Opcode "resign": game resignation
   2554 
   2555 The opcode "resign" is used to indicate that the active player has resigned the
   2556 game.  This opcode takes no operands.
   2557 
   2558 
   2559 16.2.5.22: Opcode "sm": supplied move
   2560 
   2561 The "sm" opcode is used to provide a single supplied move for the indicated
   2562 position.  It has exactly one operand, a move playable from the position.  This
   2563 move is the move to be played from the position.
   2564 
   2565 The "sm" opcode is intended for use to communicate the most recent played move
   2566 in an active game.  It is used to communicate moves between programs in
   2567 automatic play via a network.  This includes correspondence play using e-mail
   2568 and also programs acting as network front ends to human players.
   2569 
   2570 
   2571 16.2.5.23: Opcode "tcgs": telecommunication: game selector
   2572 
   2573 The "tcgs" opcode is one of the telecommunication family of opcodes used for
   2574 games conducted via e-mail and similar means.  This opcode takes a single
   2575 operand that is a positive integer.  It is used to select among various games
   2576 in progress between the same sender and receiver.
   2577 
   2578 
   2579 16.2.5.24: Opcode "tcri": telecommunication: receiver identification
   2580 
   2581 The "tcri" opcode is one of the telecommunication family of opcodes used for
   2582 games conducted via e-mail and similar means.  This opcode takes two order
   2583 dependent string operands.  The first operand is the e-mail address of the
   2584 receiver of the EPD record.  The second operand is the name of the player
   2585 (program or human) at the address who is the actual receiver of the EPD record.
   2586 
   2587 
   2588 16.2.5.25: Opcode "tcsi": telecommunication: sender identification
   2589 
   2590 The "tcsi" opcode is one of the telecommunication family of opcodes used for
   2591 games conducted via e-mail and similar means.  This opcode takes two order
   2592 dependent string operands.  The first operand is the e-mail address of the
   2593 sender of the EPD record.  The second operand is the name of the player
   2594 (program or human) at the address who is the actual sender of the EPD record.
   2595 
   2596 
   2597 16.2.5.26: Opcode "v0": variation name (primary, also "v1" though "v9")
   2598 
   2599 The opcode "v0" (lower case letter "v", digit character zero) indicates a top
   2600 level variation name that applies to the given position.  It is the first of
   2601 ten ranked variation names, each of which has a mnemonic formed from the lower
   2602 case letter "v" followed by a single decimal digit.  Each of these opcodes
   2603 takes either a single string operand or no operand at all.
   2604 
   2605 This ten member variation name family of opcodes is intended for use as
   2606 traditional variation names for a complete game or game fragment.  The usual
   2607 processing of these opcodes are as follows:
   2608 
   2609 1) At the beginning of a game (or game fragment), a move sequence scanning
   2610 program initializes each element of its set of ten variation name string
   2611 registers to be null.
   2612 
   2613 2) As the EPD record for each position in the game is processed, the variation
   2614 name operations are interpreted from left to right.  (Actually, all operations
   2615 in n EPD record are interpreted from left to right.)  Because operations appear
   2616 in ASCII order according to their opcode mnemonics, opcode "v0" (if present)
   2617 will be handled prior to all other opcodes, then opcode "v1" (if present), and
   2618 so forth until opcode "v9" (if present).
   2619 
   2620 3) The processing of opcode "vN" (0 <= N <= 9) involves two steps.  First, all
   2621 variation name string registers with an index equal to or greater than N are
   2622 set to null.  (This is the set "vN" though "v9".)  Second, and only if a string
   2623 operand is present, the value of the corresponding variation name string
   2624 register is set equal to the string operand.
   2625 
   2626 
   2627 17: Alternative chesspiece identifier letters
   2628 
   2629 English language piece names are used to define the letter set for identifying
   2630 chesspieces in PGN movetext.  However, authors of programs which are used only
   2631 for local presentation or scanning of chess move data may find it convenient to
   2632 use piece letter codes common in their locales.  This is not a problem as long
   2633 as PGN data that resides in archival storage or that is exchanged among
   2634 programs still uses the SAN (English) piece letter codes: "PNBRQK".
   2635 
   2636 For the above authors only, a list of alternative piece letter codes are
   2637 provided:
   2638 
   2639 Language     Piece letters (pawn knight bishop rook queen king)
   2640 ----------   --------------------------------------------------
   2641 Czech        P J S V D K
   2642 Danish       B S L T D K
   2643 Dutch        O P L T D K
   2644 English      P N B R Q K
   2645 Estonian     P R O V L K
   2646 Finnish      P R L T D K
   2647 French       P C F T D R
   2648 German       B S L T D K
   2649 Hungarian    G H F B V K
   2650 Icelandic    P R B H D K
   2651 Italian      P C A T D R
   2652 Norwegian    B S L T D K
   2653 Polish       P S G W H K
   2654 Portuguese   P C B T D R
   2655 Romanian     P C N T D R
   2656 Spanish      P C A T D R
   2657 Swedish      B S L T D K
   2658 
   2659 
   2660 18: Formal syntax
   2661 
   2662 <PGN-database> ::= <PGN-game> <PGN-database>
   2663                    <empty>
   2664 
   2665 <PGN-game> ::= <tag-section> <movetext-section>
   2666 
   2667 <tag-section> ::= <tag-pair> <tag-section>
   2668                   <empty>
   2669 
   2670 <tag-pair> ::= [ <tag-name> <tag-value> ]
   2671 
   2672 <tag-name> ::= <identifier>
   2673 
   2674 <tag-value> ::= <string>
   2675 
   2676 <movetext-section> ::= <element-sequence> <game-termination>
   2677 
   2678 <element-sequence> ::= <element> <element-sequence>
   2679                        <recursive-variation> <element-sequence>
   2680                        <empty>
   2681 
   2682 <element> ::= <move-number-indication>
   2683               <SAN-move>
   2684               <numeric-annotation-glyph>
   2685 
   2686 <recursive-variation> ::= ( <element-sequence> )
   2687 
   2688 <game-termination> ::= 1-0
   2689                        0-1
   2690                        1/2-1/2
   2691                        *
   2692 <empty> ::=
   2693 
   2694 
   2695 19: Canonical chess position hash coding
   2696 
   2697 *** This section is under development.
   2698 
   2699 
   2700 20: Binary representation (PGC)
   2701 
   2702 *** This section is under development.
   2703 
   2704 The binary coded version of PGN is PGC (PGN Game Coding).  PGC is a binary
   2705 representation standard of PGN data designed for the dual goals of storage
   2706 efficiency and program I/O.  A file containing PGC data should have a name with
   2707 a suffix of ".pgc".
   2708 
   2709 Unlike PGN text files that may have locale dependent representations for
   2710 newlines, PGC files have data that does not vary due to local processing
   2711 environment.  This means that PGC files may be transferred among systems using
   2712 general binary file methods.
   2713 
   2714 PGC files should be used only when the use of PGN is impractical due to time
   2715 and space resource constraints.  As the general level of processing
   2716 capabilities increases, the need for PGC over PGN will decrease.  Therefore,
   2717 implementors are encouraged not to use PGC as the default representation
   2718 because it is much more difficult (than PGN) to understand without proper
   2719 software.
   2720 
   2721 PGC data is composed of a sequence of PGC records.  Each record is composed of
   2722 a sequence of one or more bytes.  The first byte is the PGN record marker and
   2723 it specifies the interpretation of the remaining portion of the record.  This
   2724 remaining portion is composed of zero or more PGN record items.  Item types
   2725 include move sequences, move sets, and character strings.
   2726 
   2727 
   2728 20.1: Bytes, words, and doublewords
   2729 
   2730 At the lowest level, PGC binary data is organized as bytes, words (two
   2731 contiguous bytes), and doublewords (four contiguous bytes).  All eight bits of
   2732 a byte are used.  Longwords (eight contiguous bytes) are not used.  Integer
   2733 values are stored using two's complement representation.  Integers may be
   2734 signed or unsigned depending on context.  Multibyte integers are stored in
   2735 low-endian format with the least significant byte appearing first.
   2736 
   2737 A one byte integer item is called "int-1".  A two byte integer item is called
   2738 "int-2".  A four byte integer item is called "int-4".
   2739 
   2740 Characters are stored as bytes using the ISO 8859/1 Latin-1 (ECMA-94) code set.
   2741 There is no provision for other characters sets or representations.
   2742 
   2743 
   2744 20.2: Move ordinals
   2745 
   2746 A chess move is represented using a move ordinal.  This is a single unsigned
   2747 byte quantity with values from zero to 255.  A move ordinal is interpreted as
   2748 an index into the list of legal moves from the current position.  This list is
   2749 constructed by generating the legal moves from the current position, assigning
   2750 SAN ASCII strings to each move, and then sorting these strings in ascending
   2751 order.  Note that a seven bit ordinal, as used by some inferior representation
   2752 systems, is insufficient as there are some positions that have more than 128
   2753 moves available.
   2754 
   2755 Examples:  From the initial position, there are twenty moves.  Move ordinal 0
   2756 corresponds to the SAN move string "Na3"; move ordinal 1 corresponds to "Nc3",
   2757 move ordinal 4 corresponds to "a3", and move ordinal 19 corresponds to "h4".
   2758 
   2759 Moves can be organized into sequences and sets.  A move sequence is an ordered
   2760 list of moves that are played, one after another from first to last.  A move
   2761 set is a list of moves that are all playable from the current position.
   2762 
   2763 Move sequence data is represented using a length header followed by move
   2764 ordinal data.  The length header is an unsigned integer that may be a byte or a
   2765 word.  The integer gives the number, possibly zero, of following move ordinal
   2766 bytes.  Most move sequences can be represented using just a byte header; these
   2767 are called "mvseq-1" items.  Move sequence data using a word header are called
   2768 "mvseq-2" items.
   2769 
   2770 Move set data is represented using a length header followed by move ordinal
   2771 data.  The length header is an unsigned integer that is a byte.  The integer
   2772 gives the number, possibly zero, of following move ordinal bytes.  All move
   2773 sets are be represented using just a byte header; these are called "mvset-1"
   2774 items.  (Note the implied restriction that a move set can only have a maximum
   2775 of 255 of the possible 256 ordinals present at one time.)
   2776 
   2777 
   2778 20.3: String data
   2779 
   2780 PGC string data is represented using a length header followed by bytes of
   2781 character data.  The length header is an unsigned integer that may be a byte, a
   2782 word, or a doubleword.  The integer gives the number, possibly zero, of
   2783 following character bytes.  Most strings can be represented using just a byte
   2784 header; these are called "string-1" items.  String data using a word header are
   2785 called "string-2" items and string data using a doubleword header are called
   2786 "string-4" items.  No special ASCII NUL termination byte is required for PGC
   2787 storage of a string as the length is explicitly given in the item header.
   2788 
   2789 
   2790 20.4: Marker codes
   2791 
   2792 PGC marker codes are given in hexadecimal format.  PGC marker code zero (marker
   2793 0x00) is the "noop" marker and carries no meaning.  Each additional marker code
   2794 defined appears in its own subsection below.
   2795 
   2796 
   2797 20.4.1: Marker 0x01: reduced export format single game
   2798 
   2799 Marker 0x01 is used to indicate a single complete game in reduced export
   2800 format.  This refers to a game that has only the Seven Tag Roster data, played
   2801 moves, and no annotations or comments.  This record type is used as an
   2802 alternative to the general game data begin/end record pairs described below.
   2803 The general marker pair (0x05/0x06) is used to help represent game data that
   2804 can't be adequately represented in reduced export format.  There are eight
   2805 items that follow marker 0x01 to form the "reduced export format single game"
   2806 record.  In order, these are:
   2807 
   2808 1) string-1 (Event tag value)
   2809 
   2810 2) string-1 (Site tag value)
   2811 
   2812 3) string-1 (Date tag value)
   2813 
   2814 4) string-1 (Round tag value)
   2815 
   2816 5) string-1 (White tag value)
   2817 
   2818 6) string-1 (Black tag value)
   2819 
   2820 7) string-1 (Result tag value)
   2821 
   2822 8) mvseq-2 (played moves)
   2823 
   2824 
   2825 20.4.2: Marker 0x02: tag pair
   2826 
   2827 Marker 0x02 is used to indicate a single tag pair.  There are two items that
   2828 follow marker 0x02 to form the "tag pair" record; in order these are:
   2829 
   2830 1) string-1 (tag pair name)
   2831 
   2832 2) string-1 (tag pair value)
   2833 
   2834 
   2835 20.4.3: Marker 0x03: short move sequence
   2836 
   2837 Marker 0x03 is used to indicate a short move sequence.  There is one item that
   2838 follows marker 0x03 to form the "short move sequence" record; this is:
   2839 
   2840 1) mvseq-1 (played moves)
   2841 
   2842 
   2843 20.4.4: Marker 0x04: long move sequence
   2844 
   2845 Marker 0x04 is used to indicate a long move sequence.  There is one item that
   2846 follows marker 0x04 to form the "long move sequence" record; this is:
   2847 
   2848 1) mvseq-2 (played moves)
   2849 
   2850 
   2851 20.4.5: Marker 0x05: general game data begin
   2852 
   2853 Marker 0x05 is used to indicate the beginning of data for a game.  It has no
   2854 associated items; it is a complete record by itself.  Instead, it marks the
   2855 beginning of PGC records used to describe a game.  All records up to the
   2856 corresponding "general game data end" record are considered to be part of the
   2857 same game.  (PGC record type 0x01, "reduced export format single game", is not
   2858 permitted to appear within a general game begin/end record pair.  The general
   2859 game construct is to be used as an alternative to record type 0x01 in those
   2860 cases where the latter is too restrictive to contain the data for a game.)
   2861 
   2862 
   2863 20.4.6: Marker 0x06: general game data end
   2864 
   2865 Marker 0x06 is used to indicate the end of data for a game.  It has no
   2866 associated items; it is a complete record by itself.  Instead, it marks the end
   2867 of PGC records used to describe a game.  All records after the corresponding
   2868 (and earlier appearing) "general game data begin" record are considered to be
   2869 part of the same game.
   2870 
   2871 
   2872 20.4.7: Marker 0x07: simple-nag
   2873 
   2874 Marker 0x07 is used to indicate the presence of a simple NAG (Numeric
   2875 Annotation Glyph).  This is an annotation marker that has only a short type
   2876 identification and no operands.  There is one item that follows marker 0x07 to
   2877 form the "simple-nag" record; this is:
   2878 
   2879 1) int-1 (unsigned NAG value, from 0 to 255)
   2880 
   2881 
   2882 20.4.8: Marker 0x08: rav-begin
   2883 
   2884 Marker 0x08 is used to indicate the beginning of an RAV (Recursive Annotation
   2885 Variation).  It has no associated items; it is a complete record by itself.
   2886 Instead, it marks the beginning of PGC records used to describe a recursive
   2887 annotation.  It is considered an opening bracket for a later rav-end record;
   2888 the recursive annotation is completely described between the bracket pair.  The
   2889 rav-begin/data/rav-end structures can be nested.
   2890 
   2891 
   2892 20.4.9: Marker 0x09: rav-end
   2893 
   2894 Marker 0x09 is used to indicate the end of an RAV (Recursive Annotation
   2895 Variation).  It has no associated items; it is a complete record by itself.
   2896 Instead, it marks the end of PGC records used to describe a recursive
   2897 annotation.  It is considered a closing bracket for an earlier rav-begin
   2898 record; the recursive annotation is completely described between the bracket
   2899 pair.  The rav-begin/data/rav-end structures can be nested.
   2900 
   2901 
   2902 20.4.10: Marker 0x0a: escape-string
   2903 
   2904 Marker 0x0a is used to indicate the presence of an escape string.  This is a
   2905 string represented by the use of the percent sign ("%") escape mechanism in
   2906 PGN.  The data that is escaped is the sequence of characters immediately
   2907 follwoing the percent sign up to but not including the terminating newline.  As
   2908 is the case with the PGN percent sign escape, the use of a PGC escape-string
   2909 record is limited to use for non-archival data.  There is one item that follows
   2910 marker 0x0a to form the "escape-string" record; this is the string data being
   2911 escaped:
   2912 
   2913 1) string-2 (escaped string data)
   2914 
   2915 
   2916 21: E-mail correspondence usage
   2917 
   2918 *** This section is under development.
   2919 
   2920 
   2921 Standard: EOF