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