commit 0ffc26c270fc14ae309b41e1c3d4e5aee5b9adb1 (patch)
parent 101bc8012c5ae9891b30c02b179eaeb93c014b2e
Author: Alex Karle <alex@alexkarle.com>
Date: Sat, 14 May 2022 16:13:07 -0400
Add spec for PGN and some examples of famous games
Diffstat:
12 files changed, 3084 insertions(+), 0 deletions(-)
diff --git a/doc/PGN_standard_1994-03-12.txt b/doc/PGN_standard_1994-03-12.txt
@@ -0,0 +1,2921 @@
+Standard: Portable Game Notation Specification and Implementation Guide
+
+Revised: 1994.03.12
+
+Authors: Interested readers of the Internet newsgroup rec.games.chess
+
+Coordinator: Steven J. Edwards (send comments to sje@world.std.com)
+
+
+0: Preface
+
+From the Tower of Babel story:
+
+"If now, while they are one people, all speaking the same language, they have
+started to do this, nothing will later stop them from doing whatever they
+propose to do."
+
+Genesis XI, v.6, _New American Bible_
+
+
+1: Introduction
+
+PGN is "Portable Game Notation", a standard designed for the representation of
+chess game data using ASCII text files. PGN is structured for easy reading and
+writing by human users and for easy parsing and generation by computer
+programs. The intent of the definition and propagation of PGN is to facilitate
+the sharing of public domain chess game data among chessplayers (both organic
+and otherwise), publishers, and computer chess researchers throughout the
+world.
+
+PGN is not intended to be a general purpose standard that is suitable for every
+possible use; no such standard could fill all conceivable requirements.
+Instead, PGN is proposed as a universal portable representation for data
+interchange. The idea is to allow the construction of a family of chess
+applications that can quickly and easily process chess game data using PGN for
+import and export among themselves.
+
+
+2: Chess data representation
+
+Computer usage among chessplayers has become quite common in recent years and a
+variety of different programs, both commercial and public domain, are used to
+generate, access, and propagate chess game data. Some of these programs are
+rather impressive; most are now well behaved in that they correctly follow the
+Laws of Chess and handle users' data with reasonable care. Unfortunately, many
+programs have had serious problems with several aspects of the external
+representation of chess game data. Sometimes these problems become more
+visible when a user attempts to move significant quantities of data from one
+program to another; if there has been no real effort to ensure portability of
+data, then the chances for a successful transfer are small at best.
+
+
+2.1: Data interchange incompatibility
+
+The reasons for format incompatibility are easy to understand. In fact, most
+of them are correlated with the same problems that have already been seen with
+commercial software offerings for other domains such as word processing,
+spreadsheets, fonts, and graphics. Sometimes a manufacturer deliberately
+designs a data format using encryption or some other secret, proprietary
+technique to "lock in" a customer. Sometimes a designer may produce a format
+that can be deciphered without too much difficulty, but at the same time
+publicly discourage third party software by claiming trade secret protection.
+Another software producer may develop a non-proprietary system, but it may work
+well only within the scope of a single program or application because it is not
+easily expandable. Finally, some other software may work very well for many
+purposes, but it uses symbols and language not easily understood by people or
+computers available to those outside the country of its development.
+
+
+2.2: Specification goals
+
+A specification for a portable game notation must observe the lessons of
+history and be able to handle probable needs of the future. The design
+criteria for PGN were selected to meet these needs. These criteria include:
+
+1) The details of the system must be publicly available and free of unnecessary
+complexity. Ideally, if the documentation is not available for some reason,
+typical chess software developers and users should be able to understand most
+of the data without the need for third party assistance.
+
+2) The details of the system must be non-proprietary so that users and software
+developers are unrestricted by concerns about infringing on intellectual
+property rights. The idea is to let chess programmers compete in a free market
+where customers may choose software based on their real needs and not based on
+artificial requirements created by a secret data format.
+
+3) The system must work for a variety of programs. The format should be such
+that it can be used by chess database programs, chess publishing programs,
+chess server programs, and chessplaying programs without being unnecessarily
+specific to any particular application class.
+
+4) The system must be easily expandable and scalable. The expansion ability
+must include handling data items that may not exist currently but could be
+expected to emerge in the future. (Examples: new opening classifications and
+new country names.) The system should be scalable in that it must not have any
+arbitrary restrictions concerning the quantity of stored data. Also, planned
+modes of expansion should either preserve earlier databases or at least allow
+for their automatic conversion.
+
+5) The system must be international. Chess software users are found in many
+countries and the system should be free of difficulties caused by conventions
+local to a given region.
+
+6) Finally, the system should handle the same kinds and amounts of data that
+are already handled by existing chess software and by print media.
+
+
+2.3: A sample PGN game
+
+Although its description may seem rather lengthy, PGN is actually fairly
+simple. A sample PGN game follows; it has most of the important features
+described in later sections of this document.
+
+[Event "F/S Return Match"]
+[Site "Belgrade, Serbia JUG"]
+[Date "1992.11.04"]
+[Round "29"]
+[White "Fischer, Robert J."]
+[Black "Spassky, Boris V."]
+[Result "1/2-1/2"]
+
+1. e4 e5 2. Nf3 Nc6 3. Bb5 a6 4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8. c3
+O-O 9. h3 Nb8 10. d4 Nbd7 11. c4 c6 12. cxb5 axb5 13. Nc3 Bb7 14. Bg5 b4 15.
+Nb1 h6 16. Bh4 c5 17. dxe5 Nxe4 18. Bxe7 Qxe7 19. exd6 Qf6 20. Nbd2 Nxd6 21.
+Nc4 Nxc4 22. Bxc4 Nb6 23. Ne5 Rae8 24. Bxf7+ Rxf7 25. Nxf7 Rxe1+ 26. Qxe1 Kxf7
+27. Qe3 Qg5 28. Qxg5 hxg5 29. b3 Ke6 30. a3 Kd6 31. axb4 cxb4 32. Ra5 Nd5 33.
+f3 Bc8 34. Kf2 Bf5 35. Ra7 g6 36. Ra6+ Kc5 37. Ke1 Nf4 38. g3 Nxh3 39. Kd2 Kb5
+40. Rd6 Kc5 41. Ra6 Nf2 42. g4 Bd3 43. Re6 1/2-1/2
+
+
+3: Formats: import and export
+
+There are two formats in the PGN specification. These are the "import" format
+and the "export" format. These are the two different ways of formatting the
+same PGN data according to its source. The details of the two formats are
+described throughout the following sections of this document.
+
+Other than formats, there is the additional topic of PGN presentation. While
+both PGN import and export formats are designed to be readable by humans, there
+is no recommendation that either of these be an ultimate mode of chess data
+presentation. Rather, software developers are urged to consider all of the
+various techniques at their disposal to enhance the display of chess data at
+the presentation level (i.e., highest level) of their programs. This means
+that the use of different fonts, character sizes, color, and other tools of
+computer aided interaction and publishing should be explored to provide a high
+quality presentation appropriate to the function of the particular program.
+
+
+3.1: Import format allows for manually prepared data
+
+The import format is rather flexible and is used to describe data that may have
+been prepared by hand, much like a source file for a high level programming
+language. A program that can read PGN data should be able to handle the
+somewhat lax import format.
+
+
+3.2: Export format used for program generated output
+
+The export format is rather strict and is used to describe data that is usually
+prepared under program control, something like a pretty printed source program
+reformatted by a compiler.
+
+
+3.2.1: Byte equivalence
+
+For a given PGN data file, export format representations generated by different
+PGN programs on the same computing system should be exactly equivalent, byte
+for byte.
+
+
+3.2.2: Archival storage and the newline character
+
+Export format should also be used for archival storage. Here, "archival"
+storage is defined as storage that may be accessed by a variety of computing
+systems. The only extra requirement for archival storage is that the newline
+character have a specific representation that is independent of its value for a
+particular computing system's text file usage. The archival representation of
+a newline is the ASCII control character LF (line feed, decimal value 10,
+hexadecimal value 0x0a).
+
+Sadly, there are some accidents of history that survive to this day that have
+baroque representations for a newline: multicharacter sequences, end-of-line
+record markers, start-of-line byte counts, fixed length records, and so forth.
+It is well beyond the scope of the PGN project to reconcile all of these to the
+unified world of ANSI C and the those enjoying the bliss of a single '\n'
+convention. Some systems may just not be able to handle an archival PGN text
+file with native text editors. In these cases, an indulgence of sorts is
+granted to use the local newline convention in non-archival PGN files for those
+text editors.
+
+
+3.2.3: Speed of processing
+
+Several parts of the export format deal with exact descriptions of line and
+field justification that are absent from the import format details. The main
+reason for these restrictions on the export format are to allow the
+construction of simple data translation programs that can easily scan PGN data
+without having to have a full chess engine or other complex parsing routines.
+The idea is to encourage chess software authors to always allow for at least a
+limited PGN reading capability. Even when a full chess engine parsing
+capability is available, it is likely to be at least two orders of magnitude
+slower than a simple text scanner.
+
+
+3.2.4: Reduced export format
+
+A PGN game represented using export format is said to be in "reduced export
+format" if all of the following hold: 1) it has no commentary, 2) it has only
+the standard seven tag roster identification information ("STR", see below), 3)
+it has no recursive annotation variations ("RAV", see below), and 4) it has no
+numeric annotation glyphs ("NAG", see below). Reduced export format is used
+for bulk storage of unannotated games. It represents a minimum level of
+standard conformance for a PGN exporting application.
+
+
+4: Lexicographical issues
+
+PGN data is composed of characters; non-overlapping contiguous sequences of
+characters form lexical tokens.
+
+
+4.1: Character codes
+
+PGN data is represented using a subset of the eight bit ISO 8859/1 (Latin 1)
+character set. ("ISO" is an acronym for the International Standards
+Organization.) This set is also known as ECMA-94 and is similar to other ISO
+Latin character sets. ISO 8859/1 includes the standard seven bit ASCII
+character set for the 32 control character code values from zero to 31. The 95
+printing character code values from 32 to 126 are also equivalent to seven bit
+ASCII usage. (Code value 127, the ASCII DEL control character, is a graphic
+character in ISO 8859/1; it is not used for PGN data representation.)
+
+The 32 ISO 8859/1 code values from 128 to 159 are non-printing control
+characters. They are not used for PGN data representation. The 32 code values
+from 160 to 191 are mostly non-alphabetic printing characters and their use for
+PGN data is discouraged as their graphic representation varies considerably
+among other ISO Latin sets. Finally, the 64 code values from 192 to 255 are
+mostly alphabetic printing characters with various diacritical marks; their use
+is encouraged for those languages that require such characters. The graphic
+representations of this last set of 64 characters is fairly constant for the
+ISO Latin family.
+
+Printing character codes outside of the seven bit ASCII range may only appear
+in string data and in commentary. They are not permitted for use in symbol
+construction.
+
+Because some PGN users' environments may not support presentation of non-ASCII
+characters, PGN game authors should refrain from using such characters in
+critical commentary or string values in game data that may be referenced in
+such environments. PGN software authors should have their programs handle such
+environments by displaying a question mark ("?") for non-ASCII character codes.
+This is an important point because there are many computing systems that can
+display eight bit character data, but the display graphics may differ among
+machines and operating systems from different manufacturers.
+
+Only four of the ASCII control characters are permitted in PGN import format;
+these are the horizontal and vertical tabs along with the linefeed and carriage
+return codes.
+
+The external representation of the newline character may differ among
+platforms; this is an acceptable variation as long as the details of the
+implementation are hidden from software implementors and users. When a choice
+is practical, the Unix "newline is linefeed" convention is preferred.
+
+
+4.2: Tab characters
+
+Tab characters, both horizontal and vertical, are not permitted in the export
+format. This is because the treatment of tab characters is highly dependent
+upon the particular software in use on the host computing system. Also, tab
+characters may not appear inside of string data.
+
+
+4.3: Line lengths
+
+PGN data are organized as simple text lines without any special bytes or
+markers for secondary record structure imposed by specific operating systems.
+Import format PGN text lines are limited to having a maximum of 255 characters
+per line including the newline character. Lines with 80 or more printing
+characters are strongly discouraged because of the difficulties experienced by
+common text editors with long lines.
+
+In some cases, very long tag values will require 80 or more columns, but these
+are relatively rare. An example of this is the "FEN" tag pair; it may have a
+long tag value, but this particular tag pair is only used to represent a game
+that doesn't start from the usual initial position.
+
+
+5: Commentary
+
+Comment text may appear in PGN data. There are two kinds of comments. The
+first kind is the "rest of line" comment; this comment type starts with a
+semicolon character and continues to the end of the line. The second kind
+starts with a left brace character and continues to the next right brace
+character. Comments cannot appear inside any token.
+
+Brace comments do not nest; a left brace character appearing in a brace comment
+loses its special meaning and is ignored. A semicolon appearing inside of a
+brace comment loses its special meaning and is ignored. Braces appearing
+inside of a semicolon comments lose their special meaning and are ignored.
+
+*** Export format representation of comments needs definition work.
+
+
+6: Escape mechanism
+
+There is a special escape mechanism for PGN data. This mechanism is triggered
+by a percent sign character ("%") appearing in the first column of a line; the
+data on the rest of the line is ignored by publicly available PGN scanning
+software. This escape convention is intended for the private use of software
+developers and researchers to embed non-PGN commands and data in PGN streams.
+
+A percent sign appearing in any other place other than the first position in a
+line does not trigger the escape mechanism.
+
+
+7: Tokens
+
+PGN character data is organized as tokens. A token is a contiguous sequence of
+characters that represents a basic semantic unit. Tokens may be separated from
+adjacent tokens by white space characters. (White space characters include
+space, newline, and tab characters.) Some tokens are self delimiting and do
+not require white space characters.
+
+A string token is a sequence of zero or more printing characters delimited by a
+pair of quote characters (ASCII decimal value 34, hexadecimal value 0x22). An
+empty string is represented by two adjacent quotes. (Note: an apostrophe is
+not a quote.) A quote inside a string is represented by the backslash
+immediately followed by a quote. A backslash inside a string is represented by
+two adjacent backslashes. Strings are commonly used as tag pair values (see
+below). Non-printing characters like newline and tab are not permitted inside
+of strings. A string token is terminated by its closing quote. Currently, a
+string is limited to a maximum of 255 characters of data.
+
+An integer token is a sequence of one or more decimal digit characters. It is
+a special case of the more general "symbol" token class described below.
+Integer tokens are used to help represent move number indications (see below).
+An integer token is terminated just prior to the first non-symbol character
+following the integer digit sequence.
+
+A period character (".") is a token by itself. It is used for move number
+indications (see below). It is self terminating.
+
+An asterisk character ("*") is a token by itself. It is used as one of the
+possible game termination markers (see below); it indicates an incomplete game
+or a game with an unknown or otherwise unavailable result. It is self
+terminating.
+
+The left and right bracket characters ("[" and "]") are tokens. They are used
+to delimit tag pairs (see below). Both are self terminating.
+
+The left and right parenthesis characters ("(" and ")") are tokens. They are
+used to delimit Recursive Annotation Variations (see below). Both are self
+terminating.
+
+The left and right angle bracket characters ("<" and ">") are tokens. They are
+reserved for future expansion. Both are self terminating.
+
+A Numeric Annotation Glyph ("NAG", see below) is a token; it is composed of a
+dollar sign character ("$") immediately followed by one or more digit
+characters. It is terminated just prior to the first non-digit character
+following the digit sequence.
+
+A symbol token starts with a letter or digit character and is immediately
+followed by a sequence of zero or more symbol continuation characters. These
+continuation characters are letter characters ("A-Za-z"), digit characters
+("0-9"), the underscore ("_"), the plus sign ("+"), the octothorpe sign ("#"),
+the equal sign ("="), the colon (":"), and the hyphen ("-"). Symbols are used
+for a variety of purposes. All characters in a symbol are significant. A
+symbol token is terminated just prior to the first non-symbol character
+following the symbol character sequence. Currently, a symbol is limited to a
+maximum of 255 characters in length.
+
+
+8: Parsing games
+
+A PGN database file is a sequential collection of zero or more PGN games. An
+empty file is a valid, although somewhat uninformative, PGN database.
+
+A PGN game is composed of two sections. The first is the tag pair section and
+the second is the movetext section. The tag pair section provides information
+that identifies the game by defining the values associated with a set of
+standard parameters. The movetext section gives the usually enumerated and
+possibly annotated moves of the game along with the concluding game termination
+marker. The chess moves themselves are represented using SAN (Standard
+Algebraic Notation), also described later in this document.
+
+
+8.1: Tag pair section
+
+The tag pair section is composed of a series of zero or more tag pairs.
+
+A tag pair is composed of four consecutive tokens: a left bracket token, a
+symbol token, a string token, and a right bracket token. The symbol token is
+the tag name and the string token is the tag value associated with the tag
+name. (There is a standard set of tag names and semantics described below.)
+The same tag name should not appear more than once in a tag pair section.
+
+A further restriction on tag names is that they are composed exclusively of
+letters, digits, and the underscore character. This is done to facilitate
+mapping of tag names into key and attribute names for use with general purpose
+database programs.
+
+For PGN import format, there may be zero or more white space characters between
+any adjacent pair of tokens in a tag pair.
+
+For PGN export format, there are no white space characters between the left
+bracket and the tag name, there are no white space characters between the tag
+value and the right bracket, and there is a single space character between the
+tag name and the tag value.
+
+Tag names, like all symbols, are case sensitive. All tag names used for
+archival storage begin with an upper case letter.
+
+PGN import format may have multiple tag pairs on the same line and may even
+have a tag pair spanning more than a single line. Export format requires each
+tag pair to appear left justified on a line by itself; a single empty line
+follows the last tag pair.
+
+Some tag values may be composed of a sequence of items. For example, a
+consultation game may have more than one player for a given side. When this
+occurs, the single character ":" (colon) appears between adjacent items.
+Because of this use as an internal separator in strings, the colon should not
+otherwise appear in a string.
+
+The tag pair format is designed for expansion; initially only strings are
+allowed as tag pair values. Tag value formats associated with the STR (Seven
+Tag Roster, see below) will not change; they will always be string values.
+However, there are long term plans to allow general list structures as tag
+values for non-STR tag pairs. Use of these expanded tag values will likely be
+restricted to special research programs. In all events, the top level
+structure of a tag pair remains the same: left bracket, tag name, tag value,
+and right bracket.
+
+
+8.1.1: Seven Tag Roster
+
+There is a set of tags defined for mandatory use for archival storage of PGN
+data. This is the STR (Seven Tag Roster). The interpretation of these tags is
+fixed as is the order in which they appear. Although the definition and use of
+additional tag names and semantics is permitted and encouraged when needed, the
+STR is the common ground that all programs should follow for public data
+interchange.
+
+For import format, the order of tag pairs is not important. For export format,
+the STR tag pairs appear before any other tag pairs. (The STR tag pairs must
+also appear in order; this order is described below). Also for export format,
+any additional tag pairs appear in ASCII order by tag name.
+
+The seven tag names of the STR are (in order):
+
+1) Event (the name of the tournament or match event)
+
+2) Site (the location of the event)
+
+3) Date (the starting date of the game)
+
+4) Round (the playing round ordinal of the game)
+
+5) White (the player of the white pieces)
+
+6) Black (the player of the black pieces)
+
+7) Result (the result of the game)
+
+A set of supplemental tag names is given later in this document.
+
+For PGN export format, a single blank line appears after the last of the tag
+pairs to conclude the tag pair section. This helps simple scanning programs to
+quickly determine the end of the tag pair section and the beginning of the
+movetext section.
+
+
+8.1.1.1: The Event tag
+
+The Event tag value should be reasonably descriptive. Abbreviations are to be
+avoided unless absolutely necessary. A consistent event naming should be used
+to help facilitate database scanning. If the name of the event is unknown, a
+single question mark should appear as the tag value.
+
+Examples:
+
+[Event "FIDE World Championship"]
+
+[Event "Moscow City Championship"]
+
+[Event "ACM North American Computer Championship"]
+
+[Event "Casual Game"]
+
+
+8.1.1.2: The Site tag
+
+The Site tag value should include city and region names along with a standard
+name for the country. The use of the IOC (International Olympic Committee)
+three letter names is suggested for those countries where such codes are
+available. If the site of the event is unknown, a single question mark should
+appear as the tag value. A comma may be used to separate a city from a region.
+No comma is needed to separate a city or region from the IOC country code. A
+later section of this document gives a list of three letter nation codes along
+with a few additions for "locations" not covered by the IOC.
+
+Examples:
+
+[Site "New York City, NY USA"]
+
+[Site "St. Petersburg RUS"]
+
+[Site "Riga LAT"]
+
+
+8.1.1.3: The Date tag
+
+The Date tag value gives the starting date for the game. (Note: this is not
+necessarily the same as the starting date for the event.) The date is given
+with respect to the local time of the site given in the Event tag. The Date
+tag value field always uses a standard ten character format: "YYYY.MM.DD". The
+first four characters are digits that give the year, the next character is a
+period, the next two characters are digits that give the month, the next
+character is a period, and the final two characters are digits that give the
+day of the month. If the any of the digit fields are not known, then question
+marks are used in place of the digits.
+
+Examples:
+
+[Date "1992.08.31"]
+
+[Date "1993.??.??"]
+
+[Date "2001.01.01"]
+
+
+8.1.1.4: The Round tag
+
+The Round tag value gives the playing round for the game. In a match
+competition, this value is the number of the game played. If the use of a
+round number is inappropriate, then the field should be a single hyphen
+character. If the round is unknown, a single question mark should appear as
+the tag value.
+
+Some organizers employ unusual round designations and have multipart playing
+rounds and sometimes even have conditional rounds. In these cases, a multipart
+round identifier can be made from a sequence of integer round numbers separated
+by periods. The leftmost integer represents the most significant round and
+succeeding integers represent round numbers in descending hierarchical order.
+
+Examples:
+
+[Round "1"]
+
+[Round "3.1"]
+
+[Round "4.1.2"]
+
+
+8.1.1.5: The White tag
+
+The White tag value is the name of the player or players of the white pieces.
+The names are given as they would appear in a telephone directory. The family
+or last name appears first. If a first name or first initial is available, it
+is separated from the family name by a comma and a space. Finally, one or more
+middle initials may appear. (Wherever a comma appears, the very next character
+should be a space. Wherever an initial appears, the very next character should
+be a period.) If the name is unknown, a single question mark should appear as
+the tag value.
+
+The intent is to allow meaningful ASCII sorting of the tag value that is
+independent of regional name formation customs. If more than one person is
+playing the white pieces, the names are listed in alphabetical order and are
+separated by the colon character between adjacent entries. A player who is
+also a computer program should have appropriate version information listed
+after the name of the program.
+
+The format used in the FIDE Rating Lists is appropriate for use for player name
+tags.
+
+Examples:
+
+[White "Tal, Mikhail N."]
+
+[White "van der Wiel, Johan"]
+
+[White "Acme Pawngrabber v.3.2"]
+
+[White "Fine, R."]
+
+
+8.1.1.6: The Black tag
+
+The Black tag value is the name of the player or players of the black pieces.
+The names are given here as they are for the White tag value.
+
+Examples:
+
+[Black "Lasker, Emmanuel"]
+
+[Black "Smyslov, Vasily V."]
+
+[Black "Smith, John Q.:Woodpusher 2000"]
+
+[Black "Morphy"]
+
+
+8.1.1.7: The Result tag
+
+The Result field value is the result of the game. It is always exactly the
+same as the game termination marker that concludes the associated movetext. It
+is always one of four possible values: "1-0" (White wins), "0-1" (Black wins),
+"1/2-1/2" (drawn game), and "*" (game still in progress, game abandoned, or
+result otherwise unknown). Note that the digit zero is used in both of the
+first two cases; not the letter "O".
+
+All possible examples:
+
+[Result "0-1"]
+
+[Result "1-0"]
+
+[Result "1/2-1/2"]
+
+[Result "*"]
+
+
+8.2: Movetext section
+
+The movetext section is composed of chess moves, move number indications,
+optional annotations, and a single concluding game termination marker.
+
+Because illegal moves are not real chess moves, they are not permitted in PGN
+movetext. They may appear in commentary, however. One would hope that illegal
+moves are relatively rare in games worthy of recording.
+
+
+8.2.1: Movetext line justification
+
+In PGN import format, tokens in the movetext do not require any specific line
+justification.
+
+In PGN export format, tokens in the movetext are placed left justified on
+successive text lines each of which has less than 80 printing characters. As
+many tokens as possible are placed on a line with the remainder appearing on
+successive lines. A single space character appears between any two adjacent
+symbol tokens on the same line in the movetext. As with the tag pair section,
+a single empty line follows the last line of data to conclude the movetext
+section.
+
+Neither the first or the last character on an export format PGN line is a
+space. (This may change in the case of commentary; this area is currently
+under development.)
+
+
+8.2.2: Movetext move number indications
+
+A move number indication is composed of one or more adjacent digits (an integer
+token) followed by zero or more periods. The integer portion of the indication
+gives the move number of the immediately following white move (if present) and
+also the immediately following black move (if present).
+
+
+8.2.2.1: Import format move number indications
+
+PGN import format does not require move number indications. It does not
+prohibit superfluous move number indications anywhere in the movetext as long
+as the move numbers are correct.
+
+PGN import format move number indications may have zero or more period
+characters following the digit sequence that gives the move number; one or more
+white space characters may appear between the digit sequence and the period(s).
+
+
+8.2.2.2: Export format move number indications
+
+There are two export format move number indication formats, one for use
+appearing immediately before a white move element and one for use appearing
+immediately before a black move element. A white move number indication is
+formed from the integer giving the fullmove number with a single period
+character appended. A black move number indication is formed from the integer
+giving the fullmove number with three period characters appended.
+
+All white move elements have a preceding move number indication. A black move
+element has a preceding move number indication only in two cases: first, if
+there is intervening annotation or commentary between the black move and the
+previous white move; and second, if there is no previous white move in the
+special case where a game starts from a position where Black is the active
+player.
+
+There are no other cases where move number indications appear in PGN export
+format.
+
+
+8.2.3: Movetext SAN (Standard Algebraic Notation)
+
+SAN (Standard Algebraic Notation) is a representation standard for chess moves
+using the ASCII Latin alphabet.
+
+Examples of SAN recorded games are found throughout most modern chess
+publications. SAN as presented in this document uses English language single
+character abbreviations for chess pieces, although this is easily changed in
+the source. English is chosen over other languages because it appears to be
+the most widely recognized.
+
+An alternative to SAN is FAN (Figurine Algebraic Notation). FAN uses miniature
+piece icons instead of single letter piece abbreviations. The two notations
+are otherwise identical.
+
+
+8.2.3.1: Square identification
+
+SAN identifies each of the sixty four squares on the chessboard with a unique
+two character name. The first character of a square identifier is the file of
+the square; a file is a column of eight squares designated by a single lower
+case letter from "a" (leftmost or queenside) up to and including "h" (rightmost
+or kingside). The second character of a square identifier is the rank of the
+square; a rank is a row of eight squares designated by a single digit from "1"
+(bottom side [White's first rank]) up to and including "8" (top side [Black's
+first rank]). The initial squares of some pieces are: white queen rook at a1,
+white king at e1, black queen knight pawn at b7, and black king rook at h8.
+
+
+8.2.3.2: Piece identification
+
+SAN identifies each piece by a single upper case letter. The standard English
+values: pawn = "P", knight = "N", bishop = "B", rook = "R", queen = "Q", and
+king = "K".
+
+The letter code for a pawn is not used for SAN moves in PGN export format
+movetext. However, some PGN import software disambiguation code may allow for
+the appearance of pawn letter codes. Also, pawn and other piece letter codes
+are needed for use in some tag pair and annotation constructs.
+
+It is admittedly a bit chauvinistic to select English piece letters over those
+from other languages. There is a slight justification in that English is a de
+facto universal second language among most chessplayers and program users. It
+is probably the best that can be done for now. A later section of this
+document gives alternative piece letters, but these should be used only for
+local presentation software and not for archival storage or for dynamic
+interchange among programs.
+
+
+8.2.3.3: Basic SAN move construction
+
+A basic SAN move is given by listing the moving piece letter (omitted for
+pawns) followed by the destination square. Capture moves are denoted by the
+lower case letter "x" immediately prior to the destination square; pawn
+captures include the file letter of the originating square of the capturing
+pawn immediately prior to the "x" character.
+
+SAN kingside castling is indicated by the sequence "O-O"; queenside castling is
+indicated by the sequence "O-O-O". Note that the upper case letter "O" is
+used, not the digit zero. The use of a zero character is not only incompatible
+with traditional text practices, but it can also confuse parsing algorithms
+which also have to understand about move numbers and game termination markers.
+Also note that the use of the letter "O" is consistent with the practice of
+having all chess move symbols start with a letter; also, it follows the
+convention that all non-pwn move symbols start with an upper case letter.
+
+En passant captures do not have any special notation; they are formed as if the
+captured pawn were on the capturing pawn's destination square. Pawn promotions
+are denoted by the equal sign "=" immediately following the destination square
+with a promoted piece letter (indicating one of knight, bishop, rook, or queen)
+immediately following the equal sign. As above, the piece letter is in upper
+case.
+
+
+8.2.3.4: Disambiguation
+
+In the case of ambiguities (multiple pieces of the same type moving to the same
+square), the first appropriate disambiguating step of the three following steps
+is taken:
+
+First, if the moving pieces can be distinguished by their originating files,
+the originating file letter of the moving piece is inserted immediately after
+the moving piece letter.
+
+Second (when the first step fails), if the moving pieces can be distinguished
+by their originating ranks, the originating rank digit of the moving piece is
+inserted immediately after the moving piece letter.
+
+Third (when both the first and the second steps fail), the two character square
+coordinate of the originating square of the moving piece is inserted
+immediately after the moving piece letter.
+
+Note that the above disambiguation is needed only to distinguish among moves of
+the same piece type to the same square; it is not used to distinguish among
+attacks of the same piece type to the same square. An example of this would be
+a position with two white knights, one on square c3 and one on square g1 and a
+vacant square e2 with White to move. Both knights attack square e2, and if
+both could legally move there, then a file disambiguation is needed; the
+(nonchecking) knight moves would be "Nce2" and "Nge2". However, if the white
+king were at square e1 and a black bishop were at square b4 with a vacant
+square d2 (thus an absolute pin of the white knight at square c3), then only
+one white knight (the one at square g1) could move to square e2: "Ne2".
+
+
+8.2.3.5: Check and checkmate indication characters
+
+If the move is a checking move, the plus sign "+" is appended as a suffix to
+the basic SAN move notation; if the move is a checkmating move, the octothorpe
+sign "#" is appended instead.
+
+Neither the appearance nor the absence of either a check or checkmating
+indicator is used for disambiguation purposes. This means that if two (or
+more) pieces of the same type can move to the same square the differences in
+checking status of the moves does not allieviate the need for the standard rank
+and file disabiguation described above. (Note that a difference in checking
+status for the above may occur only in the case of a discovered check.)
+
+Neither the checking or checkmating indicators are considered annotation as
+they do not communicate subjective information. Therefore, they are
+qualitatively different from move suffix annotations like "!" and "?".
+Subjective move annotations are handled using Numeric Annotation Glyphs as
+described in a later section of this document.
+
+There are no special markings used for double checks or discovered checks.
+
+There are no special markings used for drawing moves.
+
+
+8.2.3.6: SAN move length
+
+SAN moves can be as short as two characters (e.g., "d4"), or as long as seven
+characters (e.g., "Qa6xb7#", "fxg1=Q+"). The average SAN move length seen in
+realistic games is probably just fractionally longer than three characters. If
+the SAN rules seem complicated, be assured that the earlier notation systems of
+LEN (Long English Notation) and EDN (English Descriptive Notation) are much
+more complex, and that LAN (Long Algebraic Notation, the predecessor of SAN) is
+unnecessarily bulky.
+
+
+8.2.3.7: Import and export SAN
+
+PGN export format always uses the above canonical SAN to represent moves in the
+movetext section of a PGN game. Import format is somewhat more relaxed and it
+makes allowances for moves that do not conform exactly to the canonical format.
+However, these allowances may differ among different PGN reader programs. Only
+data appearing in export format is in all cases guaranteed to be importable
+into all PGN readers.
+
+There are a number of suggested guidelines for use with implementing PGN reader
+software for permitting non-canonical SAN move representation. The idea is to
+have a PGN reader apply various transformations to attempt to discover the move
+that is represented by non-canonical input. Some suggested transformations
+include: letter case remapping, capture indicator insertion, check indicator
+insertion, and checkmate indicator insertion.
+
+
+8.2.3.8: SAN move suffix annotations
+
+Import format PGN allows for the use of traditional suffix annotations for
+moves. There are exactly six such annotations available: "!", "?", "!!", "!?",
+"?!", and "??". At most one such suffix annotation may appear per move, and if
+present, it is always the last part of the move symbol.
+
+When exported, a move suffix annotation is translated into the corresponding
+Numeric Annotation Glyph as described in a later section of this document. For
+example, if the single move symbol "Qxa8?" appears in an import format PGN
+movetext, it would be replaced with the two adjacent symbols "Qxa8 $2".
+
+
+8.2.4: Movetext NAG (Numeric Annotation Glyph)
+
+An NAG (Numeric Annotation Glyph) is a movetext element that is used to
+indicate a simple annotation in a language independent manner. An NAG is
+formed from a dollar sign ("$") with a non-negative decimal integer suffix.
+The non-negative integer must be from zero to 255 in value.
+
+
+8.2.5: Movetext RAV (Recursive Annotation Variation)
+
+An RAV (Recursive Annotation Variation) is a sequence of movetext containing
+one or more moves enclosed in parentheses. An RAV is used to represent an
+alternative variation. The alternate move sequence given by an RAV is one that
+may be legally played by first unplaying the move that appears immediately
+prior to the RAV. Because the RAV is a recursive construct, it may be nested.
+
+*** The specification for import/export representation of RAV elements needs
+further development.
+
+
+8.2.6: Game Termination Markers
+
+Each movetext section has exactly one game termination marker; the marker
+always occurs as the last element in the movetext. The game termination marker
+is a symbol that is one of the following four values: "1-0" (White wins), "0-1"
+(Black wins), "1/2-1/2" (drawn game), and "*" (game in progress, result
+unknown, or game abandoned). Note that the digit zero is used in the above;
+not the upper case letter "O". The game termination marker appearing in the
+movetext of a game must match the value of the game's Result tag pair. (While
+the marker appears as a string in the Result tag, it appears as a symbol
+without quotes in the movetext.)
+
+
+9: Supplemental tag names
+
+The following tag names and their associated semantics are recommended for use
+for information not contained in the Seven Tag Roster.
+
+
+9.1: Player related information
+
+Note that if there is more than one player field in an instance of a player
+(White or Black) tag, then there will be corresponding multiple fields in any
+of the following tags. For example, if the White tag has the three field value
+"Jones:Smith:Zacharias" (a consultation game), then the WhiteTitle tag could
+have a value of "IM:-:GM" if Jones was an International Master, Smith was
+untitled, and Zacharias was a Grandmaster.
+
+
+9.1.1: Tags: WhiteTitle, BlackTitle
+
+These use string values such as "FM", "IM", and "GM"; these tags are used only
+for the standard abbreviations for FIDE titles. A value of "-" is used for an
+untitled player.
+
+
+9.1.2: Tags: WhiteElo, BlackElo
+
+These tags use integer values; these are used for FIDE Elo ratings. A value of
+"-" is used for an unrated player.
+
+
+9.1.3: Tags: WhiteUSCF, BlackUSCF
+
+These tags use integer values; these are used for USCF (United States Chess
+Federation) ratings. Similar tag names can be constructed for other rating
+agencies.
+
+
+9.1.4: Tags: WhiteNA, BlackNA
+
+These tags use string values; these are the e-mail or network addresses of the
+players. A value of "-" is used for a player without an electronic address.
+
+
+9.1.5: Tags: WhiteType, BlackType
+
+These tags use string values; these describe the player types. The value
+"human" should be used for a person while the value "program" should be used
+for algorithmic (computer) players.
+
+
+9.2: Event related information
+
+The following tags are used for providing additional information about the
+event.
+
+
+9.2.1: Tag: EventDate
+
+This uses a date value, similar to the Date tag field, that gives the starting
+date of the Event.
+
+
+9.2.2: Tag: EventSponsor
+
+This uses a string value giving the name of the sponsor of the event.
+
+
+9.2.3: Tag: Section
+
+This uses a string; this is used for the playing section of a tournament (e.g.,
+"Open" or "Reserve").
+
+
+9.2.4: Tag: Stage
+
+This uses a string; this is used for the stage of a multistage event (e.g.,
+"Preliminary" or "Semifinal").
+
+
+9.2.5: Tag: Board
+
+This uses an integer; this identifies the board number in a team event and also
+in a simultaneous exhibition.
+
+
+9.3: Opening information (locale specific)
+
+The following tag pairs are used for traditional opening names. The associated
+tag values will vary according to the local language in use.
+
+
+9.3.1: Tag: Opening
+
+This uses a string; this is used for the traditional opening name. This will
+vary by locale. This tag pair is associated with the use of the EPD opcode
+"v0" described in a later section of this document.
+
+
+9.3.2: Tag: Variation
+
+This uses a string; this is used to further refine the Opening tag. This will
+vary by locale. This tag pair is associated with the use of the EPD opcode
+"v1" described in a later section of this document.
+
+
+9.3.3: Tag: SubVariation
+
+This uses a string; this is used to further refine the Variation tag. This
+will vary by locale. This tag pair is associated with the use of the EPD
+opcode "v2" described in a later section of this document.
+
+
+9.4: Opening information (third party vendors)
+
+The following tag pairs are used for representing opening identification
+according to various third party vendors and organizations. References to
+these organizations does not imply any endorsement of them or any endorsement
+by them.
+
+
+9.4.1: Tag: ECO
+
+This uses a string of either the form "XDD" or the form "XDD/DD" where the "X"
+is a letter from "A" to "E" and the "D" positions are digits; this is used for
+an opening designation from the five volume _Encyclopedia of Chess Openings_.
+This tag pair is associated with the use of the EPD opcode "eco" described in a
+later section of this document.
+
+
+9.4.2: Tag: NIC
+
+This uses a string; this is used for an opening designation from the _New in
+Chess_ database. This tag pair is associated with the use of the EPD opcode
+"nic" described in a later section of this document.
+
+
+9.5: Time and date related information
+
+The following tags assist with further refinement of the time and data
+information associated with a game.
+
+
+9.5.1: Tag: Time
+
+This uses a time-of-day value in the form "HH:MM:SS"; similar to the Date tag
+except that it denotes the local clock time (hours, minutes, and seconds) of
+the start of the game. Note that colons, not periods, are used for field
+separators for the Time tag value. The value is taken from the local time
+corresponding to the location given in the Site tag pair.
+
+
+9.5.2: Tag: UTCTime
+
+This tag is similar to the Time tag except that the time is given according to
+the Universal Coordinated Time standard.
+
+
+9.5.3: Tag:; UTCDate
+
+This tag is similar to the Date tag except that the date is given according to
+the Universal Coordinated Time standard.
+
+
+9.6: Time control
+
+The follwing tag is used to help describe the time control used with the game.
+
+
+9.6.1: Tag: TimeControl
+
+This uses a list of one or more time control fields. Each field contains a
+descriptor for each time control period; if more than one descriptor is present
+then they are separated by the colon character (":"). The descriptors appear
+in the order in which they are used in the game. The last field appearing is
+considered to be implicitly repeated for further control periods as needed.
+
+There are six kinds of TimeControl fields.
+
+The first kind is a single question mark ("?") which means that the time
+control mode is unknown. When used, it is usually the only descriptor present.
+
+The second kind is a single hyphen ("-") which means that there was no time
+control mode in use. When used, it is usually the only descriptor present.
+
+The third Time control field kind is formed as two positive integers separated
+by a solidus ("/") character. The first integer is the number of moves in the
+period and the second is the number of seconds in the period. Thus, a time
+control period of 40 moves in 2 1/2 hours would be represented as "40/9000".
+
+The fourth TimeControl field kind is used for a "sudden death" control period.
+It should only be used for the last descriptor in a TimeControl tag value. It
+is sometimes the only descriptor present. The format consists of a single
+integer that gives the number of seconds in the period. Thus, a blitz game
+would be represented with a TimeControl tag value of "300".
+
+The fifth TimeControl field kind is used for an "incremental" control period.
+It should only be used for the last descriptor in a TimeControl tag value and
+is usually the only descriptor in the value. The format consists of two
+positive integers separated by a plus sign ("+") character. The first integer
+gives the minimum number of seconds allocated for the period and the second
+integer gives the number of extra seconds added after each move is made. So,
+an incremental time control of 90 minutes plus one extra minute per move would
+be given by "4500+60" in the TimeControl tag value.
+
+The sixth TimeControl field kind is used for a "sandclock" or "hourglass"
+control period. It should only be used for the last descriptor in a
+TimeControl tag value and is usually the only descriptor in the value. The
+format consists of an asterisk ("*") immediately followed by a positive
+integer. The integer gives the total number of seconds in the sandclock
+period. The time control is implemented as if a sandclock were set at the
+start of the period with an equal amount of sand in each of the two chambers
+and the players invert the sandclock after each move with a time forfeit
+indicated by an empty upper chamber. Electronic implementation of a physical
+sandclock may be used. An example sandclock specification for a common three
+minute egg timer sandclock would have a tag value of "*180".
+
+Additional TimeControl field kinds will be defined as necessary.
+
+
+9.7: Alternative starting positions
+
+There are two tags defined for assistance with describing games that did not
+start from the usual initial array.
+
+
+9.7.1: Tag: SetUp
+
+This tag takes an integer that denotes the "set-up" status of the game. A
+value of "0" indicates that the game has started from the usual initial array.
+A value of "1" indicates that the game started from a set-up position; this
+position is given in the "FEN" tag pair. This tag must appear for a game
+starting with a set-up position. If it appears with a tag value of "1", a FEN
+tag pair must also appear.
+
+
+9.7.2: Tag: FEN
+
+This tag uses a string that gives the Forsyth-Edwards Notation for the starting
+position used in the game. FEN is described in a later section of this
+document. If a SetUp tag appears with a tag value of "1", the FEN tag pair is
+also required.
+
+
+9.8: Game conclusion
+
+There is a single tag that discusses the conclusion of the game.
+
+
+9.8.1: Tag: Termination
+
+This takes a string that describes the reason for the conclusion of the game.
+While the Result tag gives the result of the game, it does not provide any
+extra information and so the Termination tag is defined for this purpose.
+
+Strings that may appear as Termination tag values:
+
+* "abandoned": abandoned game.
+
+* "adjudication": result due to third party adjudication process.
+
+* "death": losing player called to greater things, one hopes.
+
+* "emergency": game concluded due to unforeseen circumstances.
+
+* "normal": game terminated in a normal fashion.
+
+* "rules infraction": administrative forfeit due to losing player's failure to
+observe either the Laws of Chess or the event regulations.
+
+* "time forfeit": loss due to losing player's failure to meet time control
+requirements.
+
+* "unterminated": game not terminated.
+
+
+9.9: Miscellaneous
+
+These are tags that can be briefly described and that doon't fit well inother
+sections.
+
+
+9.9.1: Tag: Annotator
+
+This tag uses a name or names in the format of the player name tags; this
+identifies the annotator or annotators of the game.
+
+
+9.9.2: Tag: Mode
+
+This uses a string that gives the playing mode of the game. Examples: "OTB"
+(over the board), "PM" (paper mail), "EM" (electronic mail), "ICS" (Internet
+Chess Server), and "TC" (general telecommunication).
+
+
+9.9.3: Tag: PlyCount
+
+This tag takes a single integer that gives the number of ply (moves) in the
+game.
+
+
+10: Numeric Annotation Glyphs
+
+NAG zero is used for a null annotation; it is provided for the convenience of
+software designers as a placeholder value and should probably not be used in
+external PGN data.
+
+NAGs with values from 1 to 9 annotate the move just played.
+
+NAGs with values from 10 to 135 modify the current position.
+
+NAGs with values from 136 to 139 describe time pressure.
+
+Other NAG values are reserved for future definition.
+
+Note: the number assignments listed below should be considered preliminary in
+nature; they are likely to be changed as a result of reviewer feedback.
+
+NAG Interpretation
+--- --------------
+ 0 null annotation
+ 1 good move (traditional "!")
+ 2 poor move (traditional "?")
+ 3 very good move (traditional "!!")
+ 4 very poor move (traditional "??")
+ 5 speculative move (traditional "!?")
+ 6 questionable move (traditional "?!")
+ 7 forced move (all others lose quickly)
+ 8 singular move (no reasonable alternatives)
+ 9 worst move
+ 10 drawish position
+ 11 equal chances, quiet position
+ 12 equal chances, active position
+ 13 unclear position
+ 14 White has a slight advantage
+ 15 Black has a slight advantage
+ 16 White has a moderate advantage
+ 17 Black has a moderate advantage
+ 18 White has a decisive advantage
+ 19 Black has a decisive advantage
+ 20 White has a crushing advantage (Black should resign)
+ 21 Black has a crushing advantage (White should resign)
+ 22 White is in zugzwang
+ 23 Black is in zugzwang
+ 24 White has a slight space advantage
+ 25 Black has a slight space advantage
+ 26 White has a moderate space advantage
+ 27 Black has a moderate space advantage
+ 28 White has a decisive space advantage
+ 29 Black has a decisive space advantage
+ 30 White has a slight time (development) advantage
+ 31 Black has a slight time (development) advantage
+ 32 White has a moderate time (development) advantage
+ 33 Black has a moderate time (development) advantage
+ 34 White has a decisive time (development) advantage
+ 35 Black has a decisive time (development) advantage
+ 36 White has the initiative
+ 37 Black has the initiative
+ 38 White has a lasting initiative
+ 39 Black has a lasting initiative
+ 40 White has the attack
+ 41 Black has the attack
+ 42 White has insufficient compensation for material deficit
+ 43 Black has insufficient compensation for material deficit
+ 44 White has sufficient compensation for material deficit
+ 45 Black has sufficient compensation for material deficit
+ 46 White has more than adequate compensation for material deficit
+ 47 Black has more than adequate compensation for material deficit
+ 48 White has a slight center control advantage
+ 49 Black has a slight center control advantage
+ 50 White has a moderate center control advantage
+ 51 Black has a moderate center control advantage
+ 52 White has a decisive center control advantage
+ 53 Black has a decisive center control advantage
+ 54 White has a slight kingside control advantage
+ 55 Black has a slight kingside control advantage
+ 56 White has a moderate kingside control advantage
+ 57 Black has a moderate kingside control advantage
+ 58 White has a decisive kingside control advantage
+ 59 Black has a decisive kingside control advantage
+ 60 White has a slight queenside control advantage
+ 61 Black has a slight queenside control advantage
+ 62 White has a moderate queenside control advantage
+ 63 Black has a moderate queenside control advantage
+ 64 White has a decisive queenside control advantage
+ 65 Black has a decisive queenside control advantage
+ 66 White has a vulnerable first rank
+ 67 Black has a vulnerable first rank
+ 68 White has a well protected first rank
+ 69 Black has a well protected first rank
+ 70 White has a poorly protected king
+ 71 Black has a poorly protected king
+ 72 White has a well protected king
+ 73 Black has a well protected king
+ 74 White has a poorly placed king
+ 75 Black has a poorly placed king
+ 76 White has a well placed king
+ 77 Black has a well placed king
+ 78 White has a very weak pawn structure
+ 79 Black has a very weak pawn structure
+ 80 White has a moderately weak pawn structure
+ 81 Black has a moderately weak pawn structure
+ 82 White has a moderately strong pawn structure
+ 83 Black has a moderately strong pawn structure
+ 84 White has a very strong pawn structure
+ 85 Black has a very strong pawn structure
+ 86 White has poor knight placement
+ 87 Black has poor knight placement
+ 88 White has good knight placement
+ 89 Black has good knight placement
+ 90 White has poor bishop placement
+ 91 Black has poor bishop placement
+ 92 White has good bishop placement
+ 93 Black has good bishop placement
+ 84 White has poor rook placement
+ 85 Black has poor rook placement
+ 86 White has good rook placement
+ 87 Black has good rook placement
+ 98 White has poor queen placement
+ 99 Black has poor queen placement
+100 White has good queen placement
+101 Black has good queen placement
+102 White has poor piece coordination
+103 Black has poor piece coordination
+104 White has good piece coordination
+105 Black has good piece coordination
+106 White has played the opening very poorly
+107 Black has played the opening very poorly
+108 White has played the opening poorly
+109 Black has played the opening poorly
+110 White has played the opening well
+111 Black has played the opening well
+112 White has played the opening very well
+113 Black has played the opening very well
+114 White has played the middlegame very poorly
+115 Black has played the middlegame very poorly
+116 White has played the middlegame poorly
+117 Black has played the middlegame poorly
+118 White has played the middlegame well
+119 Black has played the middlegame well
+120 White has played the middlegame very well
+121 Black has played the middlegame very well
+122 White has played the ending very poorly
+123 Black has played the ending very poorly
+124 White has played the ending poorly
+125 Black has played the ending poorly
+126 White has played the ending well
+127 Black has played the ending well
+128 White has played the ending very well
+129 Black has played the ending very well
+130 White has slight counterplay
+131 Black has slight counterplay
+132 White has moderate counterplay
+133 Black has moderate counterplay
+134 White has decisive counterplay
+135 Black has decisive counterplay
+136 White has moderate time control pressure
+137 Black has moderate time control pressure
+138 White has severe time control pressure
+139 Black has severe time control pressure
+
+
+11: File names and directories
+
+File names chosen for PGN data should be both informative and portable. The
+directory names and arrangements should also be chosen for the same reasons and
+also for ease of navigation.
+
+Some of suggested file and directory names may be difficult or impossible to
+represent on certain computing systems. Use of appropriate conversion customs
+is encouraged.
+
+
+11.1: File name suffix for PGN data
+
+The use of the file suffix ".pgn" is encouraged for ASCII text files containing
+PGN data.
+
+
+11.2: File name formation for PGN data for a specific player
+
+PGN games for a specific player should have a file name consisting of the
+player's last name followed by the ".pgn" suffix.
+
+
+11.3: File name formation for PGN data for a specific event
+
+PGN games for a specific event should have a file name consisting of the
+event's name followed by the ".pgn" suffix.
+
+
+11.4: File name formation for PGN data for chronologically ordered games
+
+PGN data files used for chronologically ordered (oldest first) archives use
+date information as file name root strings. A file containing all the PGN
+games for a given year would have an eight character name in the format
+"YYYY.pgn". A file containing PGN data for a given month would have a ten
+character name in the format "YYYYMM.pgn". Finally, a file for PGN games for a
+single day would have a twelve character name in the format "YYYYMMDD.pgn".
+Large files are split into smaller files as needed.
+
+As game files are commonly arranged by chronological order, games with missing
+or incomplete Date tag pair data are to be avoided. Any question mark
+characters in a Date tag value will be treated as zero digits for collation
+within a file and also for file naming.
+
+Large quantities of PGN data arranged by chronological order should be
+organized into hierarchical directories. A directory containing all PGN data
+for a given year would have a four character name in the format "YYYY";
+directories containing PGN files for a given month would have a six character
+name in the format "YYYYMM".
+
+
+11.5: Suggested directory tree organization
+
+A suggested directory arrangement for ftp sites and CD-ROM distributions:
+
+* PGN: master directory of the PGN subtree (pub/chess/Game-Databases/PGN)
+
+* PGN/Events: directory of PGN files, each for a specific event
+
+* PGN/Events/News: news and status of the event collection
+
+* PGN/Events/ReadMe: brief description of the local directory contents
+
+* PGN/MGR: directory of the Master Games Repository subtree
+
+* PGN/MGR/News: news and status of the entire PGN/MGR subtree
+
+* PGN/MGR/ReadMe: brief description of the local directory contents
+
+* PGN/MGR/YYYY: directory of games or subtrees for the year YYYY
+
+* PGN/MGR/YYYY/ReadMe: description of local directory for year YYYY
+
+* PGN/MGR/YYYY/News: news and status for year YYYY data
+
+* PGN/News: news and status of the entire PGN subtree
+
+* PGN/Players: directory of PGN files, each for a specific player
+
+* PGN/Players/News: news and status of the player collection
+
+* PGN/Players/ReadMe: brief description of the local directory contents
+
+* PGN/ReadMe: brief description of the local directory contents
+
+* PGN/Standard: the PGN standard (this document)
+
+* PGN/Tools: software utilities that access PGN data
+
+
+12: PGN collating sequence
+
+There is a standard sorting order for PGN games within a file. This collation
+is based on eight keys; these are the seven tag values of the STR and also the
+movetext itself.
+
+The first (most important, primary key) is the Date tag. Earlier dated games
+appear prior to games played at a later date. This field is sorted by
+ascending numeric value first with the year, then the month, and finally the
+day of the month. Query characters used for unknown date digit values will be
+treated as zero digit characters for ordering comparison.
+
+The second key is the Event tag. This is sorted in ascending ASCII order.
+
+The third key is the Site tag. This is sorted in ascending ASCII order.
+
+The fourth key is the Round tag. This is sorted in ascending numeric order
+based on the value of the integer used to denote the playing round. A query or
+hyphen used for the round is ordered before any integer value. A query
+character is ordered before a hyphen character.
+
+The fifth key is the White tag. This is sorted in ascending ASCII order.
+
+The sixth key is the Black tag. This is sorted in ascending ASCII order.
+
+The seventh key is the Result tag. This is sorted in ascending ASCII order.
+
+The eighth key is the movetext itself. This is sorted in ascending ASCII order
+with the entire text including spaces and newline characters.
+
+
+13: PGN software
+
+This section describes some PGN software that is either currently available or
+expected to be available in the near future. The entries are presented in
+rough chronological order of their being made known to the PGN standard
+coordinator. Authors of PGN capable software are encouraged to contact the
+coordinator (e-mail address listed near the start of this document) so that the
+information may be included here in this section.
+
+In addition to the PGN standard, there are two more chess standards of interest
+to the chess software community. These are the FEN standard (Forsyth-Edwards
+Notation) for position notation and the EPD standard (Extended Position
+Description) for comprehensive position description for automated interprogram
+processing. These are described in a later section of this document.
+
+Some PGN software is freeware and can be gotten from ftp sites and other
+sources. Other PGN software is payware and appears as part of commercial
+chessplaying programs and chess database managers. Those who are interested in
+the propagation of the PGN standard are encouraged to support manufacturers of
+chess software that use the standard. If a particular vendor does not offer
+PGN compatibility, it is likely that a few letters to them along with a copy of
+this specification may help them decide to include PGN support in their next
+release.
+
+The staff at the University of Oklahoma at Norman (USA) have graciously
+provided an ftp site (chess.uoknor.edu) for the storage of chess related data
+and programs. Because file names change over time, those accessing the site
+are encouraged to first retrieve the file "pub/chess/ls-lR.gz" for a current
+listing. A scan of this listing will also help locate versions of PGN programs
+for machine types and operating systems other than those listed below. Further
+information about this archive can be gotten from its administrator, Chris
+Petroff (chris@uoknor.edu).
+
+For European users, the kind staff at the University of Hamburg (Germany) have
+provided the ftp site ftp.math.uni-hamburg.de; this carries a daily mirror of
+the pub/chess directory at the chess.uoknor.edu site.
+
+
+13.1: The SAN Kit
+
+The "SAN Kit" is an ANSI C source chess programming toolkit available for free
+from the ftp site chess.uoknor.edu in the directory pub/chess/Unix as the file
+"SAN.tar.gz" (a gzip tar archive). This kit contains code for PGN import and
+export and can be used to "regularize" PGN data into reduced export format by
+use of its "tfgg" command. The SAN Kit also supports FEN I/O. Code from this
+kit is freely redistributable for anyone as long as future distribution is
+unhindered for everyone. The SAN Kit is undergoing continuous development,
+although dates of future deliveries are quite difficult to predict and releases
+sometimes appear months apart. Suggestions and comments should be directed to
+its author, Steven J. Edwards (sje@world.std.com).
+
+
+13.2: pgnRead
+
+The program "pgnRead" runs under MS Windows 3.1 and provides an interactive
+graphical user interface for scanning PGN data files. This program includes a
+colorful figurine chessboard display and scrolling controls for game and game
+text selection. It is available from the chess.uoknor.edu ftp site in the
+pub/chess/DOS directory; several versions are available with names of the form
+"pgnrd**.exe"; the latest at this writing is "PGNRD130.EXE". Suggestions and
+comments should be directed to its author, Keith Fuller (keithfx@aol.com).
+
+
+13.3: mail2pgn/GIICS
+
+The program "mail2pgn" produces a PGN version of chess game data generated by
+the ICS (Internet Chess Server). It can be found at the chess.uoknor.edu ftp
+site in the pub/chess/DOS directory as the file "mail2pgn.zip" A C language
+version is in the directory pub/chess/Unix as the file "mail2pgn.c".
+Suggestions and comments should be directed to its author, John Aronson
+(aronson@helios.ece.arizona.edu). This code has been reportedly incorporated
+into the GIICS (Graphical Interface for the ICS); suggestions and comments
+should be directed to its author, Tony Acero (ace3@midway.uchicago.edu).
+
+There is a report that mail2pgn has been superseded by the newer program
+"MV2PGN" described below.
+
+
+13.4: XBoard
+
+"XBoard" is a comprehensive chess utility running under the X Window System
+that provides a graphical user interface in a portable manner. A new version
+now handles PGN data. It is available from the chess.uoknor.edu ftp site in
+the pub/chess/X directory as the file "xboard-3.0.pl9.tar.gz". Suggestions and
+comments should be directed to its author, Tim Mann (mann@src.dec.com).
+
+
+13.5: cupgn
+
+The program "cupgn" converts game data stored in the ChessBase format into PGN.
+It is available from the chess.uoknor.edu ftp site in the
+pub/chess/Game-Databases/CBUFF directory as the file "cupgn.tar.gz". Another
+version is in the directory pub/chess/DOS as the file "cupgn120.exe".
+Suggestions and comments should be directed to its author, Anjo Anjewierden
+(anjo@swi.psy.uva.nl).
+
+
+13.6: Zarkov
+
+The current version (3.0) of the commercial chessplaying program "Zarkov" can
+read and write games using PGN. This program can also use the EPD standard for
+communication with other EPD capable programs. Historically, Zarkov is the
+very first program to use EPD. Suggestions and comments should be directed to
+its author, John Stanback (jhs@icbdfcs1.fc.hp.com).
+
+A vendor for North America is:
+
+ International Chess Enterprises
+ P.O. Box 19457
+ Seattle, WA 98109
+ USA
+ (800) 262-4277
+
+A vendor for Europe is:
+
+ Gambit-Soft
+ Feckenhauser Strasse 27
+ D-78628 Rottweil
+ GERMANY
+ 49-741-21573
+
+
+13.7: Chess Assistant
+
+The upcoming version of the multifunction commercial database program "Chess
+Assistant" will be able to use the PGN standard as an import and export option.
+There is a report of a freeware program, "PGN2CA", that will convert PGN
+databases into Chess Assistant format. For more information, the contact is
+Victor Zakharov, one of the members of the Chess Assistant development team
+(VICTOR@ldis.cs.msu.su).
+
+A vendor for North America is:
+
+ International Chess Enterprises
+ P.O. Box 19457
+ Seattle, WA 98109
+ USA
+ (800) 262-4277
+
+
+13.8: BOOKUP
+
+The MS-DOS edition of the multifunction commercial program BOOKUP, version 8.1,
+is able to use the EPD standard for communication with other EPD capable
+programs. It may also be PGN capable as well.
+
+The BOOKUP 8.1.1 Addenda notes dated 1993.12.17 provide comprehensive
+information on how to use EPD in conjunction with "analyst" programs such as
+Zarkov and HIARCS. Specifically, the search and evaluation abilities of an
+analyst program are combined with the information organization abilities of the
+BOOKUP database program to provide position scoring. This is done by first
+having BOOKUP export a database in EPD format, then having an analyst program
+annotate each EPD record with a numeric score, and then having BOOKUP import
+the changed EPD file. BOOKUP can then apply minimaxing to the imported
+database; this results in scores from terminal positions being propagated back
+to earlier positions and even back to moves from the starting array.
+
+For some reason, BOOKUP calls this process "backsolving", but it's really just
+standard minimaxing. In any case, it's a good example of how different
+programs from different authors performing different types of tasks can be
+integrated by use of a common, non-proprietary standard. This allows for a new
+set of powerful features that are beyond the capabilities of any one of the
+individual component programs.
+
+BOOKUP allows for some customizing of EPD actions. One such customization is
+to require the positional evaluations to follow the EPD standard; this means
+that the score is always given from the viewpoint of the active player. This
+is explained more fully in the section on the "ce" (centipawn evaluation)
+opcode in the EPD description in a later section of this document. To ensure
+that BOOKUP handles the centipawn evaluations in the "right" way, the EPD
+setting "Positive for White" must be set to "N". This makes BOOKUP work
+correctly with Zarkov and with all other programs that use the "right"
+centipawn evaluation convention. There is an apparent problem with HIARCS that
+requires this option to be set to "Y"; but this really means that, if true,
+HIARCS needs to be adjusted to use the "right" centipawn evaluation convention.
+
+A vendor in North America is:
+
+ BOOKUP
+ 2763 Kensington Place West
+ Columbus, OH 43202
+ USA
+ (800) 949-5445
+ (614) 263-7219
+
+
+13.9: HIARCS
+
+The current version (2.1) of the commercial chessplaying program "HIARCS" is
+able to use the EPD standard for communication with other EPD capable programs.
+It may also be PGN capable as well. More details will appear here as they
+become available.
+
+A vendor in North America is:
+
+ HIARCS
+ c/o BOOKUP
+ 2763 Kensington Place West
+ Columbus, OH 43202
+ USA
+ (800) 949-5445
+ (614) 263-7219
+
+
+13.10: Deja Vu
+
+The chess database "Deja Vu" from ChessWorks is a PGN compatible collection of
+over 300,000 games. It is available only on CD-ROM and is scheduled for
+release in 1994.05 with periodic revisions thereafter. The introductory price
+is US$329. For further information, the authors are John Crayton and Eric
+Schiller and they can be contacted via e-mail (chesswks@netcom.com).
+
+
+13.11: MV2PGN
+
+The program "MV2PGN" can be used to convert game data generated by both current
+and older versions of the GIICS (Graphical Interface - Internet Chess Server).
+The program is included in the self extracting archive available from
+chess.uoknor.edu in the directory pub/chess/DOS as the file "ics2pgn.exe".
+Source code is also included. This program is reported to supersede the older
+"mail2pgn" and was needed due to a change in ICS recording format in late 1993.
+For further information about MV2PGN, the contact person is Gary Bastin
+(gbastin@x102a.ess.harris.com).
+
+
+13.12: The Hansen utilities (cb2pgn, nic2pgn, pgn2cb, pgn2nic)
+
+The Hansen utilities are used to convert among various chess data
+representation formats. The PGN related programs include: "cb2pgn.exe"
+(convert ChessBase to PGN), "nic2pgn.exe" (convert NIC to PGN), "pgn2cb.exe"
+(convert PGN to ChessBase), and "pgn2nic.exe" (convert PGN to NIC).
+
+The ChessBase related utilities (cb2pgn/pgn2cb) are found at chess.uoknor.edu
+in the pub/chess/Game-Databases/ChessBase directory.
+
+The NIC related utilities (nic2pgn/pgn2nic) are found at chess.uoknor.edu in
+the pub/chess/Game-Databases/NIC directory.
+
+For further information about the Hansen utilities, the contact person is the
+author, Carsten Hansen (ch0506@hdc.hha.dk).
+
+
+13.13: Slappy the Database
+
+"Slappy the Database" is a commercial chess database and translation program
+scheduled for release no sooner than late 1994. It is a low cost utility with
+a simple character interface intended for those who want a supported product
+but who do not need (or cannot afford) a comprehensive, feature-laden program
+with a graphical user interface. Slappy's two most important features are its
+batch processing ability and its full implementation of each and every standard
+described in this document. Versions of Slappy the Database will be provided
+for various platforms including: Intel 386/486 Unix, Apple Macintosh, and
+MS-DOS.
+
+Slappy may also be useful to those who have a full feature program who also
+need to run time consuming chess database tasks on a spare computer.
+
+Suggestions and comments should be directed to its author, Steven J. Edwards
+(sje@world.std.com). More details will appear here as they become available.
+
+
+13.14: CBASCII
+
+"CBASCII" is a general utility for converting chess data between ChessBase
+format and ASCII representations. It has PGN capability, and it is available
+from the chess.uoknor.edu ftp site in the pub/chess/DOS directory as the file
+"cba1_2.zip". The contact person is the program's author, Andy Duplain
+(duplain@btcs.bt.co.uk).
+
+
+13.15: ZZZZZZ
+
+"ZZZZZZ" is a chessplaying program, complete with source, that also includes
+some database functions. A recent version is reported to have both PGN and EPD
+capabilities. It is available from the chess.uoknor.edu ftp site in the
+pub/chess/Unix directory as the file "zzzzzz-3.2b1.tar.gz". The contact person
+is its author, Gijsbert Wiesenecker (wiesenecker@sara.nl).
+
+
+13.16: icsconv
+
+The program "icsconv" can be used to convert Internet Chess Server games, both
+old and new format, to PGN. It is available from the chess.uoknor.edu site in
+the pub/chess/Game-Databases/PGN/Tools directory as the file "icsconv.exe".
+The contact person is the author, Kevin Nomura (chow@netcom.com).
+
+
+13.17: CHESSOP (CHESSOPN/CHESSOPG)
+
+CHESSOP is an openings database and viewing tool with support for reading PGN
+games. It runs under MS-DOS and displays positions rather than games. For
+each position, both good and bad moves are listed with appropriate annotation.
+Transpositions are handled as well. The distributed database contains over
+100,000 positions covering all the common openings. Users can feed in their
+own PGN data as well. CHESSOP takes 3 Mbyte of hard disk, costs US$39 and can
+be obtained from:
+
+ CHESSX Software
+ 12 Bluebell Close
+ Glenmore Park
+ AUSTRALIA 2745.
+
+The ideas behind CHESSOP can be seen in CHESSOPN (alias CHESSOPG), a free
+version on the ICS server which has a reduced openings database (25,000
+positions) and no PGN or transposition support but is otherwise the same as
+CHESSOP. (These are the files "chessopg.zip" in the directory pub/chess/DOS at
+the chess.uoknor.edu ftp site.)
+
+
+13.18: CAT2PGN
+
+The program "CAT2PGN" is a utility that translates data from the format used by
+Chess Assistant into PGN. It is available from the chess.uoknor.edu ftp site.
+The contact person for CAT2PGN is its author, David Myers
+(myers@frodo.biochem.duke.edu).
+
+
+13.19: pgn2opg
+
+The utility "pgn2opg" can be used to convert PGN files into a text format used
+by the "CHESSOPG" program mentioned above. Although it does not perform any
+semantic analysis on PGN input, it has been demonstrated to handle known
+correct PGN input properly. The file can be found in the pub/chess/PGN/Tools
+directory at the chess.uoknor.edu ftp site. For more information, the author
+is David Barnes (djb@ukc.ac.uk).
+
+
+14: PGN data archives
+
+The primary PGN data archive repository is located at the ftp site
+chess.uoknor.edu as the directory "pub/chess/Game-Databases/PGN". It is
+organized according to the description given in section C.5 of this document.
+The European site ftp.math.uni-hamburg.de is also reported to carry a regularly
+updated copy of the repository.
+
+
+15: International Olympic Committee country codes
+
+International Olympic Committee country codes are employed for Site nation
+information because of their traditional use with the reporting of
+international sporting events. Due to changes in geography and linguistic
+custom, some of the following may be incorrect or outdated. Corrections and
+extensions should be sent via e-mail to the PGN coordinator whose address
+listed near the start of this document.
+
+AFG: Afghanistan
+AIR: Aboard aircraft
+ALB: Albania
+ALG: Algeria
+AND: Andorra
+ANG: Angola
+ANT: Antigua
+ARG: Argentina
+ARM: Armenia
+ATA: Antarctica
+AUS: Australia
+AZB: Azerbaijan
+BAN: Bangladesh
+BAR: Bahrain
+BHM: Bahamas
+BEL: Belgium
+BER: Bermuda
+BIH: Bosnia and Herzegovina
+BLA: Belarus
+BLG: Bulgaria
+BLZ: Belize
+BOL: Bolivia
+BRB: Barbados
+BRS: Brazil
+BRU: Brunei
+BSW: Botswana
+CAN: Canada
+CHI: Chile
+COL: Columbia
+CRA: Costa Rica
+CRO: Croatia
+CSR: Czechoslovakia
+CUB: Cuba
+CYP: Cyprus
+DEN: Denmark
+DOM: Dominican Republic
+ECU: Ecuador
+EGY: Egypt
+ENG: England
+ESP: Spain
+EST: Estonia
+FAI: Faroe Islands
+FIJ: Fiji
+FIN: Finland
+FRA: France
+GAM: Gambia
+GCI: Guernsey-Jersey
+GEO: Georgia
+GER: Germany
+GHA: Ghana
+GRC: Greece
+GUA: Guatemala
+GUY: Guyana
+HAI: Haiti
+HKG: Hong Kong
+HON: Honduras
+HUN: Hungary
+IND: India
+IRL: Ireland
+IRN: Iran
+IRQ: Iraq
+ISD: Iceland
+ISR: Israel
+ITA: Italy
+IVO: Ivory Coast
+JAM: Jamaica
+JAP: Japan
+JRD: Jordan
+JUG: Yugoslavia
+KAZ: Kazakhstan
+KEN: Kenya
+KIR: Kyrgyzstan
+KUW: Kuwait
+LAT: Latvia
+LEB: Lebanon
+LIB: Libya
+LIC: Liechtenstein
+LTU: Lithuania
+LUX: Luxembourg
+MAL: Malaysia
+MAU: Mauritania
+MEX: Mexico
+MLI: Mali
+MLT: Malta
+MNC: Monaco
+MOL: Moldova
+MON: Mongolia
+MOZ: Mozambique
+MRC: Morocco
+MRT: Mauritius
+MYN: Myanmar
+NCG: Nicaragua
+NET: The Internet
+NIG: Nigeria
+NLA: Netherlands Antilles
+NLD: Netherlands
+NOR: Norway
+NZD: New Zealand
+OST: Austria
+PAK: Pakistan
+PAL: Palestine
+PAN: Panama
+PAR: Paraguay
+PER: Peru
+PHI: Philippines
+PNG: Papua New Guinea
+POL: Poland
+POR: Portugal
+PRC: People's Republic of China
+PRO: Puerto Rico
+QTR: Qatar
+RIN: Indonesia
+ROM: Romania
+RUS: Russia
+SAF: South Africa
+SAL: El Salvador
+SCO: Scotland
+SEA: At Sea
+SEN: Senegal
+SEY: Seychelles
+SIP: Singapore
+SLV: Slovenia
+SMA: San Marino
+SPC: Aboard spacecraft
+SRI: Sri Lanka
+SUD: Sudan
+SUR: Surinam
+SVE: Sweden
+SWZ: Switzerland
+SYR: Syria
+TAI: Thailand
+TMT: Turkmenistan
+TRK: Turkey
+TTO: Trinidad and Tobago
+TUN: Tunisia
+UAE: United Arab Emirates
+UGA: Uganda
+UKR: Ukraine
+UNK: Unknown
+URU: Uruguay
+USA: United States of America
+UZB: Uzbekistan
+VEN: Venezuela
+VGB: British Virgin Islands
+VIE: Vietnam
+VUS: U.S. Virgin Islands
+WLS: Wales
+YEM: Yemen
+YUG: Yugoslavia
+ZAM: Zambia
+ZIM: Zimbabwe
+ZRE: Zaire
+
+
+16: Additional chess data standards
+
+While PGN is used for game storage, there are other data representation
+standards for other chess related purposes. Two important standards are FEN
+and EPD, both described in this section.
+
+
+16.1: FEN
+
+FEN is "Forsyth-Edwards Notation"; it is a standard for describing chess
+positions using the ASCII character set.
+
+A single FEN record uses one text line of variable length composed of six data
+fields. The first four fields of the FEN specification are the same as the
+first four fields of the EPD specification.
+
+A text file composed exclusively of FEN data records should have a file name
+with the suffix ".fen".
+
+
+16.1.1: History
+
+FEN is based on a 19th century standard for position recording designed by the
+Scotsman David Forsyth, a newspaper journalist. The original Forsyth standard
+has been slightly extended for use with chess software by Steven Edwards with
+assistance from commentators on the Internet. This new standard, FEN, was
+first implemented in Edwards' SAN Kit.
+
+
+16.1.2: Uses for a position notation
+
+Having a standard position notation is particularly important for chess
+programmers as it allows them to share position databases. For example, there
+exist standard position notation databases with many of the classical benchmark
+tests for chessplaying programs, and by using a common position notation format
+many hours of tedious data entry can be saved. Additionally, a position
+notation can be useful for page layout programs and for confirming position
+status for e-mail competition.
+
+Many interesting chess problem sets represented using FEN can be found at the
+chess.uoknor.edu ftp site in the directory pub/chess/SAN_testsuites.
+
+
+16.1.3: Data fields
+
+FEN specifies the piece placement, the active color, the castling availability,
+the en passant target square, the halfmove clock, and the fullmove number.
+These can all fit on a single text line in an easily read format. The length
+of a FEN position description varies somewhat according to the position. In
+some cases, the description could be eighty or more characters in length and so
+may not fit conveniently on some displays. However, these positions aren't too
+common.
+
+A FEN description has six fields. Each field is composed only of non-blank
+printing ASCII characters. Adjacent fields are separated by a single ASCII
+space character.
+
+
+16.1.3.1: Piece placement data
+
+The first field represents the placement of the pieces on the board. The board
+contents are specified starting with the eighth rank and ending with the first
+rank. For each rank, the squares are specified from file a to file h. White
+pieces are identified by uppercase SAN piece letters ("PNBRQK") and black
+pieces are identified by lowercase SAN piece letters ("pnbrqk"). Empty squares
+are represented by the digits one through eight; the digit used represents the
+count of contiguous empty squares along a rank. A solidus character "/" is
+used to separate data of adjacent ranks.
+
+
+16.1.3.2: Active color
+
+The second field represents the active color. A lower case "w" is used if
+White is to move; a lower case "b" is used if Black is the active player.
+
+
+16.1.3.3: Castling availability
+
+The third field represents castling availability. This indicates potential
+future castling that may of may not be possible at the moment due to blocking
+pieces or enemy attacks. If there is no castling availability for either side,
+the single character symbol "-" is used. Otherwise, a combination of from one
+to four characters are present. If White has kingside castling availability,
+the uppercase letter "K" appears. If White has queenside castling
+availability, the uppercase letter "Q" appears. If Black has kingside castling
+availability, the lowercase letter "k" appears. If Black has queenside
+castling availability, then the lowercase letter "q" appears. Those letters
+which appear will be ordered first uppercase before lowercase and second
+kingside before queenside. There is no white space between the letters.
+
+
+16.1.3.4: En passant target square
+
+The fourth field is the en passant target square. If there is no en passant
+target square then the single character symbol "-" appears. If there is an en
+passant target square then is represented by a lowercase file character
+immediately followed by a rank digit. Obviously, the rank digit will be "3"
+following a white pawn double advance (Black is the active color) or else be
+the digit "6" after a black pawn double advance (White being the active color).
+
+An en passant target square is given if and only if the last move was a pawn
+advance of two squares. Therefore, an en passant target square field may have
+a square name even if there is no pawn of the opposing side that may
+immediately execute the en passant capture.
+
+
+16.1.3.5: Halfmove clock
+
+The fifth field is a nonnegative integer representing the halfmove clock. This
+number is the count of halfmoves (or ply) since the last pawn advance or
+capturing move. This value is used for the fifty move draw rule.
+
+
+16.1.3.6: Fullmove number
+
+The sixth and last field is a positive integer that gives the fullmove number.
+This will have the value "1" for the first move of a game for both White and
+Black. It is incremented by one immediately after each move by Black.
+
+
+16.1.4: Examples
+
+Here's the FEN for the starting position:
+
+rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
+
+And after the move 1. e4:
+
+rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq e3 0 1
+
+And then after 1. ... c5:
+
+rnbqkbnr/pp1ppppp/8/2p5/4P3/8/PPPP1PPP/RNBQKBNR w KQkq c6 0 2
+
+And then after 2. Nf3:
+
+rnbqkbnr/pp1ppppp/8/2p5/4P3/5N2/PPPP1PPP/RNBQKB1R b KQkq - 1 2
+
+For two kings on their home squares and a white pawn on e2 (White to move) with
+thirty eight full moves played with five halfmoves since the last pawn move or
+capture:
+
+4k3/8/8/8/8/8/4P3/4K3 w - - 5 39
+
+
+16.2: EPD
+
+EPD is "Extended Position Description"; it is a standard for describing chess
+positions along with an extended set of structured attribute values using the
+ASCII character set. It is intended for data and command interchange among
+chessplaying programs. It is also intended for the representation of portable
+opening library repositories.
+
+A single EPD uses one text line of variable length composed of four data field
+followed by zero or more operations. The four fields of the EPD specification
+are the same as the first four fields of the FEN specification.
+
+A text file composed exclusively of EPD data records should have a file name
+with the suffix ".epd".
+
+
+16.2.1: History
+
+EPD is based in part on the earlier FEN standard; it has added extensions for
+use with opening library preparation and also for general data and command
+interchange among advanced chess programs. EPD was developed by John Stanback
+and Steven Edwards; its first implementation is in Stanback's master strength
+chessplaying program Zarkov.
+
+
+16.2.2: Uses for an extended position notation
+
+Like FEN, EPD can also be used for general position description. However,
+unlike FEN, EPD is designed to be expandable by the addition of new operations
+that provide new functionality as needs arise.
+
+Many interesting chess problem sets represented using EPD can be found at the
+chess.uoknor.edu ftp site in the directory pub/chess/SAN_testsuites.
+
+
+16.2.3: Data fields
+
+EPD specifies the piece placement, the active color, the castling availability,
+and the en passant target square of a position. These can all fit on a single
+text line in an easily read format. The length of an EPD position description
+varies somewhat according to the position and any associated operations. In
+some cases, the description could be eighty or more characters in length and so
+may not fit conveniently on some displays. However, most EPD descriptions pass
+among programs only and these are not usually seen by program users.
+
+(Note: due to the likelihood of future expansion of EPD, implementors are
+encouraged to have their programs handle EPD text lines of up to 1024
+characters long.)
+
+Each EPD data field is composed only of non-blank printing ASCII characters.
+Adjacent data fields are separated by a single ASCII space character.
+
+
+16.2.3.1: Piece placement data
+
+The first field represents the placement of the pieces on the board. The board
+contents are specified starting with the eighth rank and ending with the first
+rank. For each rank, the squares are specified from file a to file h. White
+pieces are identified by uppercase SAN piece letters ("PNBRQK") and black
+pieces are identified by lowercase SAN piece letters ("pnbrqk"). Empty squares
+are represented by the digits one through eight; the digit used represents the
+count of contiguous empty squares along a rank. A solidus character "/" is
+used to separate data of adjacent ranks.
+
+
+16.2.3.2: Active color
+
+The second field represents the active color. A lower case "w" is used if
+White is to move; a lower case "b" is used if Black is the active player.
+
+
+16.2.3.3: Castling availability
+
+The third field represents castling availability. This indicates potential
+future castling that may or may not be possible at the moment due to blocking
+pieces or enemy attacks. If there is no castling availability for either side,
+the single character symbol "-" is used. Otherwise, a combination of from one
+to four characters are present. If White has kingside castling availability,
+the uppercase letter "K" appears. If White has queenside castling
+availability, the uppercase letter "Q" appears. If Black has kingside castling
+availability, the lowercase letter "k" appears. If Black has queenside
+castling availability, then the lowercase letter "q" appears. Those letters
+which appear will be ordered first uppercase before lowercase and second
+kingside before queenside. There is no white space between the letters.
+
+
+16.2.3.4: En passant target square
+
+The fourth field is the en passant target square. If there is no en passant
+target square then the single character symbol "-" appears. If there is an en
+passant target square then is represented by a lowercase file character
+immediately followed by a rank digit. Obviously, the rank digit will be "3"
+following a white pawn double advance (Black is the active color) or else be
+the digit "6" after a black pawn double advance (White being the active color).
+
+An en passant target square is given if and only if the last move was a pawn
+advance of two squares. Therefore, an en passant target square field may have
+a square name even if there is no pawn of the opposing side that may
+immediately execute the en passant capture.
+
+
+16.2.4: Operations
+
+An EPD operation is composed of an opcode followed by zero or more operands and
+is concluded by a semicolon.
+
+Multiple operations are separated by a single space character. If there is at
+least one operation present in an EPD line, it is separated from the last
+(fourth) data field by a single space character.
+
+
+16.2.4.1: General format
+
+An opcode is an identifier that starts with a letter character and may be
+followed by up to fourteen more characters. Each additional character may be a
+letter or a digit or the underscore character.
+
+An operand is either a set of contiguous non-white space printing characters or
+a string. A string is a set of contiguous printing characters delimited by a
+quote character at each end. A string value must have less than 256 bytes of
+data.
+
+If at least one operand is present in an operation, there is a single space
+between the opcode and the first operand. If more than one operand is present
+in an operation, there is a single blank character between every two adjacent
+operands. If there are no operands, a semicolon character is appended to the
+opcode to mark the end of the operation. If any operands appear, the last
+operand has an appended semicolon that marks the end of the operation.
+
+Any given opcode appears at most once per EPD record. Multiple operations in a
+single EPD record should appear in ASCII order of their opcode names
+(mnemonics). However, a program reading EPD records may allow for operations
+not in ASCII order by opcode mnemonics; the semantics are the same in either
+case.
+
+Some opcodes that allow for more than one operand may have special ordering
+requirements for the operands. For example, the "pv" (predicted variation)
+opcode requires its operands (moves) to appear in the order in which they would
+be played. All other opcodes that allow for more than one operand should have
+operands appearing in ASCII order. An example of the latter set is the "bm"
+(best move[s]) opcode; its operands are moves that are all immediately playable
+from the current position.
+
+Some opcodes require one or more operands that are chess moves. These moves
+should be represented using SAN. If a different representation is used, there
+is no guarantee that the EPD will be read correctly during subsequent
+processing.
+
+Some opcodes require one or more operands that are integers. Some opcodes may
+require that an integer operand must be within a given range; the details are
+described in the opcode list given below. A negative integer is formed with a
+hyphen (minus sign) preceding the integer digit sequence. An optional plus
+sign may be used for indicating a non-negative value, but such use is not
+required and is indeed discouraged.
+
+Some opcodes require one or more operands that are floating point numbers.
+Some opcodes may require that a floating point operand must be within a given
+range; the details are described in the opcode list given below. A floating
+point operand is constructed from an optional sign character ("+" or "-"), a
+digit sequence (with at least one digit), a radix point (always "."), and a
+final digit sequence (with at least one digit).
+
+
+16.2.4.2: Opcode mnemonics
+
+An opcode mnemonic used for archival storage and for interprogram communication
+starts with a lower case letter and is composed of only lower case letters,
+digits, and the underscore character (i.e., no upper case letters). These
+mnemonics will also all be at least two characters in length.
+
+Opcode mnemonics used only by a single program or an experimental suite of
+programs should start with an upper case letter. This is so they may be easily
+distinguished should they be inadvertently be encountered by other programs.
+When a such a "private" opcode be demonstrated to be widely useful, it should
+be brought into the official list (appearing below) in a lower case form.
+
+If a given program does not recognize a particular opcode, that operation is
+simply ignored; it is not signaled as an error.
+
+
+16.2.5: Opcode list
+
+The opcodes are listed here in ASCII order of their mnemonics. Suggestions for
+new opcodes should be sent to the PGN standard coordinator listed near the
+start of this document.
+
+
+16.2.5.1: Opcode "acn": analysis count: nodes
+
+The opcode "acn" takes a single non-negative integer operand. It is used to
+represent the number of nodes examined in an analysis. Note that the value may
+be quite large for some extended searches and so use of (at least) a long (four
+byte) representation is suggested.
+
+
+16.2.5.2: Opcode "acs": analysis count: seconds
+
+The opcode "acs" takes a single non-negative integer operand. It is used to
+represent the number of seconds used for an analysis. Note that the value may
+be quite large for some extended searches and so use of (at least) a long (four
+byte) representation is suggested.
+
+
+16.2.5.3: Opcode "am": avoid move(s)
+
+The opcode "am" indicates a set of zero or more moves, all immediately playable
+from the current position, that are to be avoided in the opinion of the EPD
+writer. Each operand is a SAN move; they appear in ASCII order.
+
+
+16.2.5.4: Opcode "bm": best move(s)
+
+The opcode "bm" indicates a set of zero or more moves, all immediately playable
+from the current position, that are judged to the best available by the EPD
+writer. Each operand is a SAN move; they appear in ASCII order.
+
+
+16.2.5.5: Opcode "c0": comment (primary, also "c1" though "c9")
+
+The opcode "c0" (lower case letter "c", digit character zero) indicates a top
+level comment that applies to the given position. It is the first of ten
+ranked comments, each of which has a mnemonic formed from the lower case letter
+"c" followed by a single decimal digit. Each of these opcodes takes either a
+single string operand or no operand at all.
+
+This ten member comment family of opcodes is intended for use as descriptive
+commentary for a complete game or game fragment. The usual processing of these
+opcodes are as follows:
+
+1) At the beginning of a game (or game fragment), a move sequence scanning
+program initializes each element of its set of ten comment string registers to
+be null.
+
+2) As the EPD record for each position in the game is processed, the comment
+operations are interpreted from left to right. (Actually, all operations in n
+EPD record are interpreted from left to right.) Because operations appear in
+ASCII order according to their opcode mnemonics, opcode "c0" (if present) will
+be handled prior to all other opcodes, then opcode "c1" (if present), and so
+forth until opcode "c9" (if present).
+
+3) The processing of opcode "cN" (0 <= N <= 9) involves two steps. First, all
+comment string registers with an index equal to or greater than N are set to
+null. (This is the set "cN" though "c9".) Second, and only if a string
+operand is present, the value of the corresponding comment string register is
+set equal to the string operand.
+
+
+16.2.5.6: Opcode "ce": centipawn evaluation
+
+The opcode "ce" indicates the evaluation of the indicated position in centipawn
+units. It takes a single operand, an optionally signed integer that gives an
+evaluation of the position from the viewpoint of the active player; i.e., the
+player with the move. Positive values indicate a position favorable to the
+moving player while negative values indicate a position favorable to the
+passive player; i.e., the player without the move. A centipawn evaluation
+value close to zero indicates a neutral positional evaluation.
+
+Values are restricted to integers that are equal to or greater than -32767 and
+are less than or equal to 32766.
+
+A value greater than 32000 indicates the availability of a forced mate to the
+active player. The number of plies until mate is given by subtracting the
+evaluation from the value 32767. Thus, a winning mate in N fullmoves is a mate
+in ((2 * N) - 1) halfmoves (or ply) and has a corresponding centipawn
+evaluation of (32767 - ((2 * N) - 1)). For example, a mate on the move (mate
+in one) has a centipawn evaluation of 32766 while a mate in five has a
+centipawn evaluation of 32758.
+
+A value less than -32000 indicates the availability of a forced mate to the
+passive player. The number of plies until mate is given by subtracting the
+evaluation from the value -32767 and then negating the result. Thus, a losing
+mate in N fullmoves is a mate in (2 * N) halfmoves (or ply) and has a
+corresponding centipawn evaluation of (-32767 + (2 * N)). For example, a mate
+after the move (losing mate in one) has a centipawn evaluation of -32765 while
+a losing mate in five has a centipawn evaluation of -32757.
+
+A value of -32767 indicates an illegal position. A stalemate position has a
+centipawn evaluation of zero as does a position drawn due to insufficient
+mating material. Any other position known to be a certain forced draw also has
+a centipawn evaluation of zero.
+
+
+16.2.5.7: Opcode "dm": direct mate fullmove count
+
+The "dm" opcode is used to indicate the number of fullmoves until checkmate is
+to be delivered by the active color for the indicated position. It always
+takes a single operand which is a positive integer giving the fullmove count.
+For example, a position known to be a "mate in three" would have an operation
+of "dm 3;" to indicate this.
+
+This opcode is intended for use with problem sets composed of positions
+requiring direct mate answers as solutions.
+
+
+16.2.5.8: Opcode "draw_accept": accept a draw offer
+
+The opcode "draw_accept" is used to indicate that a draw offer made after the
+move that lead to the indicated position is accepted by the active player.
+This opcode takes no operands.
+
+
+16.2.5.9: Opcode "draw_claim": claim a draw
+
+The opcode "draw_claim" is used to indicate claim by the active player that a
+draw exists. The draw is claimed because of a third time repetition or because
+of the fifty move rule or because of insufficient mating material. A supplied
+move (see the opcode "sm") is also required to appear as part of the same EPD
+record. The draw_claim opcode takes no operands.
+
+
+16.2.5.10: Opcode "draw_offer": offer a draw
+
+The opcode "draw_offer" is used to indicate that a draw is offered by the
+active player. A supplied move (see the opcode "sm") is also required to
+appear as part of the same EPD record; this move is considered played from the
+indicated position. The draw_offer opcode takes no operands.
+
+
+16.2.5.11: Opcode "draw_reject": reject a draw offer
+
+The opcode "draw_reject" is used to indicate that a draw offer made after the
+move that lead to the indicated position is rejected by the active player.
+This opcode takes no operands.
+
+
+16.2.5.12: Opcode "eco": _Encyclopedia of Chess Openings_ opening code
+
+The opcode "eco" is used to associate an opening designation from the
+_Encyclopedia of Chess Openings_ taxonomy with the indicated position. The
+opcode takes either a single string operand (the ECO opening name) or no
+operand at all. If an operand is present, its value is associated with an
+"ECO" string register of the scanning program. If there is no operand, the ECO
+string register of the scanning program is set to null.
+
+The usage is similar to that of the "ECO" tag pair of the PGN standard.
+
+
+16.2.5.13: Opcode "fmvn": fullmove number
+
+The opcode "fmvn" represents the fullmove n umber associated with the position.
+It always takes a single operand that is the positive integer value of the move
+number.
+
+This opcode is used to explicitly represent the fullmove number in EPD that is
+present by default in FEN as the sixth field. Fullmove number information is
+usually omitted from EPD because it does not affect move generation (commonly
+needed for EPD-using tasks) but it does affect game notation (commonly needed
+for FEN-using tasks). Because of the desire for space optimization for large
+EPD files, fullmove numbers were dropped from EPD's parent FEN. The halfmove
+clock information was similarly dropped.
+
+
+16.2.5.14: Opcode "hmvc": halfmove clock
+
+The opcode "hmvc" represents the halfmove clock associated with the position.
+The halfmove clock of a position is equal to the number of plies since the last
+pawn move or capture. This information is used to implement the fifty move
+draw rule. It always takes a single operand that is the non-negative integer
+value of the halfmove clock.
+
+This opcode is used to explicitly represent the halfmove clock in EPD that is
+present by default in FEN as the fifth field. Halfmove clock information is
+usually omitted from EPD because it does not affect move generation (commonly
+needed for EPD-using tasks) but it does affect game termination issues
+(commonly needed for FEN-using tasks). Because of the desire for space
+optimization for large EPD files, halfmove clock values were dropped from EPD's
+parent FEN. The fullmove number information was similarly dropped.
+
+
+16.2.5.15: Opcode "id": position identification
+
+The opcode "id" is used to provide a simple identifying label for the indicated
+position. It takes a single string operand.
+
+This opcode is intended for use with test suites used for measuring
+chessplaying program strength. An example "id" operand for the seven hundred
+fifty seventh position of the one thousand one problems in Reinfeld's _1001
+Winning Chess Sacrifices and Combinations_ would be "WCSAC.0757" while the
+fifteenth position in the twenty four problem Bratko-Kopec test suite would
+have an "id" operand of "BK.15".
+
+
+16.2.5.16: Opcode "nic": _New In Chess_ opening code
+
+The opcode "nic" is used to associate an opening designation from the _New In
+Chess_ taxonomy with the indicated position. The opcode takes either a single
+string operand (the NIC opening name) or no operand at all. If an operand is
+present, its value is associated with an "NIC" string register of the scanning
+program. If there is no operand, the NIC string register of the scanning
+program is set to null.
+
+The usage is similar to that of the "NIC" tag pair of the PGN standard.
+
+
+16.2.5.17: Opcode "noop": no operation
+
+The "noop" opcode is used to indicate no operation. It takes zero or more
+operands, each of which may be of any type. The operation involves no
+processing. It is intended for use by developers for program testing purposes.
+
+
+16.2.5.18: Opcode "pm": predicted move
+
+The "pm" opcode is used to provide a single predicted move for the indicated
+position. It has exactly one operand, a move playable from the position. This
+move is judged by the EPD writer to represent the best move available to the
+active player.
+
+If a non-empty "pv" (predicted variation) line of play is also present in the
+same EPD record, the first move of the predicted variation is the same as the
+predicted move.
+
+The "pm" opcode is intended for use as a general "display hint" mechanism.
+
+
+16.2.5.19: Opcode "pv": predicted variation
+
+The "pv" opcode is used to provide a predicted variation for the indicated
+position. It has zero or more operands which represent a sequence of moves
+playable from the position. This sequence is judged by the EPD writer to
+represent the best play available.
+
+If a "pm" (predicted move) operation is also present in the same EPD record,
+the predicted move is the same as the first move of the predicted variation.
+
+
+16.2.5.20: Opcode "rc": repetition count
+
+The "rc" opcode is used to indicate the number of occurrences of the indicated
+position. It takes a single, positive integer operand. Any position,
+including the initial starting position, is considered to have an "rc" value of
+at least one. A value of three indicates a candidate for a draw claim by the
+position repetition rule.
+
+
+16.2.5.21: Opcode "resign": game resignation
+
+The opcode "resign" is used to indicate that the active player has resigned the
+game. This opcode takes no operands.
+
+
+16.2.5.22: Opcode "sm": supplied move
+
+The "sm" opcode is used to provide a single supplied move for the indicated
+position. It has exactly one operand, a move playable from the position. This
+move is the move to be played from the position.
+
+The "sm" opcode is intended for use to communicate the most recent played move
+in an active game. It is used to communicate moves between programs in
+automatic play via a network. This includes correspondence play using e-mail
+and also programs acting as network front ends to human players.
+
+
+16.2.5.23: Opcode "tcgs": telecommunication: game selector
+
+The "tcgs" opcode is one of the telecommunication family of opcodes used for
+games conducted via e-mail and similar means. This opcode takes a single
+operand that is a positive integer. It is used to select among various games
+in progress between the same sender and receiver.
+
+
+16.2.5.24: Opcode "tcri": telecommunication: receiver identification
+
+The "tcri" opcode is one of the telecommunication family of opcodes used for
+games conducted via e-mail and similar means. This opcode takes two order
+dependent string operands. The first operand is the e-mail address of the
+receiver of the EPD record. The second operand is the name of the player
+(program or human) at the address who is the actual receiver of the EPD record.
+
+
+16.2.5.25: Opcode "tcsi": telecommunication: sender identification
+
+The "tcsi" opcode is one of the telecommunication family of opcodes used for
+games conducted via e-mail and similar means. This opcode takes two order
+dependent string operands. The first operand is the e-mail address of the
+sender of the EPD record. The second operand is the name of the player
+(program or human) at the address who is the actual sender of the EPD record.
+
+
+16.2.5.26: Opcode "v0": variation name (primary, also "v1" though "v9")
+
+The opcode "v0" (lower case letter "v", digit character zero) indicates a top
+level variation name that applies to the given position. It is the first of
+ten ranked variation names, each of which has a mnemonic formed from the lower
+case letter "v" followed by a single decimal digit. Each of these opcodes
+takes either a single string operand or no operand at all.
+
+This ten member variation name family of opcodes is intended for use as
+traditional variation names for a complete game or game fragment. The usual
+processing of these opcodes are as follows:
+
+1) At the beginning of a game (or game fragment), a move sequence scanning
+program initializes each element of its set of ten variation name string
+registers to be null.
+
+2) As the EPD record for each position in the game is processed, the variation
+name operations are interpreted from left to right. (Actually, all operations
+in n EPD record are interpreted from left to right.) Because operations appear
+in ASCII order according to their opcode mnemonics, opcode "v0" (if present)
+will be handled prior to all other opcodes, then opcode "v1" (if present), and
+so forth until opcode "v9" (if present).
+
+3) The processing of opcode "vN" (0 <= N <= 9) involves two steps. First, all
+variation name string registers with an index equal to or greater than N are
+set to null. (This is the set "vN" though "v9".) Second, and only if a string
+operand is present, the value of the corresponding variation name string
+register is set equal to the string operand.
+
+
+17: Alternative chesspiece identifier letters
+
+English language piece names are used to define the letter set for identifying
+chesspieces in PGN movetext. However, authors of programs which are used only
+for local presentation or scanning of chess move data may find it convenient to
+use piece letter codes common in their locales. This is not a problem as long
+as PGN data that resides in archival storage or that is exchanged among
+programs still uses the SAN (English) piece letter codes: "PNBRQK".
+
+For the above authors only, a list of alternative piece letter codes are
+provided:
+
+Language Piece letters (pawn knight bishop rook queen king)
+---------- --------------------------------------------------
+Czech P J S V D K
+Danish B S L T D K
+Dutch O P L T D K
+English P N B R Q K
+Estonian P R O V L K
+Finnish P R L T D K
+French P C F T D R
+German B S L T D K
+Hungarian G H F B V K
+Icelandic P R B H D K
+Italian P C A T D R
+Norwegian B S L T D K
+Polish P S G W H K
+Portuguese P C B T D R
+Romanian P C N T D R
+Spanish P C A T D R
+Swedish B S L T D K
+
+
+18: Formal syntax
+
+<PGN-database> ::= <PGN-game> <PGN-database>
+ <empty>
+
+<PGN-game> ::= <tag-section> <movetext-section>
+
+<tag-section> ::= <tag-pair> <tag-section>
+ <empty>
+
+<tag-pair> ::= [ <tag-name> <tag-value> ]
+
+<tag-name> ::= <identifier>
+
+<tag-value> ::= <string>
+
+<movetext-section> ::= <element-sequence> <game-termination>
+
+<element-sequence> ::= <element> <element-sequence>
+ <recursive-variation> <element-sequence>
+ <empty>
+
+<element> ::= <move-number-indication>
+ <SAN-move>
+ <numeric-annotation-glyph>
+
+<recursive-variation> ::= ( <element-sequence> )
+
+<game-termination> ::= 1-0
+ 0-1
+ 1/2-1/2
+ *
+<empty> ::=
+
+
+19: Canonical chess position hash coding
+
+*** This section is under development.
+
+
+20: Binary representation (PGC)
+
+*** This section is under development.
+
+The binary coded version of PGN is PGC (PGN Game Coding). PGC is a binary
+representation standard of PGN data designed for the dual goals of storage
+efficiency and program I/O. A file containing PGC data should have a name with
+a suffix of ".pgc".
+
+Unlike PGN text files that may have locale dependent representations for
+newlines, PGC files have data that does not vary due to local processing
+environment. This means that PGC files may be transferred among systems using
+general binary file methods.
+
+PGC files should be used only when the use of PGN is impractical due to time
+and space resource constraints. As the general level of processing
+capabilities increases, the need for PGC over PGN will decrease. Therefore,
+implementors are encouraged not to use PGC as the default representation
+because it is much more difficult (than PGN) to understand without proper
+software.
+
+PGC data is composed of a sequence of PGC records. Each record is composed of
+a sequence of one or more bytes. The first byte is the PGN record marker and
+it specifies the interpretation of the remaining portion of the record. This
+remaining portion is composed of zero or more PGN record items. Item types
+include move sequences, move sets, and character strings.
+
+
+20.1: Bytes, words, and doublewords
+
+At the lowest level, PGC binary data is organized as bytes, words (two
+contiguous bytes), and doublewords (four contiguous bytes). All eight bits of
+a byte are used. Longwords (eight contiguous bytes) are not used. Integer
+values are stored using two's complement representation. Integers may be
+signed or unsigned depending on context. Multibyte integers are stored in
+low-endian format with the least significant byte appearing first.
+
+A one byte integer item is called "int-1". A two byte integer item is called
+"int-2". A four byte integer item is called "int-4".
+
+Characters are stored as bytes using the ISO 8859/1 Latin-1 (ECMA-94) code set.
+There is no provision for other characters sets or representations.
+
+
+20.2: Move ordinals
+
+A chess move is represented using a move ordinal. This is a single unsigned
+byte quantity with values from zero to 255. A move ordinal is interpreted as
+an index into the list of legal moves from the current position. This list is
+constructed by generating the legal moves from the current position, assigning
+SAN ASCII strings to each move, and then sorting these strings in ascending
+order. Note that a seven bit ordinal, as used by some inferior representation
+systems, is insufficient as there are some positions that have more than 128
+moves available.
+
+Examples: From the initial position, there are twenty moves. Move ordinal 0
+corresponds to the SAN move string "Na3"; move ordinal 1 corresponds to "Nc3",
+move ordinal 4 corresponds to "a3", and move ordinal 19 corresponds to "h4".
+
+Moves can be organized into sequences and sets. A move sequence is an ordered
+list of moves that are played, one after another from first to last. A move
+set is a list of moves that are all playable from the current position.
+
+Move sequence data is represented using a length header followed by move
+ordinal data. The length header is an unsigned integer that may be a byte or a
+word. The integer gives the number, possibly zero, of following move ordinal
+bytes. Most move sequences can be represented using just a byte header; these
+are called "mvseq-1" items. Move sequence data using a word header are called
+"mvseq-2" items.
+
+Move set data is represented using a length header followed by move ordinal
+data. The length header is an unsigned integer that is a byte. The integer
+gives the number, possibly zero, of following move ordinal bytes. All move
+sets are be represented using just a byte header; these are called "mvset-1"
+items. (Note the implied restriction that a move set can only have a maximum
+of 255 of the possible 256 ordinals present at one time.)
+
+
+20.3: String data
+
+PGC string data is represented using a length header followed by bytes of
+character data. The length header is an unsigned integer that may be a byte, a
+word, or a doubleword. The integer gives the number, possibly zero, of
+following character bytes. Most strings can be represented using just a byte
+header; these are called "string-1" items. String data using a word header are
+called "string-2" items and string data using a doubleword header are called
+"string-4" items. No special ASCII NUL termination byte is required for PGC
+storage of a string as the length is explicitly given in the item header.
+
+
+20.4: Marker codes
+
+PGC marker codes are given in hexadecimal format. PGC marker code zero (marker
+0x00) is the "noop" marker and carries no meaning. Each additional marker code
+defined appears in its own subsection below.
+
+
+20.4.1: Marker 0x01: reduced export format single game
+
+Marker 0x01 is used to indicate a single complete game in reduced export
+format. This refers to a game that has only the Seven Tag Roster data, played
+moves, and no annotations or comments. This record type is used as an
+alternative to the general game data begin/end record pairs described below.
+The general marker pair (0x05/0x06) is used to help represent game data that
+can't be adequately represented in reduced export format. There are eight
+items that follow marker 0x01 to form the "reduced export format single game"
+record. In order, these are:
+
+1) string-1 (Event tag value)
+
+2) string-1 (Site tag value)
+
+3) string-1 (Date tag value)
+
+4) string-1 (Round tag value)
+
+5) string-1 (White tag value)
+
+6) string-1 (Black tag value)
+
+7) string-1 (Result tag value)
+
+8) mvseq-2 (played moves)
+
+
+20.4.2: Marker 0x02: tag pair
+
+Marker 0x02 is used to indicate a single tag pair. There are two items that
+follow marker 0x02 to form the "tag pair" record; in order these are:
+
+1) string-1 (tag pair name)
+
+2) string-1 (tag pair value)
+
+
+20.4.3: Marker 0x03: short move sequence
+
+Marker 0x03 is used to indicate a short move sequence. There is one item that
+follows marker 0x03 to form the "short move sequence" record; this is:
+
+1) mvseq-1 (played moves)
+
+
+20.4.4: Marker 0x04: long move sequence
+
+Marker 0x04 is used to indicate a long move sequence. There is one item that
+follows marker 0x04 to form the "long move sequence" record; this is:
+
+1) mvseq-2 (played moves)
+
+
+20.4.5: Marker 0x05: general game data begin
+
+Marker 0x05 is used to indicate the beginning of data for a game. It has no
+associated items; it is a complete record by itself. Instead, it marks the
+beginning of PGC records used to describe a game. All records up to the
+corresponding "general game data end" record are considered to be part of the
+same game. (PGC record type 0x01, "reduced export format single game", is not
+permitted to appear within a general game begin/end record pair. The general
+game construct is to be used as an alternative to record type 0x01 in those
+cases where the latter is too restrictive to contain the data for a game.)
+
+
+20.4.6: Marker 0x06: general game data end
+
+Marker 0x06 is used to indicate the end of data for a game. It has no
+associated items; it is a complete record by itself. Instead, it marks the end
+of PGC records used to describe a game. All records after the corresponding
+(and earlier appearing) "general game data begin" record are considered to be
+part of the same game.
+
+
+20.4.7: Marker 0x07: simple-nag
+
+Marker 0x07 is used to indicate the presence of a simple NAG (Numeric
+Annotation Glyph). This is an annotation marker that has only a short type
+identification and no operands. There is one item that follows marker 0x07 to
+form the "simple-nag" record; this is:
+
+1) int-1 (unsigned NAG value, from 0 to 255)
+
+
+20.4.8: Marker 0x08: rav-begin
+
+Marker 0x08 is used to indicate the beginning of an RAV (Recursive Annotation
+Variation). It has no associated items; it is a complete record by itself.
+Instead, it marks the beginning of PGC records used to describe a recursive
+annotation. It is considered an opening bracket for a later rav-end record;
+the recursive annotation is completely described between the bracket pair. The
+rav-begin/data/rav-end structures can be nested.
+
+
+20.4.9: Marker 0x09: rav-end
+
+Marker 0x09 is used to indicate the end of an RAV (Recursive Annotation
+Variation). It has no associated items; it is a complete record by itself.
+Instead, it marks the end of PGC records used to describe a recursive
+annotation. It is considered a closing bracket for an earlier rav-begin
+record; the recursive annotation is completely described between the bracket
+pair. The rav-begin/data/rav-end structures can be nested.
+
+
+20.4.10: Marker 0x0a: escape-string
+
+Marker 0x0a is used to indicate the presence of an escape string. This is a
+string represented by the use of the percent sign ("%") escape mechanism in
+PGN. The data that is escaped is the sequence of characters immediately
+follwoing the percent sign up to but not including the terminating newline. As
+is the case with the PGN percent sign escape, the use of a PGC escape-string
+record is limited to use for non-archival data. There is one item that follows
+marker 0x0a to form the "escape-string" record; this is the string data being
+escaped:
+
+1) string-2 (escaped string data)
+
+
+21: E-mail correspondence usage
+
+*** This section is under development.
+
+
+Standard: EOF
diff --git a/examples/Aronian_vs_Anand_2013.01.15.pgn b/examples/Aronian_vs_Anand_2013.01.15.pgn
@@ -0,0 +1,12 @@
+[Event "75th Tata Steel GpA"]
+[Site "Wijk aan Zee NED"]
+[Date "2013.01.15"]
+[Round "?"]
+[White "Levon Aronian"]
+[Black "Viswanathan Anand"]
+[Result "0-1"]
+
+1. d4 d5 2. c4 c6 3. Nf3 Nf6 4. Nc3 e6 5. e3 Nbd7 6. Bd3 dxc4 7. Bxc4 b5 8. Bd3
+Bd6 9. O-O O-O 10. Qc2 Bb7 11. a3 Rc8 12. Ng5 c5 13. Nxh7 Ng4 14. f4 cxd4 15.
+exd4 Bc5 16. Be2 Nde5 17. Bxg4 Bxd4+ 18. Kh1 Nxg4 19. Nxf8 f5 20. Ng6 Qf6 21. h3
+Qxg6 22. Qe2 Qh5 23. Qd3 Be3 0-1
+\ No newline at end of file
diff --git a/examples/Bai_vs_Liren_2017.11.04.pgn b/examples/Bai_vs_Liren_2017.11.04.pgn
@@ -0,0 +1,18 @@
+[Event "Chinese Chess League"]
+[Site "China CHN"]
+[Date "2017.11.04"]
+[Round "18.4"]
+[White "Jinshi Bai"]
+[Black "Ding Liren"]
+[Result "0-1"]
+[EventDate "2017.04.18"]
+[ECO "E21"]
+[WhiteElo "2553"]
+[BlackElo "2774"]
+[PlyCount "64"]
+
+1. d4 Nf6 2. c4 e6 3. Nc3 Bb4 4. Nf3 O-O 5. Bg5 c5 6. e3 cxd4 7. Qxd4 Nc6 8. Qd3
+h6 9. Bh4 d5 10. Rd1 g5 11. Bg3 Ne4 12. Nd2 Nc5 13. Qc2 d4 14. Nf3 e5 15. Nxe5
+dxc3 16. Rxd8 cxb2+ 17. Ke2 Rxd8 18. Qxb2 Na4 19. Qc2 Nc3+ 20. Kf3 Rd4 21. h3 h5
+22. Bh2 g4+ 23. Kg3 Rd2 24. Qb3 Ne4+ 25. Kh4 Be7+ 26. Kxh5 Kg7 27. Bf4 Bf5 28.
+Bh6+ Kh7 29. Qxb7 Rxf2 30. Bg5 Rh8 31. Nxf7 Bg6+ 32. Kxg4 Ne5+ 0-1
+\ No newline at end of file
diff --git a/examples/Byrne_vs_Fischer_1956.pgn b/examples/Byrne_vs_Fischer_1956.pgn
@@ -0,0 +1,15 @@
+[Event "Memorial Rosenwald"]
+[Site "New York (USA)"]
+[Date "1956.??.??"]
+[Round "?"]
+[White "Donald Byrne"]
+[Black "Bobby Fischer"]
+[Result "0-1"]
+
+1. Nf3 Nf6 2. c4 g6 3. Nc3 Bg7 4. d4 O-O 5. Bf4 d5 6. Qb3 dxc4 7. Qxc4 c6 8. e4
+Nbd7 9. Rd1 Nb6 10. Qc5 Bg4 11. Bg5 Na4 12. Qa3 Nxc3 13. bxc3 Nxe4 14. Bxe7 Qb6
+15. Bc4 Nxc3 16. Bc5 Rfe8+ 17. Kf1 Be6 18. Bxb6 Bxc4+ 19. Kg1 Ne2+ 20. Kf1 Nxd4+
+21. Kg1 Ne2+ 22. Kf1 Nc3+ 23. Kg1 axb6 24. Qb4 Ra4 25. Qxb6 Nxd1 26. h3 Rxa2 27.
+Kh2 Nxf2 28. Re1 Rxe1 29. Qd8+ Bf8 30. Nxe1 Bd5 31. Nf3 Ne4 32. Qb8 b5 33. h4 h5
+34. Ne5 Kg7 35. Kg1 Bc5+ 36. Kf1 Ng3+ 37. Ke1 Bb4+ 38. Kd1 Bb3+ 39. Kc1 Ne2+ 40.
+Kb1 Nc3+ 41. Kc1 Rc2# 0-1
+\ No newline at end of file
diff --git a/examples/Geller_vs_Euwe_1953.pgn b/examples/Geller_vs_Euwe_1953.pgn
@@ -0,0 +1,12 @@
+[Event "Tournament (candidates)"]
+[Site "Zurich (Switzerland)"]
+[Date "1953.??.??"]
+[Round "?"]
+[White "Efim P Geller"]
+[Black "Max Euwe"]
+[Result "0-1"]
+
+1. d4 Nf6 2. c4 e6 3. Nc3 Bb4 4. e3 c5 5. a3 Bxc3+ 6. bxc3 b6 7. Bd3 Bb7 8. f3
+Nc6 9. Ne2 O-O 10. O-O Na5 11. e4 Ne8 12. Ng3 cxd4 13. cxd4 Rc8 14. f4 Nxc4 15.
+f5 f6 16. Rf4 b5 17. Rh4 Qb6 18. e5 Nxe5 19. fxe6 Nxd3 20. Qxd3 Qxe6 21. Qxh7+
+Kf7 22. Bh6 Rh8 23. Qxh8 Rc2 24. Rc1 Rxg2+ 25. Kf1 Qb3 26. Ke1 Qf3 0-1
+\ No newline at end of file
diff --git a/examples/Ivanchuk_vs_Yusupov_1991.pgn b/examples/Ivanchuk_vs_Yusupov_1991.pgn
@@ -0,0 +1,14 @@
+[Event "Ch World (match) (cand.) (1/4)"]
+[Site "Brussels (Belgium)"]
+[Date "1991.??.??"]
+[Round "?"]
+[White "Vassily Ivanchuk"]
+[Black "Artur Yusupov"]
+[Result "0-1"]
+
+1. c4 e5 2. g3 d6 3. Bg2 g6 4. d4 Nd7 5. Nc3 Bg7 6. Nf3 Ngf6 7. O-O O-O 8. Qc2
+Re8 9. Rd1 c6 10. b3 Qe7 11. Ba3 e4 12. Ng5 e3 13. f4 Nf8 14. b4 Bf5 15. Qb3 h6
+16. Nf3 Ng4 17. b5 g5 18. bxc6 bxc6 19. Ne5 gxf4 20. Nxc6 Qg5 21. Bxd6 Ng6 22.
+Nd5 Qh5 23. h4 Nxh4 24. gxh4 Qxh4 25. Nde7+ Kh8 26. Nxf5 Qh2+ 27. Kf1 Re6 28.
+Qb7 Rg6 29. Qxa8+ Kh7 30. Qg8+ Kxg8 31. Nce7+ Kh7 32. Nxg6 fxg6 33. Nxg7 Nf2 34.
+Bxf4 Qxf4 35. Ne6 Qh2 36. Rdb1 Nh3 37. Rb7+ Kh8 38. Rb8+ Qxb8 39. Bxh3 Qg3 0-1
+\ No newline at end of file
diff --git a/examples/Karpov_vs_Kasparov_1985.pgn b/examples/Karpov_vs_Kasparov_1985.pgn
@@ -0,0 +1,14 @@
+[Event "Ch World (match)"]
+[Site "Moscow (Russia)"]
+[Date "1985.??.??"]
+[Round "?"]
+[White "Anatoly Karpov"]
+[Black "Garry Kasparov"]
+[Result "0-1"]
+
+1. e4 c5 2. Nf3 e6 3. d4 cxd4 4. Nxd4 Nc6 5. Nb5 d6 6. c4 Nf6 7. N1c3 a6 8. Na3
+d5 9. cxd5 exd5 10. exd5 Nb4 11. Be2 Bc5 12. O-O O-O 13. Bf3 Bf5 14. Bg5 Re8 15.
+Qd2 b5 16. Rad1 Nd3 17. Nab1 h6 18. Bh4 b4 19. Na4 Bd6 20. Bg3 Rc8 21. b3 g5 22.
+Bxd6 Qxd6 23. g3 Nd7 24. Bg2 Qf6 25. a3 a5 26. axb4 axb4 27. Qa2 Bg6 28. d6 g4
+29. Qd2 Kg7 30. f3 Qxd6 31. fxg4 Qd4+ 32. Kh1 Nf6 33. Rf4 Ne4 34. Qxd3 Nf2+ 35.
+Rxf2 Bxd3 36. Rfd2 Qe3 37. Rxd3 Rc1 38. Nb2 Qf2 39. Nd2 Rxd1+ 40. Nxd1 Re1+ 0-1
+\ No newline at end of file
diff --git a/examples/Kasparov_vs_Topalov_1999.pgn b/examples/Kasparov_vs_Topalov_1999.pgn
@@ -0,0 +1,15 @@
+[Event "It (cat.17)"]
+[Site "Wijk aan Zee (Netherlands)"]
+[Date "1999.??.??"]
+[Round "?"]
+[White "Garry Kasparov"]
+[Black "Veselin Topalov"]
+[Result "1-0"]
+
+1. e4 d6 2. d4 Nf6 3. Nc3 g6 4. Be3 Bg7 5. Qd2 c6 6. f3 b5 7. Nge2 Nbd7 8. Bh6
+Bxh6 9. Qxh6 Bb7 10. a3 e5 11. O-O-O Qe7 12. Kb1 a6 13. Nc1 O-O-O 14. Nb3 exd4
+15. Rxd4 c5 16. Rd1 Nb6 17. g3 Kb8 18. Na5 Ba8 19. Bh3 d5 20. Qf4+ Ka7 21. Rhe1
+d4 22. Nd5 Nbxd5 23. exd5 Qd6 24. Rxd4 cxd4 25. Re7+ Kb6 26. Qxd4+ Kxa5 27. b4+
+Ka4 28. Qc3 Qxd5 29. Ra7 Bb7 30. Rxb7 Qc4 31. Qxf6 Kxa3 32. Qxa6+ Kxb4 33. c3+
+Kxc3 34. Qa1+ Kd2 35. Qb2+ Kd1 36. Bf1 Rd2 37. Rd7 Rxd7 38. Bxc4 bxc4 39. Qxh8
+Rd3 40. Qa8 c3 41. Qa4+ Ke1 42. f4 f5 43. Kc1 Rd2 44. Qa7 1-0
+\ No newline at end of file
diff --git a/examples/Morphy_vs_Duke_of_Brunswick_and_Count_Isouard_1858.pgn b/examples/Morphy_vs_Duke_of_Brunswick_and_Count_Isouard_1858.pgn
@@ -0,0 +1,11 @@
+[Event "Paul Morphy - Duke Karl Count Isouard (1858.??.??)"]
+[Site "Paris (France)"]
+[Date "1858.??.??"]
+[Round "?"]
+[White "Paul Morphy"]
+[Black "Duke of Brunswick and Count Isouard"]
+[Result "1-0"]
+
+1. e4 e5 2. Nf3 d6 3. d4 Bg4 4. dxe5 Bxf3 5. Qxf3 dxe5 6. Bc4 Nf6 7. Qb3 Qe7 8.
+Nc3 c6 9. Bg5 b5 10. Nxb5 cxb5 11. Bxb5+ Nbd7 12. O-O-O Rd8 13. Rxd7 Rxd7 14.
+Rd1 Qe6 15. Bxd7+ Nxd7 16. Qb8+ Nxb8 17. Rd8# 1-0
+\ No newline at end of file
diff --git a/examples/Rotlevi_vs_Rubinstein_1907.pgn b/examples/Rotlevi_vs_Rubinstein_1907.pgn
@@ -0,0 +1,12 @@
+[Event "Ch Russia"]
+[Site "Lodz (Poland)"]
+[Date "1907.??.??"]
+[Round "?"]
+[White "Georg Rotlevi"]
+[Black "Akiba Rubinstein"]
+[Result "0-1"]
+
+1. d4 d5 2. Nf3 e6 3. e3 c5 4. c4 Nc6 5. Nc3 Nf6 6. dxc5 Bxc5 7. a3 a6 8. b4 Bd6
+9. Bb2 O-O 10. Qd2 Qe7 11. Bd3 dxc4 12. Bxc4 b5 13. Bd3 Rd8 14. Qe2 Bb7 15. O-O
+Ne5 16. Nxe5 Bxe5 17. f4 Bc7 18. e4 Rac8 19. e5 Bb6+ 20. Kh1 Ng4 21. Be4 Qh4 22.
+g3 Rxc3 23. gxh4 Rd2 24. Qxd2 Bxe4+ 25. Qg2 Rh3 0-1
+\ No newline at end of file
diff --git a/examples/Short_vs_Timman_1991.pgn b/examples/Short_vs_Timman_1991.pgn
@@ -0,0 +1,14 @@
+[Event "It (cat.17)"]
+[Site "Tilburg (Netherlands)"]
+[Date "1991.??.??"]
+[Round "?"]
+[White "Nigel D Short"]
+[Black "Jan H Timman"]
+[Result "1-0"]
+
+1. e4 Nf6 2. e5 Nd5 3. d4 d6 4. Nf3 g6 5. Bc4 Nb6 6. Bb3 Bg7 7. Qe2 Nc6 8. O-O
+O-O 9. h3 a5 10. a4 dxe5 11. dxe5 Nd4 12. Nxd4 Qxd4 13. Re1 e6 14. Nd2 Nd5 15.
+Nf3 Qc5 16. Qe4 Qb4 17. Bc4 Nb6 18. b3 Nxc4 19. bxc4 Re8 20. Rd1 Qc5 21. Qh4 b6
+22. Be3 Qc6 23. Bh6 Bh8 24. Rd8 Bb7 25. Rad1 Bg7 26. R8d7 Rf8 27. Bxg7 Kxg7 28.
+R1d4 Rae8 29. Qf6+ Kg8 30. h4 h5 31. Kh2 Rc8 32. Kg3 Rce8 33. Kf4 Bc8 34. Kg5
+1-0
+\ No newline at end of file
diff --git a/examples/fischer_spassky_1992.pgn b/examples/fischer_spassky_1992.pgn
@@ -0,0 +1,16 @@
+[Event "F/S Return Match"]
+[Site "Belgrade, Serbia JUG"]
+[Date "1992.11.04"]
+[Round "29"]
+[White "Fischer, Robert J."]
+[Black "Spassky, Boris V."]
+[Result "1/2-1/2"]
+
+1. e4 e5 2. Nf3 Nc6 3. Bb5 a6 {This opening is called the Ruy Lopez.}
+4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8. c3 O-O 9. h3 Nb8 10. d4 Nbd7
+11. c4 c6 12. cxb5 axb5 13. Nc3 Bb7 14. Bg5 b4 15. Nb1 h6 16. Bh4 c5 17. dxe5
+Nxe4 18. Bxe7 Qxe7 19. exd6 Qf6 20. Nbd2 Nxd6 21. Nc4 Nxc4 22. Bxc4 Nb6
+23. Ne5 Rae8 24. Bxf7+ Rxf7 25. Nxf7 Rxe1+ 26. Qxe1 Kxf7 27. Qe3 Qg5 28. Qxg5
+hxg5 29. b3 Ke6 30. a3 Kd6 31. axb4 cxb4 32. Ra5 Nd5 33. f3 Bc8 34. Kf2 Bf5
+35. Ra7 g6 36. Ra6+ Kc5 37. Ke1 Nf4 38. g3 Nxh3 39. Kd2 Kb5 40. Rd6 Kc5 41. Ra6
+Nf2 42. g4 Bd3 43. Re6 1/2-1/2
