diff --git a/_assets/vendor/pgn4web/CarlsenSvidler2010.pgn b/_assets/vendor/pgn4web/CarlsenSvidler2010.pgn
new file mode 100644
index 0000000..204812c
--- /dev/null
+++ b/_assets/vendor/pgn4web/CarlsenSvidler2010.pgn
@@ -0,0 +1,88 @@
+[Event "Wch Blitz"]
+[Site "Moscow RUS"]
+[Date "2010.11.18"]
+[Round "30"]
+[White "Carlsen, Magnus"]
+[Black "Svidler, Peter"]
+[Result "1-0"]
+[SetUp "1"]
+[FEN "8/6k1/1R6/p2pBnP1/8/8/r7/6K1 b - - 6 62"]
+[VideoTime "0.6"]
+
+{ associated video originally from http://www.youtube.com/watch?v=HY3SM3GKjd8 }
+
+62... Kh7 {[%vt 3.5]}
+63. g6 {[%vt 4.3]}
+63... Kh6 {[%vt 5.7]}
+64. g7 {[%vt 6.4]}
+64... Kh7 {[%vt 7.2]}
+65. Rb8 {[%vt 7.8]}
+65... Nxg7 {[%vt 10.1]}
+66. Rb7 {[%vt 10.9]}
+66... Kg6 {[%vt 11.9]}
+67. Rxg7 {[%vt 12.5]}
+67... Kf5 {[%vt 14.1]}
+68. Bd6 {[%vt 16.2]}
+68... d4 {[%vt 17.1]}
+69. Kf1 {[%vt 18.1]}
+69... Ke4 {[%vt 18.8]}
+70. Ke1 {[%vt 20.1]}
+70... a4 {[%vt 21.3]}
+71. Rg3 {[%vt 22.6]}
+71... d3 {[%vt 23.3]}
+72. Kd1 {[%vt 25.6]}
+72... a3 {[%vt 27.6]}
+73. Rg4 {[%vt 28.4]}
+73... Kf3 {[%vt 30.3]}
+74. Ra4 {[%vt 31.2]}
+74... Ra1 {[%vt 34.6]}
+75. Kd2 {[%vt 35.6]}
+75... a2 {[%vt 36.7]}
+76. Be5 {[%vt 37.5]}
+76... Rh1 {[%vt 41.8]}
+77. Kxd3 {[%vt 46.7]}
+77... Rd1 {[%vt 47.7]}
+78. Kc2 {[%vt 49.4]}
+78... Rd5 {[%vt 50.6]}
+79. Bc3 {[%vt 51.9]}
+79... Rd8 {[%vt 54.9]}
+80. Rxa2 {[%vt 55.7]}
+80... Ke4 {[%vt 56.6]}
+81. Ra4 {[%vt 57.4]}
+81... Kf5 {[%vt 58.3]}
+82. Bd4 {[%vt 59.2]}
+82... Rd7 {[%vt 60.6]}
+83. Kd3 {[%vt 61.4]}
+83... Rd8 {[%vt 62.2]}
+84. Ra5 {[%vt 63.2]}
+84... Kf4 {[%vt 65]}
+85. Ra6 {[%vt 66.4]}
+85... Kg5 {[%vt 74.9]}
+86. Ke4 {[%vt 75.7]}
+86... Rb8 {[%vt 79.4]}
+87. Ra7 {[%vt 83.5]}
+87... Rb4 {[%vt 84.8]}
+88. Rg7 {[%vt 85.8]}
+88... Kh4 {[%vt 87.5]}
+89. Rg8 {[%vt 89.3]}
+89... Ra4 {[%vt 90.2]}
+90. Ke5 {[%vt 93]}
+90... Kh3 {[%vt 94.4]}
+91. Be3 {[%vt 95.8]}
+91... Rb4 {[%vt 98.4]}
+92. Kf5 {[%vt 99.7]}
+92... Ra4 {[%vt 110]}
+93. Bf4 {[%vt 110.8]}
+93... Ra3 {[%vt 113.7]}
+94. Bd6 {[%vt 120.8]}
+94... Ra4 {[%vt 121.9]}
+95. Rg3 {[%vt 123.9]}
+95... Kh4 {[%vt 124.7]}
+96. Rg2 {[%vt 127]}
+96... Kh5 {[%vt 131.7]}
+97. Rg8 {[%vt 137.4]}
+97... Kh6 {[%vt 142.3]}
+98. Be5 {[%vt 144.1]}
+98... Ra7 {[%vt 145.7]}
+99. Rg1 {[%vt 149.4]}
+1-0
diff --git a/_assets/vendor/pgn4web/KrushKosteniuk2010.pgn b/_assets/vendor/pgn4web/KrushKosteniuk2010.pgn
new file mode 100644
index 0000000..563a1ca
--- /dev/null
+++ b/_assets/vendor/pgn4web/KrushKosteniuk2010.pgn
@@ -0,0 +1,95 @@
+[Event "WCh Women Blitz"]
+[Site "Moscow RUS"]
+[Date "2010.09.18"]
+[Round "30"]
+[White "Krush, Irina"]
+[Black "Kosteniuk, Alexandra"]
+[Result "0-1"]
+[TimeControl "180+2"]
+[WhiteClock "3.02"]
+[BlackClock "3.02"]
+[VideoTime "2"]
+
+{ associated video originally from http://www.youtube.com/watch?v=EUEypIgynsk }
+
+1. d4 {[%vt 18.6] [%clk 3.03]}
+1... Nf6 {[%vt 19.4] [%clk 3.03]}
+2. c4 {[%vt 20.1] [%clk 3.04]}
+2... e6 {[%vt 20.7] [%clk 3.05]}
+3. Nc3 {[%vt 21.3] [%clk 3.03]}
+3... Bb4 {[%vt 22.6] [%clk 3.06]}
+4. Qc2 {[%vt 23.3] [%clk 3.05]}
+4... d5 {[%vt 24.2] [%clk 3.08]}
+5. cxd5 {[%vt 25.2] [%clk 3.07]}
+5... exd5 {[%vt 25.9] [%clk 3.09]}
+6. Bg5 {[%vt 27.4] [%clk 3.08]}
+6... h6 {[%vt 28.5] [%clk 3.10]}
+7. Bh4 {[%vt 29.1] [%clk 3.08]}
+7... g5 {[%vt 29.6] [%clk 3.12]}
+8. Bg3 {[%vt 30.5] [%clk 3.10]}
+8... Ne4 {[%vt 31.6] [%clk 3.13]}
+9. e3 {[%vt 32.4] [%clk 3.11]}
+9... h5 {[%vt 34.3] [%clk 3.13]}
+10. a3 {[%vt 36.8] [%clk 3.10]}
+10... Bxc3 {[%vt 51.8] [%clk 3.00]}
+11. bxc3 {[%vt 53.3] [%clk 3.11]}
+11... Bf5 {[%vt 92.1] [%clk 2.23]}
+12. Bd3 {[%vt 96.3] [%clk 3.08]}
+12... Nd7 {[%vt 108.5] [%clk 2.13]}
+13. f3 {[%vt 119.5] [%clk 2.59]}
+13... Nxg3 {[%vt 121.5] [%clk 2.13]}
+14. hxg3 {[%vt 122.6] [%clk 3.00]}
+14... Bxd3 {[%vt 124.5] [%clk 2.13]}
+15. Qxd3 {[%vt 125.9] [%clk 3.00]}
+15... Qf6 {[%vt 127.9] [%clk 2.14]}
+16. Ne2 {[%vt 137] [%clk 2.52]}
+16... O-O-O {[%vt 138.9] [%clk 2.14]}
+17. c4 {[%vt 147.6] [%clk 2.47]}
+17... dxc4 {[%vt 166.3] [%clk 1.57]}
+18. Qxc4 {[%vt 169.6] [%clk 2.45]}
+18... Nb6 {[%vt 170.4] [%clk 1.58]}
+19. Qb3 {[%vt 180] [%clk 2.38]}
+19... h4 {[%vt 191.9] [%clk 1.48]}
+20. Kf2 {[%vt 204.4] [%clk 2.27]}
+20... hxg3 {[%vt 215.1] [%clk 1.40]}
+21. Nxg3 {[%vt 219.5] [%clk 2.24]}
+21... Qg6 {[%vt 224.2] [%clk 1.38]}
+22. a4 {[%vt 271.8] [%clk 1.39]}
+22... f5 {[%vt 276.4] [%clk 1.35]}
+23. Qc2 {[%vt 287.7] [%clk 1.29]}
+23... Rhf8 {[%vt 296.7] [%clk 1.28]}
+24. a5 {[%vt 308.5] [%clk 1.19]}
+24... Nd5 {[%vt 309.1] [%clk 1.30]}
+25. a6 {[%vt 320.8] [%clk 1.10]}
+25... b6 {[%vt 321.6] [%clk 1.31]}
+26. Rac1 {[%vt 327.8] [%clk 1.06]}
+26... Qe6 {[%vt 338.2] [%clk 1.22]}
+27. Rhe1 {[%vt 363.2] [%clk 0.43]}
+27... Rd7 {[%vt 365] [%clk 1.22]}
+28. e4 {[%vt 376] [%clk 0.34]}
+28... fxe4 {[%vt 392.1] [%clk 1.08]}
+29. Nxe4 {[%vt 393] [%clk 0.34]}
+29... Nb4 {[%vt 400.2] [%clk 1.04]}
+30. Qc3 {[%vt 407.9] [%clk 0.29]}
+30... Nxa6 {[%vt 416.1] [%clk 0.57]}
+31. Nc5 {[%vt 420.8] [%clk 0.26]}
+31... Qd5 {[%vt 432] [%clk 0.48]}
+32. Nxd7 {[%vt 446.5] [%clk 0.13]}
+32... Qxd7 {[%vt 448] [%clk 0.49]}
+33. Qa3 {[%vt 451.4] [%clk 0.12]}
+33... Qxd4 {[%vt 452.3] [%clk 0.49]}
+34. Kf1 {[%vt 456.6] [%clk 0.10]}
+34... Nc5 {[%vt 464.2] [%clk 0.44]}
+35. Qxa7 {[%vt 465.8] [%clk 0.10]}
+35... Qd3 {[%vt 471.3] [%clk 0.40]}
+36. Re2 {[%vt 473.9] [%clk 0.10]}
+36... Kd7 {[%vt 492.1] [%clk 0.25]}
+37. Qa2 {[%vt 496.7] [%clk 0.07]}
+37... g4 {[%vt 499] [%clk 0.24]}
+38. Kg1 {[%vt 503.9] [%clk 0.04]}
+38... Qd4 {[%vt 505.8] [%clk 0.24]}
+39. Kh2 {[%vt 509] [%clk 0.03]}
+39... Qf4 {[%vt 510.3] [%clk 0.25]}
+40. Kg1 {[%vt 510.9] [%clk 0.02]}
+40... Qxc1 {[%vt 511.5] [%clk 0.26]}
+0-1
diff --git a/_assets/vendor/pgn4web/README.txt b/_assets/vendor/pgn4web/README.txt
new file mode 100644
index 0000000..1dfba3a
--- /dev/null
+++ b/_assets/vendor/pgn4web/README.txt
@@ -0,0 +1,532 @@
+#
+# pgn4web javascript chessboard
+# copyright (C) 2009-2013 Paolo Casaschi
+# see README file and http://pgn4web.casaschi.net
+# for credits, license and more details
+#
+
+
+PGN4WEB: javascript chess games viewer for websites, blogs and live broadcasts.
+
+
+ABOUT
+
+pgn4web comes as software package you can add to your website or blogsite, but
+also provides a very simple board generator web tool helping you adding chess
+games to your website or blog without any html/javascript coding.
+pgn4web integrates with several popular web platforms and services.
+
+***
+*** THIS README FILE IS A SUMMARY OF THE PGN4WEB DOCUMENTATION
+*** MORE EXTENSIVE AND UPDATED DOCUMENTATION IS AVAILABLE
+*** FROM THE PGN4WEB SUPPORT WIKI REACHABLE FROM http://pgn4web.casaschi.net
+*** PLEASE RELY ON THE SUPPORT WIKI RATHER THAN THIS README ONLY
+***
+
+Project homepage: http://pgn4web.casaschi.net (including downloads and wiki)
+Contact email: pgn4web@casaschi.net
+
+Features:
+- display chess games form PGN files on websites and blogs
+- supports live broadcasts of chess games
+- interactive browsing of game variations and comments
+- shortcut keys for navigating through the game, for selecting games and much
+ more; uses chessboard squares as input buttons; on supported touchscreen
+ devices uses touch gestures across the chessboard
+- fully customizable display: each item (board, button bar, game selection
+ menu, PGN header info, game text, game comment and more) can be displayed
+ (or hidden) at pleasure in your html file
+- support different bitmaps for chess pieces (even custom bitmaps) and
+ different chessboard sizes
+- uses figurine fonts for chess moves and chess informant style symbols for
+ comments and annotations
+- provides a very simple board generator web tool helping you adding chess
+ games to your website or blog without any html/javascript coding (see
+ http://pgn4web-board-generator.casaschi.net
+- integrated with popular blog platforms (such as blogger and wordpress),
+ portal platforms (such as joomla, drupal and wikimedia), forum platforms
+ (such as phpBB, simplemachines and vbulletin) and hosting services (such
+ as google sites)
+- integrated with HTML5 video and YouTube video
+- supports Chess960 (a.k.a. Fischer random chess) games
+
+Limitations:
+- only one chessboard for html file (use frames if you need to display
+ more in the same view)
+
+Bugs:
+- no major issue at the moment of writing, please check the project
+ issues tracker at http://code.google.com/p/pgn4web/issues/list
+
+User feedback:
+Please email the pgn4web project (pgn4web@casaschi.net) your feedback,
+suggestions and bug reports. Please send for review any PGN file that
+pgn4web fails parsing correctly.
+
+Enjoy!
+
+
+DEBUGGING
+
+Errors alert messages are logged by pgn4web, such as failure to load PGN
+data, incorrect PGN games or incorrect FEN strings.
+When an error is encountered, the top left chessboard square will flash
+to signal the exception.
+The error alert log can be reviewed clicking on the same top left
+chessboard square.
+
+
+HOW TO USE pgn4we.js
+
+To enable pgn4web, add a SCRIPT instance at the top of your HTML file:
+
+
+
+The PGN input can be specified either as URL within another SCRIPT instance
+with at least the call to
+
+ SetPgnUrl("http://yoursite/yourpath/yourfile.pgn")
+
+and optionally any of the other calls listed below.
+
+Or the PGN file can be pasted in the body of the HTML file
+within a hidden FORM/TEXTAREA statement with the ID pgnText:
+
+
+
+
+
+Example:
+
+
+
+
+Please note, differently than when using the figurine fonts, if the user's web
+browser does not support web fonts, there's not elegant textual fallback.
+
+See the chess-informant-template.html and the collection-example.thml (chess
+informant sample) files for an example.
+
+
+THE BOARD GENERATOR WEB TOOL
+
+The board widget allows showing games and positions in web pages and blogs,
+without any html coding for each game, where the chessboard widget is created
+using a given HTML code within the web page or blog.
+
+Just go to the board widget generator site on
+ http://pgn4web-board-generator.casaschi.net
+the enter your PGN games and configure the options. The tool will
+automatically generate some HTML code that you can cut and paste in your web
+page or your blog.
+
+
+THE LIVE BROADCAST OF GAMES
+
+By setting the SetLiveBroadcast(delay, alertFlag, demoFlag, stepFlag) option
+in the HTML file, pgn4web will periodically refresh the PGN file, showing the
+live progress of the games. PGN files produced by the DGT chessboards are
+supported.
+
+SetLiveBroadcast(delay, alertFlag, demoFlag, stepFlag) parameters:
+ - delay = refresh interval in minutes, decimals allowed (default 1)
+ - alertFlag = if set true, shows alert debug messages (default false)
+ - demoFlag = if set true, sets live demo mode (default false)
+ - stepFlag = if set true, autoplays updates in steps (default false)
+
+If you set stepFlag, please note that the autoplay delay is set by
+SetAutoplayDelay(delay), where no more than 2000ms should be used for live
+broadcasts.
+
+The bash shell script live-grab.sh, executed on your server allows for grabbing
+the updated game source from anywhere on the Internet to your server.
+The live broadcast stops refreshing once all games are ended.
+
+Clock information as provided by the DGT chessboards in PGN move comments, such
+as {[%clk 1:59:59]}, and in the PGN header, such as [WhiteClock "2:00:00"],
+[BlackClock "2:00:00"] and [Clock "W/1:59:59"] is displayed in the following
+sections:
+
+
+
+
+The status of the live broadcast is displayed in the following sections:
+
+
+
+
+
+
+Clicking on the H6 square will force a games refresh.
+Clicking on the A6/B6 squares will pause/restart the automatic games refresh.
+
+The file live-template.html shows a very basic example.
+
+A demo facility is available to test the live broadcast functionality.
+If the demo flag is set in SetLiveBroadcast() and a set of full games is
+provided, the tool will simulate a slow progress of the game. Set the
+proper flag in live-template.html for an example. Please note, even during
+a demo, the PGN file is actually refreshed from the server for a more
+accurate testing.
+Alternatively, for a more realistic simulation, the bash shell script
+live-simulation.sh slowly updates the live.pgn file, simulating a real event.
+
+The easiest way to setup a live broadcast is to use the live-compact.html file.
+The HTML file accepts these parameters:
+ - pgnFile = PGN file to load (default live.pgn)
+ - initialGame = initial game, a number or first, last, random (default 1)
+ - refreshMinutes = refresh interval in minutes, decimals allowed (default 1)
+ - demo = if set true, sets live demo mode (default false)
+For instance, make sure that the file myGames.pgn on your server is periodically
+refreshed with the live games, then add the following iframe to your page:
+
+Of course live-compact.html can be edited to customize colors, layout and every
+detail.
+
+The live-mosaic.html file has been designed in a similar way, while offering
+a layout with multiple live boards on the same page.
+
+http://pgn4web.casaschi.net/live/live.html and
+http://pgn4web.casaschi.net/live/live-mosaic.html will occasionally broadcast
+live major chess events.
+
+
+CUSTOMIZATION FUNCTIONS
+
+The following functions, if defined in the HTML file after loading pgn4web.js,
+allow for execution of custom commands at given points:
+- customFunctionOnPgnTextLoad(): when loading a new PGN file
+- customFunctionOnPgnGameLoad(): when loading a new game
+- customFunctionOnMove(): when a move is made
+- customFunctionOnAlert(message_string): when an error alert is raised
+- customFunctionOnCheckLiveBroadcastStatus(): when a live broadcast is checked
+Please note the order these functions are executed; for example, when loading
+a new PGN file at the end of the first game, first customFunctionOnMove() is
+executed, then (when the game has been loaded and the move positioning
+completed) customFunctionOnPgnGameLoad() is executed and finally (when the
+selected game is fully loaded) customFunctionOnPgnTextLoad() is executed.
+
+The function customPgnHeaderTag(customTagString, htmlElementIdString, gameNumber)
+is available for use in customFunctionOnPgnGameLoad() to parse custom PGN header
+tags and automatically assign their value to the given HTML elements. The function
+returns the custom tag value and the `gameNumber` parameter, if unassigned,
+defaults to the current game.
+The function customPgnCommentTag(customTagString, htmlElementIdString, plyNumber)
+is available for use in customFunctionOnMove() to parse custom PGN comment tags
+like { [%pgn4web info] } and automatically assign their value to the given HTML
+elements. The function returns the custom tag value and the `plyNumber` parameter,
+if unassigned, defaults to the current ply.
+
+See twic944.html or live.html for examples.
+
+The following functions, if defined in the HTML file after loading pgn4web.js,
+allow for execution of custom commands when shift + a number key is pressed:
+- customShortcutKey_Shift_0()
+- customShortcutKey_Shift_1()
+...
+- customShortcutKey_Shift_9()
+
+
+SHORTCUT KEYS AND TEXT FORMS
+
+When the HTML page contains the following script command
+
+ SetShortcutKeysEnabled(true);
+
+then all keystrokes for that active page are captured and processed by pgn4web;
+this allows for instance to browse the game using the arrow keys. If no other
+precautions are taken, this has also the undesirable side effect of capturing
+keystrokes intended by the user for typing in text forms when present in the
+same page: this makes the text forms unusable.
+
+In order to have fully functional text forms in pgn4web pages, the following
+"onFocus" and "onBlur" actions should be added to the textarea forms:
+
+
+
+See the inputform.html HTML file for an example.
+
+
+TECHNICAL NOTES ABOUT WEB BROWSERS
+
+pgn4web is developed and tested with recent versions of a variety of
+browsers (Arora, Blackberry browser, Chrome, Epiphany, Firefox, Internet
+Explorer, Opera, Safari) on a variety of personal computer platforms
+(Linux/Debian, MacOS, Windows) and some smartphone/pda platform (Android,
+Blackberry, Apple iOS for iPhone/iPad/iPod).
+Not every browser version (please upgrade to a recent release) has been
+tested and not every combination of browser/platform has been validated.
+If you have any issue with using pgn4web on your platform, please email
+pgn4web@casaschi.net
+
+Note about Google Chrome: you might experience problems when testing HTML
+pages from your local computer while developing your site. This is a
+security limitation of the browser with respect to loading local files.
+The limitation can be bypassed by starting Google Chrome with the command
+line switch '--allow-file-access-from-files'. Browsing pgn4web websites
+with Google Chrome should work properly.
+
+Note about Internet Explorer v7 and above: under some circumstances you might
+experience problems when testing HTML pages from your local computer while
+developing your site. If this happens to you, read notes at
+http://code.google.com/p/pgn4web/issues/detail?id=23
+
+
+PGN STANDARD SUPPORT
+
+pgn4web mostly supports the PGN standard for chess games notation (see
+http://www.tim-mann.org/Standard). Notable exceptions and limitations:
+
+- variations are not parsed as such, but stored as comments; support for
+browsing variations is planned for a future release
+- if square brackets are present in the comments (or the game text) in a
+pattern similar to the PGN header pattern '[tag "value"]' then the game
+parsing might break. If your PGN file is not displayed properly, please
+check for characters "[" and "]" in the comments and try removing them.
+- only pieces initials in the English language are supported, the use of
+alternative languages as specified by the PGN standard is not supported
+(pgn4web can however display chess moves text using figurine notation, so
+the language issue should not be much of a problem, just make sure your
+chess software produces PGN data with English pieces initials).
+
+pgn4web also follows a set of proposed extensions to the PGN standard
+(see http://www.enpassant.dk/chess/palview/enhancedpgn.htm), more
+specifically:
+
+- understands the [%clk 1:59:58] tag in the PGN comment section as the
+ clock time after each move
+- understands the PGN tags [WhiteClock "2:00:00"] and
+ [BlackClock "2:00:00"] as the clock times at the beginning of the game
+- understands the PGN tag [Clock "W/1:59:59"] as the clock time of the
+ running clock
+- allows parsing of generic comment tags using the function
+ customPgnCommentTag()
+
+pgn4web also supports null moves in the "--" notation (used by a number of
+chess softwares like scid and chessbase), such as in 1. e4 -- 2. d4, and
+supports continuations (defined as variations where the last move played
+before the variation is not taken back prior to the start of the variation
+moves) in the "(*" notation, such as in 1. e4 (* 1... d5 2. exd5) e5
+
+Please email me for review any PGN file that pgn4web fails parsing correctly.
+
+
+CHESS960 SUPPORT
+
+pgn4web supports Chess960 (a.k.a. Fischer random chess) and understands both
+the X-FEN and the Shredder-FEN extensions to the FEN notation.
+
+
+JAVASCRIPT CODING
+
+As of pgn4web version 1.72, the pgn4web.js code is checked with the lint
+tool (see online version at http://www.javascriptlint.com/online_lint.php).
+Plase note that warnings "lint warning: increment (++) and decrement (--)
+operators used as part of greater statement" are ignored.
+Lint validation should allow for easy compression of the javascript code,
+for instance using http://javascriptcompressor.com/
+Although a compression beyond 50% can be achieved, only the uncompressed
+version is distributed, but if you want to use a compressed version on your
+site, the pgn4web.js code should support it.
+
+As of pgn4web version 2.71 strict mode is used, see statement: "use strict";
+
+
+CREDITS AND LICENSE
+
+javascript modifications of Paolo Casaschi (pgn4web@casaschi.net) on code
+from the http://ficsgames.org database, in turn likely based on code from the
+LT PGN viewer at http://www.lutanho.net/pgn/pgnviewer.html
+
+PNG images from http://ixian.com/chess/jin-piece-sets (creative commons
+attribution-share alike 3.0 unported license) by Eric De Mund.
+SVG images from http://commons.wikimedia.org/wiki/Category:SVG_chess_pieces
+by Colin M.L. Burnett; licensed under GFDL (www.gnu.org/copyleft/fdl.html),
+CC-BY-SA-3.0 (www.creativecommons.org/licenses/by-sa/3.0/) or
+GPL (www.gnu.org/licenses/gpl.html), via Wikimedia Commons. SVG images from
+http://openclipart.org/search/?query=chess+symbols+set by Igor Krizanovskij
+and from http://openclipart.org/search/?query=Chess+tile both dedicated to
+the Public Domain (http://creativecommons.org/publicdomain/zero/1.0/) as any
+openclipart.org content.
+
+The figurine fonts are derived from the Liberation Sans font (released under
+GNU General Public License, see https://fedorahosted.org/liberation-fonts/)
+with the addition of chess pieces from freeware fonts: the alpha2 font (Peter
+Strickland), the good companion font (David L. Brown), the merida font (Armando
+H. Marroquin), the pirate font (Klaus Wolf) and the chess usual font (Armando
+H. Marroquin). The original chess fonts and more details are available at
+http://www.enpassant.dk/chess/fonteng.htm
+The chess informant symbols font is used with permission from the Chess
+Informant publishing company (http://www.chessinformant.rs). The chess ole
+figurin font is from the ChessOLE project (http://www.chessole.de, David Frank).
+
+Some of the PGN files for the examples are coming from "The Week in Chess" at
+http://www.theweekinchess.com (file twic944.pgn), from the scid project at
+http://scid.sourceforge.net (file tactics.pgn, with minor modifications), and
+from the Chess Informant publishing company at http://www.chessinformant.rs
+(file chess-informant-sample.pgn).
+
+The jscolor javascript code is maintained by Honza Odvarko
+(http://odvarko.cz/) and released under the GNU Lesser General Public License
+(http://www.gnu.org/copyleft/lesser.html)
+See http://jscolor.com/
+
+The SWFObject javascript library (http://code.google.com/p/swfobject/) is
+released under the MIT License
+(http://www.opensource.org/licenses/mit-license.php).
+
+The ECO code (http://en.wikipedia.org/wiki/Encyclopaedia_of_Chess_Openings) for
+game opening classification is a trademark of the Chess Informant publishing
+company (http://www.chessinformant.rs).
+
+
+The above items remains subject to their original licenses (if any).
+
+
+Remaining pgn4web code is copyright (C) 2009-2013 Paolo Casaschi
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License along
+with this program; if not, write to the Free Software Foundation, Inc.,
+51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+See license-gpl-2.0.txt license file.
+
+You are free to use pgn4web in your website or blog; you are not required to
+acknowledge the pgn4web project, but if you want to do so the following line
+might be used:
+javascript chess viewer courtesy of pgn4web
+
+You are also encouraged to notify pgn4web@casaschi.net that you are using
+pgn4web.
+
+END
+
diff --git a/_assets/vendor/pgn4web/_index.html b/_assets/vendor/pgn4web/_index.html
new file mode 100644
index 0000000..484e22b
--- /dev/null
+++ b/_assets/vendor/pgn4web/_index.html
@@ -0,0 +1,53 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/_assets/vendor/pgn4web/analysis.css b/_assets/vendor/pgn4web/analysis.css
new file mode 100644
index 0000000..bf990ba
--- /dev/null
+++ b/_assets/vendor/pgn4web/analysis.css
@@ -0,0 +1,182 @@
+/*
+ * pgn4web javascript chessboard
+ * copyright (C) 2009-2013 Paolo Casaschi
+ * see README file and http://pgn4web.casaschi.net
+ * for credits, license and more details
+ */
+
+/*
+ * display optimized for a 664px high frame
+ */
+
+@import url("fonts/pgn4web-font-LiberationSans.css");
+@import url("fonts/pgn4web-font-ChessSansUsual.css");
+
+html,
+body {
+ margin: 0px;
+ padding: 0px;
+ overflow: hidden;
+}
+
+body {
+ font-family: 'pgn4web Liberation Sans', sans-serif;
+ font-size: 19px;
+ color: black;
+ background: white;
+}
+
+a {
+ color: black;
+ text-decoration: none;
+}
+
+div, span {
+ font-family: 'pgn4web Liberation Sans', sans-serif; /* fixes IE9 body css issue */
+}
+
+.boardheaderDiv {
+ position: absolute;
+ top: 0px;
+ left: 0px;
+ padding: 30px;
+ overflow: hidden;
+}
+
+.topSpacer {
+ height: 30px;
+}
+
+.gametextresultDiv {
+ padding-left: 30px;
+ padding-right: 30px;
+ margin-left: 421px;
+ margin-bottom: 30px;
+ overflow-y: scroll;
+ overflow-x: hidden;
+ text-align: justify;
+ scrollbar-base-color: #FFFFFF;
+}
+
+.shortRowSpace {
+ height: 15px;
+ line-height: 15px;
+}
+
+.gameLastMove {
+ font-size: 14px;
+ line-height: 20px;
+ white-space: nowrap;
+ overflow: hidden;
+}
+
+.gameAnnotator {
+ float: right;
+ font-style: italic;
+}
+
+.headerLine {
+ overflow: hidden;
+ white-space: nowrap;
+ width: 376px;
+ font-weight: bold;
+ font-size: 22px;
+ line-height: 30px;
+ text-align: center;
+}
+
+.gameNum {
+ width:188px;
+ text-align: left;
+}
+
+.gameECO {
+ width:188px;
+ text-align: right;
+}
+
+.gameSiteEventDate {
+ font-style: italic;
+ font-weight: normal;
+}
+
+.boardTable {
+ width: 376px;
+ height: 376px;
+ border-style: solid;
+ border-color: #808080;
+ border-width: 3px;
+ box-shadow: 0px 0px 20px #DDDDDD;
+}
+
+.pieceImage {
+ width: 39px;
+ height: 39px;
+}
+
+.whiteSquare,
+.blackSquare,
+.highlightWhiteSquare,
+.highlightBlackSquare {
+ width: 45px;
+ height: 45px;
+ border-style: solid;
+ border-width: 1px;
+}
+
+.whiteSquare,
+.highlightWhiteSquare {
+ border-color: #FFFFFF;
+ background: #FFFFFF;
+}
+
+.blackSquare,
+.highlightBlackSquare {
+ border-color: #DDDDDD;
+ background: #DDDDDD;
+}
+
+.highlightWhiteSquare,
+.highlightBlackSquare {
+ border-color: #AAAAAA;
+ border-style: solid;
+}
+
+.move,
+.variation,
+.comment {
+ color: black;
+ line-height: 1.4em;
+ font-weight: normal;
+ text-decoration: none;
+}
+
+.move,
+.variation,
+.commentMove {
+ font-family: 'pgn4web ChessSansUsual', 'pgn4web Liberation Sans', sans-serif;
+}
+
+a.move,
+a.variation,
+.commentMove {
+ white-space: nowrap;
+}
+
+.comment,
+.variation {
+ color: gray !important;
+}
+
+a.variation {
+ color: gray !important;
+}
+
+.moveOn,
+.variationOn,
+a.move:hover,
+a.variation:hover {
+ background: #DDDDDD;
+ border-radius: 2px;
+}
+
diff --git a/_assets/vendor/pgn4web/analysis.html b/_assets/vendor/pgn4web/analysis.html
new file mode 100644
index 0000000..3201546
--- /dev/null
+++ b/_assets/vendor/pgn4web/analysis.html
@@ -0,0 +1,170 @@
+
+
+
+
+
+
+
+0.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
keep PGN data short: due to a limitation of web browsers and web servers with the URL length, only short PGN texts are allowed, usually up to four games without comments; an error message shows when the max URL length limit is exceeded, in case try removing unnecessary header tags and comments/variations or try reducing the number of games per chessboard
+
by default the PGN data is compressed and encoded, with characters outside the 255 characters ascii set rejected and replaced with stars "*"; this might affect some non English text and names
+
in case of errors in the supplied PGN data, the chessboard squares starts flashing at regular intervals to signal the exception; detailed debug information is available clicking the top left chessboard square (A8 assuming White on bottom, H1 otherwise)
+once happy with the preview chessboard, just cut and paste the HTML code from the yellow box into your web page or your blog; when entering the code in your website or blog, please make sure you are using the HTML editing option, otherwise an enhanced editor might alter the code you enter; you can also generate a short url for sharing the board via email, instant messaging or social networking sites
+
+
+
+
+if you plan to reuse similar settings for other chessboards, you can bookmark a custom template into your web browser bookmarks
+
+
+
+
+email to the address of your website or your blog
+
+service availability disclaimer: the pgn4web board generator on this site is intended for chess enthusiasts to easily add chess games with a dynamic chessboard to their personal blogs and websites; this online service is provided on a best effort basis with no guarantee of future availability; if you publish chess games as part of a professional site and need continued server availability and high network performance, you are strongly recommended to evaluate the code from and install the tool on your own servers; for more details see the board widget generator pages of the pgn4web wiki at
+
+Side to move:
+
+Last move:variations:
+
+Next move:variations:
+
+Move comment:
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/_assets/vendor/pgn4web/chess960wch06.css b/_assets/vendor/pgn4web/chess960wch06.css
new file mode 100644
index 0000000..650d2bd
--- /dev/null
+++ b/_assets/vendor/pgn4web/chess960wch06.css
@@ -0,0 +1,139 @@
+/*
+ * pgn4web javascript chessboard
+ * copyright (C) 2009-2013 Paolo Casaschi
+ * see README file and http://pgn4web.casaschi.net
+ * for credits, license and more details
+ */
+
+html,
+body {
+ margin: 0px;
+ padding: 0px;
+}
+
+body {
+ padding: 10px;
+ font-family: sans-serif;
+ font-size: 16px;
+ color: black;
+ background: white;
+}
+
+a {
+ text-decoration: none;
+ color: black;
+}
+
+ul {
+ margin-bottom: 0px;
+}
+
+.boardTable {
+ border-color: #C4B9A0;
+ border-width: 2px;
+ border-style: outset;
+}
+
+.pieceImage {
+ width: 32px;
+ height: 32px;
+}
+
+.whiteSquare,
+.blackSquare,
+.highlightWhiteSquare,
+.highlightBlackSquare {
+ width: 42px;
+ height: 42px;
+ border-style: solid;
+ border-width: 1px;
+}
+
+.whiteSquare,
+.highlightWhiteSquare {
+ border-color: #EFE6D0;
+ background: #EFE6D0;
+}
+
+.blackSquare,
+.highlightBlackSquare {
+ border-color: #C4B9A0;
+ background: #C4B9A0;
+}
+
+.highlightWhiteSquare,
+.highlightBlackSquare {
+ border-style: inset;
+}
+
+.selectControl {
+/* a "width" attribute here must use the !important flag to override default settings */
+}
+
+.optionSelectControl {
+}
+
+.buttonControlPlay,
+.buttonControlStop,
+.buttonControl {
+/* a "width" attribute here must use the !important flag to override default settings */
+}
+
+.buttonControlSpace {
+/* a "width" attribute here must use the !important flag to override default settings */
+}
+
+.searchPgnButton {
+/* a "width" attribute here must use the !important flag to override default settings */
+}
+
+.searchPgnExpression {
+/* a "width" attribute here must use the !important flag to override default settings */
+}
+
+.move,
+.variation,
+.comment {
+ color: black;
+ font-family: sans-serif;
+ line-height: 1.3em;
+ font-weight: normal;
+ text-decoration: none;
+}
+
+.comment,
+.variation {
+ color: gray;
+}
+
+a.move,
+a.variation,
+.commentMove {
+ white-space: nowrap;
+}
+
+a.variation {
+ color: gray;
+}
+
+.moveOn,
+.variationOn {
+ background: #EFE6D0;
+}
+
+.label {
+ color: black;
+ font-weight: bold;
+ font-size: 16px;
+}
+
+.gameFEN {
+ font-size: 13px;
+ text-align: left;
+}
+
+.gameText {
+ font-size: 13px;
+ text-align: justify;
+}
+
diff --git a/_assets/vendor/pgn4web/chess960wch06.html b/_assets/vendor/pgn4web/chess960wch06.html
new file mode 100644
index 0000000..98a5d93
--- /dev/null
+++ b/_assets/vendor/pgn4web/chess960wch06.html
@@ -0,0 +1,161 @@
+
+
+
+
+
+
+
+Chess960 World Championship 2006
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mainz GER, 2006
+
+Chess960 rapid WCh
+
+
+
+
#
+
+
+
+ -
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+These are the games for the Chess960 rapid World Championship 2006 in Mainz (Germany) between Levon Aronian (Armenia) and Peter Svidler (Russia). Aronian won the match 5-3, with no draws!
+
+
+
+
+
+
+This chess variant uses the same board and pieces as standard chess, with extended options for the starting position and castling rules adapted accordingly.
+
+Starting position:
+
+
pawns start in the same position as in standard chess
+
White pieces are placed randomly on the first rank
+
+
the King must be placed somewhere between the Rooks
+
the Bishops must be on opposite color squares
+
+
Black pieces are placed equal and opposite to the White pieces
+
+
+Castling rules:
+
+
castling is allowed under the following conditions
+
+
the King and the castling Rook must not have moved before
+
no square between the King's initial and final squares may be under attack by any opposing piece
+
all the squares between the King's initial and final squares and all the squares between the Rook's initial and final squares must be vacant except for the King and the castling Rook
+
+
after castling, the Rook and King's final positions are exactly the same as they would be in standard chess
+
+
+Games notation:
+
+
games are recorded using the PGN notation, with an extension to the FEN notation in order to support castling information
+
two very similar FEN extensions have been proposed: X-FEN and Shredder-FEN
+This is an application example showing how to use the pgn4web file collection.html to manage a collection of PGN files.
+
+Two alternative options are shown.
+
+
+
+links to the viewer
+
+A link can be listed for viewing each PGN file in a new browser window:
+
+
+pgn4web live broadcast: flash replacement
+
+
+
+
+
+
+
+What about replacing with a broadly supported technology a well known live chess broadcast client based on the adobe flash technology and therefore not supported by mobile devices such as android phones and tablets, the iphone and the ipad? This page shows equivalent functionality based on HTML5 (javascript + css) that works on mobile devices as well.
+
+
+
+
basic example
+
+This replicates the flash based client layout and functionality:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
advanced example
+
+This shows additional functionality of the pgn4web viewer, including customized colors, customized chess pieces and integrated user/engine analysis board:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
more examples
+
+Please find below links to few more live chess broadcast examples showing the multiple options available from pgn4web:
+
click on the dots at the bottom or click on square F5 for the list of available games
+
click on square H5 for a fullscreen view, then use the browser's back button to return to this page
+
click on square E8 of the main board to activate the analysis board, copying the postion from the main board and starting the built-in chess engine (if supported by the web browser); try moves and variations clicking the from/to squares on the analysis board.
+
click on square H8 for further general help
+
+
+
webmaster hints to setup a live games broadcast
+
+The following instructions refer to the basic example; the advanced example including the integrated user/engine analysis board is relatively more complex, please contact the pgn4web project for detailed instructions based on specific requirements.
+
+
+
copy the pgn4web files on the server, for instance in the folder accessible as http://example.com/somewhere/pgn4web/
+
reuse the same tools that generate the chess moves for the flash based client processing the inputs from the electronic boards
+
configure those tools to save games as a PGN file accessible as http://example.com/somewhere/pgn4web/live/live.pgn, including clock information if available
+
replace the flash object in the live web pages with an inline frame using a src url similar to the example of this page, such as http://example.com/somewhere/pgn4web/dynamic-frame.html?
+
set the inline frame height/width as appropriate to each live web page on the server and add any desired iframe css style property
+
+
+
+
+
diff --git a/_assets/vendor/pgn4web/one.pgn b/_assets/vendor/pgn4web/one.pgn
new file mode 100644
index 0000000..822aa7a
--- /dev/null
+++ b/_assets/vendor/pgn4web/one.pgn
@@ -0,0 +1,24 @@
+[Event "World Championship"]
+[Site "Reykjavik"]
+[Date "1972"]
+[Round "13"]
+[White "Spassky, Boris"]
+[Black "Fischer, Robert"]
+[Result "0-1"]
+[ECO "B04"]
+[Opening "Alekhine's defence"]
+[Variation "modern, fianchetto variation"]
+
+1. e4 Nf6 2. e5 Nd5 3. d4 d6 4. Nf3 g6 5. Bc4 Nb6 6. Bb3 Bg7 7. Nbd2 O-O 8.
+h3 a5 9. a4 dxe5 10. dxe5 Na6 11. O-O Nc5 12. Qe2 Qe8 13. Ne4 Nbxa4 14.
+Bxa4 Nxa4 15. Re1 Nb6 16. Bd2 a4 17. Bg5 h6 18. Bh4 Bf5 19. g4 Be6 20. Nd4
+Bc4 21. Qd2 Qd7 22. Rad1 Rfe8 23. f4 Bd5 24. Nc5 Qc8 25. Qc3 e6 26. Kh2 Nd7
+27. Nd3 c5 28. Nb5 Qc6 29. Nd6 Qxd6 30. exd6 Bxc3 31. bxc3 f6 32. g5 hxg5
+33. fxg5 f5 34. Bg3 Kf7 35. Ne5+ Nxe5 36. Bxe5 b5 37. Rf1 Rh8 38. Bf6 a3
+39. Rf4 a2 40. c4 Bxc4 41. d7 Bd5 42. Kg3 Ra3+ 43. c3 Rha8 44. Rh4 e5 45.
+Rh7+ Ke6 46. Re7+ Kd6 47. Rxe5 Rxc3+ 48. Kf2 Rc2+ 49. Ke1 Kxd7 50. Rexd5+
+Kc6 51. Rd6+ Kb7 52. Rd7+ Ka6 53. R7d2 Rxd2 54. Kxd2 b4 55. h4 Kb5 56. h5
+c4 57. Ra1 gxh5 58. g6 h4 59. g7 h3 60. Be7 Rg8 61. Bf8 h2 62. Kc2 Kc6 63.
+Rd1 b3+ 64. Kc3 h1=Q 65. Rxh1 Kd5 66. Kb2 f4 67. Rd1+ Ke4 68. Rc1 Kd3 69.
+Rd1+ Ke2 70. Rc1 f3 71. Bc5 Rxg7 72. Rxc4 Rd7 73. Re4+ Kf1 74. Bd4 f2 0-1
+
diff --git a/_assets/vendor/pgn4web/parsing-tests.js b/_assets/vendor/pgn4web/parsing-tests.js
new file mode 100644
index 0000000..636b8a5
--- /dev/null
+++ b/_assets/vendor/pgn4web/parsing-tests.js
@@ -0,0 +1,55 @@
+/*
+ * pgn4web javascript chessboard
+ * copyright (C) 2009-2013 Paolo Casaschi
+ * see README file and http://pgn4web.casaschi.net
+ * for credits, license and more details
+ */
+
+"use strict";
+
+function testAllMoves() {
+ var ii = 0;
+ var start = (new Date()).getTime();
+ resetAlert();
+ for (var gg = 0; gg < numberOfGames; gg++) {
+ Init(gg);
+ for (var vv = 0; vv < numberOfVars; vv++) {
+ for (var hh = StartPlyVar[vv]; hh <= StartPlyVar[vv] + PlyNumberVar[vv]; hh++) {
+ GoToMove(hh, vv);
+ if ((++ii % 100) === 0) { console.log("i=" + ii + " g=" + gg + "/" + numberOfGames + " a=" + alertNumSinceReset); }
+ }
+ }
+ }
+ console.log("t=" + ((new Date()).getTime() - start) + " a=" + alertNumSinceReset);
+ return alertNumSinceReset;
+}
+
+function testRandomMoves(nn, pv, pg) {
+ var start = (new Date()).getTime();
+ resetAlert();
+ if (typeof(nn) == "undefined") { nn = numberOfGames * 100; }
+ if (typeof(pv) == "undefined") { pv = 0.5; }
+ if (typeof(pg) == "undefined") { pg = 0.1; }
+ var vv = 0;
+ var gg = 0;
+ for (var ii = 1; ii <= nn; ii++) {
+ if (Math.random() < pg) {
+ gg = Math.floor(numberOfGames * Math.random());
+ Init(gg);
+ vv = 0;
+ }
+ if (Math.random() < pv) {
+ vv = Math.floor(numberOfVars * Math.random());
+ }
+ var hh = StartPlyVar[vv] + Math.floor((PlyNumberVar[vv] + 1) * Math.random());
+ GoToMove(hh, vv);
+ if ((ii % 100) === 0) { console.log("i=" + ii + "/" + nn + " a=" + alertNumSinceReset); }
+ }
+ console.log("t=" + ((new Date()).getTime() - start) + " a=" + alertNumSinceReset);
+ return alertNumSinceReset;
+}
+
+function customFunctionOnAlert (msg) {
+ console.log(" alert: g=" + currentGame + " v=" + CurrentVar + " p=" + CurrentPly + " m=" + msg);
+}
+
diff --git a/_assets/vendor/pgn4web/pawn.ico b/_assets/vendor/pgn4web/pawn.ico
new file mode 100644
index 0000000..6131d0e
Binary files /dev/null and b/_assets/vendor/pgn4web/pawn.ico differ
diff --git a/_assets/vendor/pgn4web/pawn.png b/_assets/vendor/pgn4web/pawn.png
new file mode 100644
index 0000000..367427b
Binary files /dev/null and b/_assets/vendor/pgn4web/pawn.png differ
diff --git a/_assets/vendor/pgn4web/pawns.png b/_assets/vendor/pgn4web/pawns.png
new file mode 100644
index 0000000..509f5a1
Binary files /dev/null and b/_assets/vendor/pgn4web/pawns.png differ
diff --git a/_assets/vendor/pgn4web/pgn-decoder.js b/_assets/vendor/pgn4web/pgn-decoder.js
new file mode 100644
index 0000000..9a1a27a
--- /dev/null
+++ b/_assets/vendor/pgn4web/pgn-decoder.js
@@ -0,0 +1,574 @@
+/*
+ * pgn4web javascript chessboard
+ * copyright (C) 2009-2013 Paolo Casaschi
+ * see README file and http://pgn4web.casaschi.net
+ * for credits, license and more details
+ *
+ * Huffman encoding/decoding derived from code at http://rumkin.com/tools/compression/compress_huff.php
+ */
+
+// version 1 of PGN encoding:
+// encodedPGN = nnn$xxx0
+// nnn = number representing bytes length of the decoded message
+// $ = dollar char (delimiter for length info)
+// xxx = encoded text (using LetterCodes below)
+// 0 = zero char (version marker)
+
+"use strict";
+
+var encodingCharSet_dec;
+var encodingCharSet_enc;
+var encodingCharSet = encodingCharSet_dec = "$0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_";
+var encodingVersion_dec;
+var encodingVersion_enc;
+var encodingVersion = encodingVersion_dec = 1;
+var errorString;
+
+if (((encodingCharSet_enc != undefined) && (encodingCharSet_enc != encodingCharSet_dec)) ||
+ ((encodingVersion_enc != undefined) && (encodingVersion_enc != encodingVersion_dec))) {
+ errorString = "error: PGN encoding/decoding mismatch";
+ if (typeof myAlert == "function") { myAlert(errorString); }
+ else { alert(errorString); }
+}
+
+function DecodePGN(bytes) {
+
+ if (bytes.charAt(bytes.length - 1) != encodingCharSet.charAt(encodingVersion)) {
+ errorString = "error: PGN encoding version mismatch (e:" +
+ bytes.charAt(bytes.length - 1) + " d:" + encodingCharSet.charAt(encodingVersion) + ")";
+ if (typeof myAlert == "function") { myAlert(errorString); }
+ else { alert(errorString); }
+ }
+
+ var originalLength = parseInt(bytes.match(/^[0-9]*/), 10);
+ bytes = bytes.replace(/^[0-9]*\$/,"");
+
+ var l = new Array();
+ l[0] = -146;
+ l[1] = -111;
+ l[2] = -66;
+ l[3] = -55;
+ l[4] = -6;
+ l[5] = 46;
+ l[6] = -8;
+ l[7] = 66;
+ l[8] = -10;
+ l[9] = 105;
+ l[10] = -12;
+ l[11] = 107;
+ l[12] = -14;
+ l[13] = 44;
+ l[14] = -16;
+ l[15] = 85;
+ l[16] = -18;
+ l[17] = 106;
+ l[18] = -20;
+ l[19] = 62;
+ l[20] = -22;
+ l[21] = 89;
+ l[22] = -24;
+ l[23] = 38;
+ l[24] = -40;
+ l[25] = -33;
+ l[26] = -30;
+ l[27] = -29;
+ l[28] = 17;
+ l[29] = 18;
+ l[30] = -32;
+ l[31] = 15;
+ l[32] = 16;
+ l[33] = -37;
+ l[34] = -36;
+ l[35] = 21;
+ l[36] = 22;
+ l[37] = -39;
+ l[38] = 19;
+ l[39] = 20;
+ l[40] = -48;
+ l[41] = -45;
+ l[42] = -44;
+ l[43] = 7;
+ l[44] = 8;
+ l[45] = -47;
+ l[46] = 5;
+ l[47] = 6;
+ l[48] = -52;
+ l[49] = -51;
+ l[50] = 12;
+ l[51] = 14;
+ l[52] = -54;
+ l[53] = 9;
+ l[54] = 11;
+ l[55] = -57;
+ l[56] = 34;
+ l[57] = -59;
+ l[58] = 78;
+ l[59] = -61;
+ l[60] = 57;
+ l[61] = -63;
+ l[62] = 63;
+ l[63] = -65;
+ l[64] = 109;
+ l[65] = 119;
+ l[66] = -80;
+ l[67] = -69;
+ l[68] = 101;
+ l[69] = -71;
+ l[70] = 55;
+ l[71] = -73;
+ l[72] = 69;
+ l[73] = -75;
+ l[74] = 118;
+ l[75] = -77;
+ l[76] = 121;
+ l[77] = -79;
+ l[78] = 73;
+ l[79] = 123;
+ l[80] = -82;
+ l[81] = 49;
+ l[82] = -86;
+ l[83] = -85;
+ l[84] = 13;
+ l[85] = 40;
+ l[86] = -88;
+ l[87] = 45;
+ l[88] = -90;
+ l[89] = 68;
+ l[90] = -92;
+ l[91] = 84;
+ l[92] = -94;
+ l[93] = 125;
+ l[94] = -96;
+ l[95] = 39;
+ l[96] = -98;
+ l[97] = 58;
+ l[98] = -100;
+ l[99] = 36;
+ l[100] = -102;
+ l[101] = 92;
+ l[102] = -104;
+ l[103] = 124;
+ l[104] = -108;
+ l[105] = -107;
+ l[106] = 3;
+ l[107] = 4;
+ l[108] = -110;
+ l[109] = 0;
+ l[110] = 2;
+ l[111] = -129;
+ l[112] = -118;
+ l[113] = -115;
+ l[114] = 50;
+ l[115] = -117;
+ l[116] = 102;
+ l[117] = 103;
+ l[118] = -122;
+ l[119] = -121;
+ l[120] = 48;
+ l[121] = 110;
+ l[122] = -126;
+ l[123] = -125;
+ l[124] = 10;
+ l[125] = 1;
+ l[126] = -128;
+ l[127] = 79;
+ l[128] = 117;
+ l[129] = -137;
+ l[130] = -132;
+ l[131] = 51;
+ l[132] = -134;
+ l[133] = 98;
+ l[134] = -136;
+ l[135] = 47;
+ l[136] = 112;
+ l[137] = -141;
+ l[138] = -140;
+ l[139] = 56;
+ l[140] = 81;
+ l[141] = -143;
+ l[142] = 104;
+ l[143] = -145;
+ l[144] = 114;
+ l[145] = 115;
+ l[146] = -192;
+ l[147] = -153;
+ l[148] = -150;
+ l[149] = 32;
+ l[150] = -152;
+ l[151] = 91;
+ l[152] = 93;
+ l[153] = -157;
+ l[154] = -156;
+ l[155] = 99;
+ l[156] = 120;
+ l[157] = -159;
+ l[158] = 116;
+ l[159] = -161;
+ l[160] = 75;
+ l[161] = -163;
+ l[162] = 80;
+ l[163] = -165;
+ l[164] = 67;
+ l[165] = -167;
+ l[166] = 77;
+ l[167] = -169;
+ l[168] = 90;
+ l[169] = -171;
+ l[170] = 60;
+ l[171] = -173;
+ l[172] = 33;
+ l[173] = -175;
+ l[174] = 37;
+ l[175] = -177;
+ l[176] = 96;
+ l[177] = -185;
+ l[178] = -182;
+ l[179] = -181;
+ l[180] = 248;
+ l[181] = 249;
+ l[182] = -184;
+ l[183] = 246;
+ l[184] = 247;
+ l[185] = -189;
+ l[186] = -188;
+ l[187] = 252;
+ l[188] = 253;
+ l[189] = -191;
+ l[190] = 250;
+ l[191] = 251;
+ l[192] = -228;
+ l[193] = -225;
+ l[194] = -196;
+ l[195] = 52;
+ l[196] = -198;
+ l[197] = 108;
+ l[198] = -208;
+ l[199] = -201;
+ l[200] = 83;
+ l[201] = -205;
+ l[202] = -204;
+ l[203] = 61;
+ l[204] = 72;
+ l[205] = -207;
+ l[206] = 113;
+ l[207] = 122;
+ l[208] = -212;
+ l[209] = -211;
+ l[210] = 65;
+ l[211] = 70;
+ l[212] = -214;
+ l[213] = 71;
+ l[214] = -216;
+ l[215] = 76;
+ l[216] = -218;
+ l[217] = 74;
+ l[218] = -220;
+ l[219] = 88;
+ l[220] = -222;
+ l[221] = 64;
+ l[222] = -224;
+ l[223] = 42;
+ l[224] = 94;
+ l[225] = -227;
+ l[226] = 53;
+ l[227] = 100;
+ l[228] = -232;
+ l[229] = -231;
+ l[230] = 54;
+ l[231] = 82;
+ l[232] = -234;
+ l[233] = 97;
+ l[234] = -236;
+ l[235] = 111;
+ l[236] = -238;
+ l[237] = 43;
+ l[238] = -240;
+ l[239] = 87;
+ l[240] = -242;
+ l[241] = 41;
+ l[242] = -244;
+ l[243] = 86;
+ l[244] = -246;
+ l[245] = 35;
+ l[246] = -256;
+ l[247] = -249;
+ l[248] = 59;
+ l[249] = -251;
+ l[250] = 95;
+ l[251] = -253;
+ l[252] = 126;
+ l[253] = -255;
+ l[254] = 254;
+ l[255] = 255;
+ l[256] = -384;
+ l[257] = -321;
+ l[258] = -290;
+ l[259] = -275;
+ l[260] = -268;
+ l[261] = -265;
+ l[262] = -264;
+ l[263] = 160;
+ l[264] = 161;
+ l[265] = -267;
+ l[266] = 158;
+ l[267] = 159;
+ l[268] = -272;
+ l[269] = -271;
+ l[270] = 164;
+ l[271] = 165;
+ l[272] = -274;
+ l[273] = 162;
+ l[274] = 163;
+ l[275] = -283;
+ l[276] = -280;
+ l[277] = -279;
+ l[278] = 152;
+ l[279] = 153;
+ l[280] = -282;
+ l[281] = 150;
+ l[282] = 151;
+ l[283] = -287;
+ l[284] = -286;
+ l[285] = 156;
+ l[286] = 157;
+ l[287] = -289;
+ l[288] = 154;
+ l[289] = 155;
+ l[290] = -306;
+ l[291] = -299;
+ l[292] = -296;
+ l[293] = -295;
+ l[294] = 176;
+ l[295] = 177;
+ l[296] = -298;
+ l[297] = 174;
+ l[298] = 175;
+ l[299] = -303;
+ l[300] = -302;
+ l[301] = 180;
+ l[302] = 181;
+ l[303] = -305;
+ l[304] = 178;
+ l[305] = 179;
+ l[306] = -314;
+ l[307] = -311;
+ l[308] = -310;
+ l[309] = 168;
+ l[310] = 169;
+ l[311] = -313;
+ l[312] = 166;
+ l[313] = 167;
+ l[314] = -318;
+ l[315] = -317;
+ l[316] = 172;
+ l[317] = 173;
+ l[318] = -320;
+ l[319] = 170;
+ l[320] = 171;
+ l[321] = -353;
+ l[322] = -338;
+ l[323] = -331;
+ l[324] = -328;
+ l[325] = -327;
+ l[326] = 128;
+ l[327] = 129;
+ l[328] = -330;
+ l[329] = 31;
+ l[330] = 127;
+ l[331] = -335;
+ l[332] = -334;
+ l[333] = 132;
+ l[334] = 133;
+ l[335] = -337;
+ l[336] = 130;
+ l[337] = 131;
+ l[338] = -346;
+ l[339] = -343;
+ l[340] = -342;
+ l[341] = 25;
+ l[342] = 26;
+ l[343] = -345;
+ l[344] = 23;
+ l[345] = 24;
+ l[346] = -350;
+ l[347] = -349;
+ l[348] = 29;
+ l[349] = 30;
+ l[350] = -352;
+ l[351] = 27;
+ l[352] = 28;
+ l[353] = -369;
+ l[354] = -362;
+ l[355] = -359;
+ l[356] = -358;
+ l[357] = 144;
+ l[358] = 145;
+ l[359] = -361;
+ l[360] = 142;
+ l[361] = 143;
+ l[362] = -366;
+ l[363] = -365;
+ l[364] = 148;
+ l[365] = 149;
+ l[366] = -368;
+ l[367] = 146;
+ l[368] = 147;
+ l[369] = -377;
+ l[370] = -374;
+ l[371] = -373;
+ l[372] = 136;
+ l[373] = 137;
+ l[374] = -376;
+ l[375] = 134;
+ l[376] = 135;
+ l[377] = -381;
+ l[378] = -380;
+ l[379] = 140;
+ l[380] = 141;
+ l[381] = -383;
+ l[382] = 138;
+ l[383] = 139;
+ l[384] = -448;
+ l[385] = -417;
+ l[386] = -402;
+ l[387] = -395;
+ l[388] = -392;
+ l[389] = -391;
+ l[390] = 224;
+ l[391] = 225;
+ l[392] = -394;
+ l[393] = 222;
+ l[394] = 223;
+ l[395] = -399;
+ l[396] = -398;
+ l[397] = 228;
+ l[398] = 229;
+ l[399] = -401;
+ l[400] = 226;
+ l[401] = 227;
+ l[402] = -410;
+ l[403] = -407;
+ l[404] = -406;
+ l[405] = 216;
+ l[406] = 217;
+ l[407] = -409;
+ l[408] = 214;
+ l[409] = 215;
+ l[410] = -414;
+ l[411] = -413;
+ l[412] = 220;
+ l[413] = 221;
+ l[414] = -416;
+ l[415] = 218;
+ l[416] = 219;
+ l[417] = -433;
+ l[418] = -426;
+ l[419] = -423;
+ l[420] = -422;
+ l[421] = 240;
+ l[422] = 241;
+ l[423] = -425;
+ l[424] = 238;
+ l[425] = 239;
+ l[426] = -430;
+ l[427] = -429;
+ l[428] = 244;
+ l[429] = 245;
+ l[430] = -432;
+ l[431] = 242;
+ l[432] = 243;
+ l[433] = -441;
+ l[434] = -438;
+ l[435] = -437;
+ l[436] = 232;
+ l[437] = 233;
+ l[438] = -440;
+ l[439] = 230;
+ l[440] = 231;
+ l[441] = -445;
+ l[442] = -444;
+ l[443] = 236;
+ l[444] = 237;
+ l[445] = -447;
+ l[446] = 234;
+ l[447] = 235;
+ l[448] = -480;
+ l[449] = -465;
+ l[450] = -458;
+ l[451] = -455;
+ l[452] = -454;
+ l[453] = 192;
+ l[454] = 193;
+ l[455] = -457;
+ l[456] = 190;
+ l[457] = 191;
+ l[458] = -462;
+ l[459] = -461;
+ l[460] = 196;
+ l[461] = 197;
+ l[462] = -464;
+ l[463] = 194;
+ l[464] = 195;
+ l[465] = -473;
+ l[466] = -470;
+ l[467] = -469;
+ l[468] = 184;
+ l[469] = 185;
+ l[470] = -472;
+ l[471] = 182;
+ l[472] = 183;
+ l[473] = -477;
+ l[474] = -476;
+ l[475] = 188;
+ l[476] = 189;
+ l[477] = -479;
+ l[478] = 186;
+ l[479] = 187;
+ l[480] = -496;
+ l[481] = -489;
+ l[482] = -486;
+ l[483] = -485;
+ l[484] = 208;
+ l[485] = 209;
+ l[486] = -488;
+ l[487] = 206;
+ l[488] = 207;
+ l[489] = -493;
+ l[490] = -492;
+ l[491] = 212;
+ l[492] = 213;
+ l[493] = -495;
+ l[494] = 210;
+ l[495] = 211;
+ l[496] = -504;
+ l[497] = -501;
+ l[498] = -500;
+ l[499] = 200;
+ l[500] = 201;
+ l[501] = -503;
+ l[502] = 198;
+ l[503] = 199;
+ l[504] = -508;
+ l[505] = -507;
+ l[506] = 204;
+ l[507] = 205;
+ l[508] = -510;
+ l[509] = 202;
+ l[510] = 203;
+
+ var a=0, b=0, e=0, i, o="";
+
+ function B() { if (a===0) { b=encodingCharSet.indexOf(bytes.charAt(e++)); a=6; } return ((b>>--a)&0x01); }
+
+ while(originalLength>0) { i=0;
+ while(l[i]<0) {
+ if (B()) { i=-l[i]; }
+ else { i++; }
+ }
+ o+=String.fromCharCode(l[i]);
+ originalLength--;
+ }
+
+ return o;
+}
+
diff --git a/_assets/vendor/pgn4web/pgn-encoder.js b/_assets/vendor/pgn4web/pgn-encoder.js
new file mode 100644
index 0000000..96cf585
--- /dev/null
+++ b/_assets/vendor/pgn4web/pgn-encoder.js
@@ -0,0 +1,324 @@
+/*
+ * pgn4web javascript chessboard
+ * copyright (C) 2009-2013 Paolo Casaschi
+ * see README file and http://pgn4web.casaschi.net
+ * for credits, license and more details
+ *
+ * Huffman encoding/decoding derived from code at http://rumkin.com/tools/compression/compress_huff.php
+ */
+
+// version 1 of PGN encoding:
+// encodedPGN = nnn$xxx0
+// nnn = number representing bytes length of the decoded message
+// $ = dollar char (delimiter for length info)
+// xxx = encoded text (using LetterCodes below)
+// 0 = zero char (version marker)
+
+"use strict";
+
+var encodingCharSet_dec;
+var encodingCharSet_enc;
+var encodingCharSet = encodingCharSet_enc = "$0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_";
+var encodingVersion_dec;
+var encodingVersion_enc;
+var encodingVersion = encodingVersion_enc = 1;
+var errorString;
+
+if (((encodingCharSet_dec != undefined) && (encodingCharSet_enc != encodingCharSet_dec)) ||
+ ((encodingVersion_dec != undefined) && (encodingVersion_enc != encodingVersion_dec))) {
+ errorString = "error: PGN encoding/decoding version/charset mismatch";
+ if (typeof myAlert == "function") { myAlert(errorString); }
+ else { alert(errorString); }
+}
+
+function EncodePGN(ov) {
+
+ function BitsToBytes(i) {
+ var o = 0;
+ if (i.charAt(0) == '1') { o += 32; }
+ if (i.charAt(1) == '1') { o += 16; }
+ if (i.charAt(2) == '1') { o += 8; }
+ if (i.charAt(3) == '1') { o += 4; }
+ if (i.charAt(4) == '1') { o += 2; }
+ if (i.charAt(5) == '1') { o += 1; }
+ return encodingCharSet.charAt(o);
+ }
+
+ var LetterCodes = new Array(256);
+ LetterCodes[0] = '00111111111111110';
+ LetterCodes[1] = '0101101';
+ LetterCodes[2] = '00111111111111111';
+ LetterCodes[3] = '00111111111111100';
+ LetterCodes[4] = '00111111111111101';
+ LetterCodes[5] = '000011111111111010';
+ LetterCodes[6] = '000011111111111011';
+ LetterCodes[7] = '000011111111111000';
+ LetterCodes[8] = '000011111111111001';
+ LetterCodes[9] = '000011111111111110';
+ LetterCodes[10] = '0101100';
+ LetterCodes[11] = '000011111111111111';
+ LetterCodes[12] = '000011111111111100';
+ LetterCodes[13] = '0011100';
+ LetterCodes[14] = '000011111111111101';
+ LetterCodes[15] = '000011111111110010';
+ LetterCodes[16] = '000011111111110011';
+ LetterCodes[17] = '000011111111110000';
+ LetterCodes[18] = '000011111111110001';
+ LetterCodes[19] = '000011111111110110';
+ LetterCodes[20] = '000011111111110111';
+ LetterCodes[21] = '000011111111110100';
+ LetterCodes[22] = '000011111111110101';
+ LetterCodes[23] = '1111111111110101010';
+ LetterCodes[24] = '1111111111110101011';
+ LetterCodes[25] = '1111111111110101000';
+ LetterCodes[26] = '1111111111110101001';
+ LetterCodes[27] = '1111111111110101110';
+ LetterCodes[28] = '1111111111110101111';
+ LetterCodes[29] = '1111111111110101100';
+ LetterCodes[30] = '1111111111110101101';
+ LetterCodes[31] = '1111111111110100010';
+ LetterCodes[32] = '1000';
+ LetterCodes[33] = '101111111110';
+ LetterCodes[34] = '00010';
+ LetterCodes[35] = '11111111110';
+ LetterCodes[36] = '0011111111110';
+ LetterCodes[37] = '1011111111110';
+ LetterCodes[38] = '00001111111110';
+ LetterCodes[39] = '00111111110';
+ LetterCodes[40] = '0011101';
+ LetterCodes[41] = '111111110';
+ LetterCodes[42] = '11001111111110';
+ LetterCodes[43] = '1111110';
+ LetterCodes[44] = '000011110';
+ LetterCodes[45] = '0011110';
+ LetterCodes[46] = '00000';
+ LetterCodes[47] = '0110110';
+ LetterCodes[48] = '010100';
+ LetterCodes[49] = '00110';
+ LetterCodes[50] = '01000';
+ LetterCodes[51] = '01100';
+ LetterCodes[52] = '11000';
+ LetterCodes[53] = '11010';
+ LetterCodes[54] = '11100';
+ LetterCodes[55] = '001010';
+ LetterCodes[56] = '011100';
+ LetterCodes[57] = '0001110';
+ LetterCodes[58] = '001111111110';
+ LetterCodes[59] = '1111111111100';
+ LetterCodes[60] = '10111111110';
+ LetterCodes[61] = '1100110100';
+ LetterCodes[62] = '000011111110';
+ LetterCodes[63] = '00011110';
+ LetterCodes[64] = '1100111111110';
+ LetterCodes[65] = '110011100';
+ LetterCodes[66] = '000010';
+ LetterCodes[67] = '10111110';
+ LetterCodes[68] = '00111110';
+ LetterCodes[69] = '0010110';
+ LetterCodes[70] = '110011101';
+ LetterCodes[71] = '110011110';
+ LetterCodes[72] = '1100110101';
+ LetterCodes[73] = '0010111110';
+ LetterCodes[74] = '11001111110';
+ LetterCodes[75] = '101110';
+ LetterCodes[76] = '1100111110';
+ LetterCodes[77] = '101111110';
+ LetterCodes[78] = '000110';
+ LetterCodes[79] = '0101110';
+ LetterCodes[80] = '1011110';
+ LetterCodes[81] = '011101';
+ LetterCodes[82] = '11101';
+ LetterCodes[83] = '11001100';
+ LetterCodes[84] = '001111110';
+ LetterCodes[85] = '0000111110';
+ LetterCodes[86] = '1111111110';
+ LetterCodes[87] = '11111110';
+ LetterCodes[88] = '110011111110';
+ LetterCodes[89] = '0000111111110';
+ LetterCodes[90] = '1011111110';
+ LetterCodes[91] = '10010';
+ LetterCodes[92] = '00111111111110';
+ LetterCodes[93] = '10011';
+ LetterCodes[94] = '11001111111111';
+ LetterCodes[95] = '11111111111010';
+ LetterCodes[96] = '10111111111110';
+ LetterCodes[97] = '11110';
+ LetterCodes[98] = '011010';
+ LetterCodes[99] = '10100';
+ LetterCodes[100] = '11011';
+ LetterCodes[101] = '00100';
+ LetterCodes[102] = '010010';
+ LetterCodes[103] = '010011';
+ LetterCodes[104] = '011110';
+ LetterCodes[105] = '0000110';
+ LetterCodes[106] = '00001111110';
+ LetterCodes[107] = '00001110';
+ LetterCodes[108] = '110010';
+ LetterCodes[109] = '000111110';
+ LetterCodes[110] = '010101';
+ LetterCodes[111] = '111110';
+ LetterCodes[112] = '0110111';
+ LetterCodes[113] = '1100110110';
+ LetterCodes[114] = '0111110';
+ LetterCodes[115] = '0111111';
+ LetterCodes[116] = '10110';
+ LetterCodes[117] = '0101111';
+ LetterCodes[118] = '00101110';
+ LetterCodes[119] = '000111111';
+ LetterCodes[120] = '10101';
+ LetterCodes[121] = '001011110';
+ LetterCodes[122] = '1100110111';
+ LetterCodes[123] = '0010111111';
+ LetterCodes[124] = '001111111111110';
+ LetterCodes[125] = '0011111110';
+ LetterCodes[126] = '111111111110110';
+ LetterCodes[127] = '1111111111110100011';
+ LetterCodes[128] = '1111111111110100000';
+ LetterCodes[129] = '1111111111110100001';
+ LetterCodes[130] = '1111111111110100110';
+ LetterCodes[131] = '1111111111110100111';
+ LetterCodes[132] = '1111111111110100100';
+ LetterCodes[133] = '1111111111110100101';
+ LetterCodes[134] = '1111111111110111010';
+ LetterCodes[135] = '1111111111110111011';
+ LetterCodes[136] = '1111111111110111000';
+ LetterCodes[137] = '1111111111110111001';
+ LetterCodes[138] = '1111111111110111110';
+ LetterCodes[139] = '1111111111110111111';
+ LetterCodes[140] = '1111111111110111100';
+ LetterCodes[141] = '1111111111110111101';
+ LetterCodes[142] = '1111111111110110010';
+ LetterCodes[143] = '1111111111110110011';
+ LetterCodes[144] = '1111111111110110000';
+ LetterCodes[145] = '1111111111110110001';
+ LetterCodes[146] = '1111111111110110110';
+ LetterCodes[147] = '1111111111110110111';
+ LetterCodes[148] = '1111111111110110100';
+ LetterCodes[149] = '1111111111110110101';
+ LetterCodes[150] = '1111111111110001010';
+ LetterCodes[151] = '1111111111110001011';
+ LetterCodes[152] = '1111111111110001000';
+ LetterCodes[153] = '1111111111110001001';
+ LetterCodes[154] = '1111111111110001110';
+ LetterCodes[155] = '1111111111110001111';
+ LetterCodes[156] = '1111111111110001100';
+ LetterCodes[157] = '1111111111110001101';
+ LetterCodes[158] = '1111111111110000010';
+ LetterCodes[159] = '1111111111110000011';
+ LetterCodes[160] = '1111111111110000000';
+ LetterCodes[161] = '1111111111110000001';
+ LetterCodes[162] = '1111111111110000110';
+ LetterCodes[163] = '1111111111110000111';
+ LetterCodes[164] = '1111111111110000100';
+ LetterCodes[165] = '1111111111110000101';
+ LetterCodes[166] = '1111111111110011010';
+ LetterCodes[167] = '1111111111110011011';
+ LetterCodes[168] = '1111111111110011000';
+ LetterCodes[169] = '1111111111110011001';
+ LetterCodes[170] = '1111111111110011110';
+ LetterCodes[171] = '1111111111110011111';
+ LetterCodes[172] = '1111111111110011100';
+ LetterCodes[173] = '1111111111110011101';
+ LetterCodes[174] = '1111111111110010010';
+ LetterCodes[175] = '1111111111110010011';
+ LetterCodes[176] = '1111111111110010000';
+ LetterCodes[177] = '1111111111110010001';
+ LetterCodes[178] = '1111111111110010110';
+ LetterCodes[179] = '1111111111110010111';
+ LetterCodes[180] = '1111111111110010100';
+ LetterCodes[181] = '1111111111110010101';
+ LetterCodes[182] = '1111111111111101010';
+ LetterCodes[183] = '1111111111111101011';
+ LetterCodes[184] = '1111111111111101000';
+ LetterCodes[185] = '1111111111111101001';
+ LetterCodes[186] = '1111111111111101110';
+ LetterCodes[187] = '1111111111111101111';
+ LetterCodes[188] = '1111111111111101100';
+ LetterCodes[189] = '1111111111111101101';
+ LetterCodes[190] = '1111111111111100010';
+ LetterCodes[191] = '1111111111111100011';
+ LetterCodes[192] = '1111111111111100000';
+ LetterCodes[193] = '1111111111111100001';
+ LetterCodes[194] = '1111111111111100110';
+ LetterCodes[195] = '1111111111111100111';
+ LetterCodes[196] = '1111111111111100100';
+ LetterCodes[197] = '1111111111111100101';
+ LetterCodes[198] = '1111111111111111010';
+ LetterCodes[199] = '1111111111111111011';
+ LetterCodes[200] = '1111111111111111000';
+ LetterCodes[201] = '1111111111111111001';
+ LetterCodes[202] = '1111111111111111110';
+ LetterCodes[203] = '1111111111111111111';
+ LetterCodes[204] = '1111111111111111100';
+ LetterCodes[205] = '1111111111111111101';
+ LetterCodes[206] = '1111111111111110010';
+ LetterCodes[207] = '1111111111111110011';
+ LetterCodes[208] = '1111111111111110000';
+ LetterCodes[209] = '1111111111111110001';
+ LetterCodes[210] = '1111111111111110110';
+ LetterCodes[211] = '1111111111111110111';
+ LetterCodes[212] = '1111111111111110100';
+ LetterCodes[213] = '1111111111111110101';
+ LetterCodes[214] = '1111111111111001010';
+ LetterCodes[215] = '1111111111111001011';
+ LetterCodes[216] = '1111111111111001000';
+ LetterCodes[217] = '1111111111111001001';
+ LetterCodes[218] = '1111111111111001110';
+ LetterCodes[219] = '1111111111111001111';
+ LetterCodes[220] = '1111111111111001100';
+ LetterCodes[221] = '1111111111111001101';
+ LetterCodes[222] = '1111111111111000010';
+ LetterCodes[223] = '1111111111111000011';
+ LetterCodes[224] = '1111111111111000000';
+ LetterCodes[225] = '1111111111111000001';
+ LetterCodes[226] = '1111111111111000110';
+ LetterCodes[227] = '1111111111111000111';
+ LetterCodes[228] = '1111111111111000100';
+ LetterCodes[229] = '1111111111111000101';
+ LetterCodes[230] = '1111111111111011010';
+ LetterCodes[231] = '1111111111111011011';
+ LetterCodes[232] = '1111111111111011000';
+ LetterCodes[233] = '1111111111111011001';
+ LetterCodes[234] = '1111111111111011110';
+ LetterCodes[235] = '1111111111111011111';
+ LetterCodes[236] = '1111111111111011100';
+ LetterCodes[237] = '1111111111111011101';
+ LetterCodes[238] = '1111111111111010010';
+ LetterCodes[239] = '1111111111111010011';
+ LetterCodes[240] = '1111111111111010000';
+ LetterCodes[241] = '1111111111111010001';
+ LetterCodes[242] = '1111111111111010110';
+ LetterCodes[243] = '1111111111111010111';
+ LetterCodes[244] = '1111111111111010100';
+ LetterCodes[245] = '1111111111111010101';
+ LetterCodes[246] = '10111111111111010';
+ LetterCodes[247] = '10111111111111011';
+ LetterCodes[248] = '10111111111111000';
+ LetterCodes[249] = '10111111111111001';
+ LetterCodes[250] = '10111111111111110';
+ LetterCodes[251] = '10111111111111111';
+ LetterCodes[252] = '10111111111111100';
+ LetterCodes[253] = '10111111111111101';
+ LetterCodes[254] = '1111111111101110';
+ LetterCodes[255] = '1111111111101111';
+
+ // Build resulting data stream
+ // The bits string could get very large
+ var bits = "";
+ var bytes = ov.length + "$";
+ for (var i = 0; i < ov.length; i ++) {
+ // converts ASCII chars above 255 to a star (code 42) avoiding decoding failure
+ if (ov.charCodeAt(i) > 255) { bits += LetterCodes[42]; }
+ else { bits += LetterCodes[ov.charCodeAt(i)]; }
+ while (bits.length > 5) {
+ bytes += BitsToBytes(bits);
+ bits = bits.slice(6, bits.length);
+ }
+ }
+ bytes += BitsToBytes(bits);
+
+ bytes += encodingCharSet.charAt(encodingVersion);
+
+ return bytes;
+}
+
diff --git a/_assets/vendor/pgn4web/pgn-encoder.php b/_assets/vendor/pgn4web/pgn-encoder.php
new file mode 100644
index 0000000..5ac5f9c
--- /dev/null
+++ b/_assets/vendor/pgn4web/pgn-encoder.php
@@ -0,0 +1,317 @@
+ 255) { $bits = $bits . $LetterCodes[42]; }
+ else { $bits = $bits . $LetterCodes[ord(substr($ov, $i, 1))]; }
+ while (strlen($bits) > 5) {
+ $bytes = $bytes . BitsToBytes($bits);
+ $bits = substr($bits, 6);
+ }
+ }
+ $bytes = $bytes . BitsToBytes($bits);
+
+ $bytes = $bytes . substr($encodingCharSet, $encodingVersion, 1);
+
+ return $bytes;
+}
+
+?>
diff --git a/_assets/vendor/pgn4web/pgn-standard-proposed-supplement.txt b/_assets/vendor/pgn4web/pgn-standard-proposed-supplement.txt
new file mode 100644
index 0000000..bac4f82
--- /dev/null
+++ b/_assets/vendor/pgn4web/pgn-standard-proposed-supplement.txt
@@ -0,0 +1,358 @@
+Standard: Portable Game Notation Specification and Implementation Guide
+(Supplement)
+Revised: 8 September 2001
+Status: Final draft
+Authors: Alan Cowderoy (Palamede), Ben Bulsink (DGT Projects), Andrew Templeton
+(Palamede/Palview), Eric Bentzen (Enpassant.dk, Palamede), Mathias Feist
+(Chessbase), Victor Zakharov (Chess Assistant).
+Contact: alan@cowderoy.com
+
+1. Introduction
+
+PGNs combination of a formal specification for computer use with easy
+readability and manipulation by humans has firmly established it as the data
+format of choice for representing chess games. This is a major success and a
+tribute to the quality of the work done by the original authors.
+
+Steven Edwards, the author, appears unfortunately to be no longer involved with
+PGN and there is now no defined means of arbitrating and implementing proposed
+changes. There is also a huge body of software which implements the current
+standard and would break in various ways if it were changed.
+
+At the same time the increased use of DGT boards in major tournaments for the
+retransmission of live games has rendered one of the features that was planned
+for PGN but never implemented increasingly important, namely the possibility of
+encoding time information relating to each move.
+
+Without the possibility of encoding time information in PGN its usefulness in
+the retransmission of live games is significantly weakened forcing developpers
+either to resort to proprietary formats or to break the standard.
+
+Computer chess program authors are also now finding that they have no accepted
+way to encode such simple and recognised concepts as numeric position
+evaluations or search depth.
+
+Given this situation some have understandably set about defining wholly new XML
+based definitions for encoding chess games. While this work is interesting, as
+of today there is no widely accepted and supported XML schema.
+
+It thus seems important to us to attempt an incremental improvement to PGN
+intended to eliminate the functional weaknesses described above.
+
+This document proposes an extension to PGN designed to offer an immediate 'work
+around' solution to the problems outlined above.
+
+2. Design aims
+2.1 The enhancements must not break the existing standard.
+
+This rules out new syntactical elements. Steve Edwards himself proposed a format
+(BIF) that would have resolved these problems but it was never implemented and
+doing so now would break large quantities of software.
+
+2.2 The enhancements should maintain the ease of use and legibility so
+characteristic of PGN.
+
+This rules out very precise but possibly more computer readable formats in
+favour of clearer human readable ones.
+
+2.3 If new command structures are to be introduced they should be specified in
+such a way that they are usable for other extensions if needed.
+
+The intention here is to provide a generalised syntax that will enable other
+extensions rather than only solving one particular problem (time handling in our
+case).
+
+3. Proposals
+3.1 Introduction
+
+The only way to extend the syntax without breaking the standard is to embed the
+new command syntax into PGN comments. This is a kludge and such an obvious one
+that it was already suggested when Steve Edwards proposed the BIF format in
+1996. It is still the only option available.
+
+Apart from a general command syntax we propose several specific commands
+designed for the handling of time information.
+
+We also propose the addition of a tag to the header to handle the state of the
+"running clock" where the game is being transmitted live and two other optional
+tags designed to handle special cases where the clock start times are needed.
+
+These additions are not problematic as the standard concedes the possibility of
+adding new tags to the header (outside the mandatory seven tag roster)
+
+Interpreting time information for a game is either difficult or impossible if
+the time controls in force are not known. PGN has a TimeControl tag for this and
+it should be regarded as mandatory when time information is to be embedded into
+the pgn.
+
+3.2 A generalised format for embedding commands in comments.
+3.2.1 Position
+An embedded command may occur at any position in a standard PGN comment, ie
+between { } .
+For example:
+{Optional leading comments [%clk 1:05:23] optional trailing comments} where
+[%clk 1:05:23] is the embedded command string.
+
+3.2.2 Structure
+The command string is structured as follows.
+
+A leading tag of [%
+A command name consisting of one or more alphanumeric characters.
+A space character.
+Either a single parameter or a comma delimited list of parameter values.
+A closing tag of ]
+
+For example:
+[%clk 1:05:23]
+
+3.2.3 Opening delimiter
+The characters [% are redefined to indicate the start of a command sequence when
+found in between pgn comment tags.
+
+As all ASCII characters are legal in a comment string it is not possible to rely
+on any single character as an unambiguous opening delimiter. We have chosen to
+use [%. While this also could technicaly occur in some other context it seems
+highly unlikely.
+
+3.2.3 Commands
+
+Command names start immediately after the [%.
+They consist of one or more alphanumeric characters
+They are terminated by the first space character encountered.
+
+We are *not* proposing any fixed canonical list of commands. The idea is to
+describe a generalised command syntax, not to impose a particular set of
+commands.
+
+We *are* proposing a set of commands to deal with time handling. "clk" in the
+example above is the proposed command name for recording move times. See section
+4 for the detailed specification of this and other time related commands.
+
+In general software encountering an embedded command it does not understand
+should take no special action and pass the string through unchanged as part of
+the comment.
+
+For display purposes only presentation software, such as pgn readers, should by
+default strip out all commands before display in order to improve legibility.
+
+3.2.4 Parameters
+
+This parameter syntax is based on the epd opcode syntax described at 16.2.4 of
+the pgn spec.
+
+A command is followed by a single space and then either by a single operand or
+by a comma separated list of operands.
+
+An operand is either:
+i) a set containing any ascii characters except the comma and right hand square
+bracket
+or
+ii) a double quoted string containing a set of any ascii characters except the
+double quote.
+
+For instance:
+[%command 1:45:12,Nf6,"very interesting, but wrong"]
+
+This command has four operands, a time value, a san move value and a double
+quote delimitted string. Note that the quote delimitted string may contain
+commas.
+
+Commas are illegal in non quote delimitted strings because the comma serves as
+the operand list separator.
+
+Right hand square brackets are illegal in non quote delimitted strings because
+they terminate both the last operand and the command.
+
+We have thus departed from the epd opcode specification in two ways:
+i) The operand list is separated using a comma rather than a space.
+ii) Space characters are allowed in non quote delimited operands
+
+So it is possible to pass a full FEN string as an unquoted operand as in the
+example below.
+
+[%command "very tense start to the
+game",4r1k1/pp1b2r1/2n1pq1p/3p2pP/2pP2B1/P1P1Q3/2P2PPB/R4RK1 w - - 0 1,e4,d4]
+
+This command has four operands, the first is a double quote delimitted string,
+the second is a FEN, the third is e4 and the fourth is d4.
+
+3.2.5 Terminator
+The command is terminated by a single ] character.
+
+3.2.6 Multiple commands.
+A single comment tag may contain multiple embedded commands.
+For instance:
+{[%clk 0:00:07][%eval -6.05] White is toast}
+
+4. Time handling commands.
+4.1 Introduction.
+We propose the following commands for time handling The first is the command
+that DGT boards will be using to transmit times via pgn.
+
+The other commands are optional and cover times that can be derived from the
+clock time. They are technicaly redundant but may be usefull for highlighting
+aspects of the game and the players use of time.
+
+All these commands take one and only one parameter which is a time value in the
+format h:mm:ss (except for the mct command which requires hh:mm:ss)
+
+The comments containing the embedded commands are to be taken as referring to
+the move immediately preceding them.
+
+4.2 The clk command.
+
+{[%clk 1:55:21]}
+
+This is the time displayed on the players clock. It represents the time
+remaining to the next time control. It is proposed that future versions of
+software producing pgn from games played on DGT boards include this command
+after every move.
+
+The clk command is intended for the *automatic* recording of time values by
+digital clock/board combinations. It is not normaly intended for use with
+mechanical clocks which show a clock time rather than the time remaining to the
+next control.
+
+4.3 Elapsed Game Time : the egt command
+
+{[%egt 1:25:42]}
+
+The elapsed time that a player has used for all moves in the game up to that
+point.
+Takes one parameter in the format h:mm:ss
+
+4.4 Elapsed Move Time : the emt command
+
+{[%emt 0:05:42]}
+
+The elapsed time that a player used for the commented move.
+Takes one parameter in the format h:mm:ss
+
+4.5 Mechanical Clock Time : the mct command
+
+{[%mct 17:10:42]}
+The time actualy displayed on a mechanical clock. Notice that here the time
+format is hh:mm:ss.
+
+5. The "Running Clock"
+The syntax described above allows us to encode a move time for a *completed
+move*. This is all well and good but during transmission of a live game it can
+also be interesting to know the state of the clock of the player whose turn it
+is to move *but who has not yet done so*.
+
+5.1 The Clock tag
+We propose that this information should be encoded in a new header tag.
+
+[Clock "B/0:45:56"]
+
+As only one clock is running at a time only one tag is necessary.
+
+In the example above Blacks clock is running and is currently showing the time
+indicated by the string following the /.
+
+Clock is the name of the tag.
+It is followed by a string constructed as follows:
+The first character is either "W" (whites clock is running), "B" (blacks clock
+is running) or "N" (the clocks are stopped).
+This information is technicaly redundant as it could be calculated by looking at
+which side last moved. Encoding it here avoids this calculation and also covers
+the situation where a player forgets to switch the clocks. It also allows us to
+cover the admittedly rare case where the clocks are stopped.
+
+The second character is a "/" seperator.
+The rest of the string is a time in the format h:mm:ss which indicates the
+currently displayed clock time of the running clock. As for the clk command this
+represents the remaining time to the next time control.
+
+6. Clock Start Time.
+6.1 Introduction.
+Two optional tags are proposed to record the clock setting at the start of the
+play.
+While it may be helpfull to record normal clock start values here (as is done in
+the example below) they are mainly intended to cover the case where a game is
+adjourned and the displayed clock times at start of play are thus non standard.
+
+eg.
+[WhiteClock "1:07:00"]
+[BlackClock "0:56:00"]
+
+7. As explained above the existing pgn tag [TimeControl] (cf 9.6 and following
+of the standard) should be regarded as mandatory when move times are supplied.
+Clearly when manipulating time information about a game details of the time
+controls in use are vital.
+
+8. Example game.
+
+[Event "?"]
+[Site "Madrid"]
+[Date "1995.??.??"]
+[White "Beliavsky, A "]
+[Black "Timman, J "]
+[Result "1-0"]
+[ECO "E35"]
+[Round "2"]
+[TimeControl "40/7200:3600"]
+[WhiteClock "2:00:00"]
+[BlackClock "2:00:00"]
+[Clock "W/1:34:56"]
+
+1. d4 {[%clk 1:59:01]} Nf6 {[%clk 1:59:32] Timman hesitates slightly} 2. c4
+{[%clk 1:58:00]} e6 {[%clk 1:57:01]} 3. Nc3 {[%clk 1:37:00] Beliavsky clearly
+suprised here takes a full [%emt 0:20:00] on this move} Bb4 {[%clk 1:54:25]}
+
+Game notes:
+
+8.1. The time control is specified as 40 moves in two hours and then one hour to
+finish. This tag must be specified in order to permit calculation of such
+information as elapsed time since start of game. It is also particularly
+important that it be specified when fischer or bronstein time controls are used.
+
+8.2. In the example we have given the White and BlackClock tags but in this case
+this was redundant as the clocks were set as normal to show that two hours
+remained to the first time control. If the White and BlackClock tags are absent
+start times should be derived from the TimeControl tag and/or the Time tag,
+where they are specified they take precedence.
+
+8.3. The Clock tag, which is only relevant during live transmission of a game,
+here shows that it is whites turn to move and that he/she has 1 hour 34 minutes
+and 56 seconds remaining on their clock.
+
+8.4. PGN generated directly from DGT boards will have a clk command like the one
+following the first move after *all* subsequent moves.
+
+8.5. In this example we imagine that the pgn has been further edited to include
+additional text comments and commands (cf the %emt command after whites third
+move.)
+
+8.6. Notice that commands can appear at any point inside comments and that there
+may be multiple commands in a single comment.
+
+8.7. The Beliavsky/Timman game is real, all the rest is pure invention.
+
+9 Authors websites:
+DGT Projects: http://www.dgtprojects.com/
+Chess Base: http://www.chessbase.com/
+Chess Assistant: http://www.chessassistant.com/
+Palview: http://www.enpassant.dk/chess/palview/
+
+10. Thanks
+Many thanks to Axel Fritz and Robert Ericsson
+
+*additional notes:
+
+1. Cf Steve Edwards discussion of the planned implementation of BIF format here:
+http://groups.google.com/groups?hl=en&safe=off&ic=1&th=1fe06718d5ec89a5,20&seekm
+=4psfnl%24i5m%40darkstar.UCSC.EDU
+We ruled out the use of < > as delimiters specified in the BIF format because if
+this syntax is pasted into an html document then parsers will ignore the
+contents as an unrecognised tag. This is not the effect we want.
+
+2. While the seven tag roster is very precisely specified the PGN specification
+does envisage the specification of new optional tags. We have taken advantage of
+this to specify several new tags.
+
+Note also that there is already a [Time] tag - this denotes the time of the game
+start (and not anything else).
+
+3. For reference the current pgn standard is here
+http://www.clark.net/pub/pribut/standard.txt
diff --git a/_assets/vendor/pgn4web/pgn-standard.txt b/_assets/vendor/pgn4web/pgn-standard.txt
new file mode 100644
index 0000000..07149fd
--- /dev/null
+++ b/_assets/vendor/pgn4web/pgn-standard.txt
@@ -0,0 +1,2921 @@
+Standard: Portable Game Notation Specification and Implementation Guide
+
+Revised: 1994.03.12
+
+Authors: Interested readers of the Internet newsgroup rec.games.chess
+
+Coordinator: Steven J. Edwards (send comments to sje@world.std.com)
+
+
+0: Preface
+
+From the Tower of Babel story:
+
+"If now, while they are one people, all speaking the same language, they have
+started to do this, nothing will later stop them from doing whatever they
+propose to do."
+
+Genesis XI, v.6, _New American Bible_
+
+
+1: Introduction
+
+PGN is "Portable Game Notation", a standard designed for the representation of
+chess game data using ASCII text files. PGN is structured for easy reading and
+writing by human users and for easy parsing and generation by computer
+programs. The intent of the definition and propagation of PGN is to facilitate
+the sharing of public domain chess game data among chessplayers (both organic
+and otherwise), publishers, and computer chess researchers throughout the
+world.
+
+PGN is not intended to be a general purpose standard that is suitable for every
+possible use; no such standard could fill all conceivable requirements.
+Instead, PGN is proposed as a universal portable representation for data
+interchange. The idea is to allow the construction of a family of chess
+applications that can quickly and easily process chess game data using PGN for
+import and export among themselves.
+
+
+2: Chess data representation
+
+Computer usage among chessplayers has become quite common in recent years and a
+variety of different programs, both commercial and public domain, are used to
+generate, access, and propagate chess game data. Some of these programs are
+rather impressive; most are now well behaved in that they correctly follow the
+Laws of Chess and handle users' data with reasonable care. Unfortunately, many
+programs have had serious problems with several aspects of the external
+representation of chess game data. Sometimes these problems become more
+visible when a user attempts to move significant quantities of data from one
+program to another; if there has been no real effort to ensure portability of
+data, then the chances for a successful transfer are small at best.
+
+
+2.1: Data interchange incompatibility
+
+The reasons for format incompatibility are easy to understand. In fact, most
+of them are correlated with the same problems that have already been seen with
+commercial software offerings for other domains such as word processing,
+spreadsheets, fonts, and graphics. Sometimes a manufacturer deliberately
+designs a data format using encryption or some other secret, proprietary
+technique to "lock in" a customer. Sometimes a designer may produce a format
+that can be deciphered without too much difficulty, but at the same time
+publicly discourage third party software by claiming trade secret protection.
+Another software producer may develop a non-proprietary system, but it may work
+well only within the scope of a single program or application because it is not
+easily expandable. Finally, some other software may work very well for many
+purposes, but it uses symbols and language not easily understood by people or
+computers available to those outside the country of its development.
+
+
+2.2: Specification goals
+
+A specification for a portable game notation must observe the lessons of
+history and be able to handle probable needs of the future. The design
+criteria for PGN were selected to meet these needs. These criteria include:
+
+1) The details of the system must be publicly available and free of unnecessary
+complexity. Ideally, if the documentation is not available for some reason,
+typical chess software developers and users should be able to understand most
+of the data without the need for third party assistance.
+
+2) The details of the system must be non-proprietary so that users and software
+developers are unrestricted by concerns about infringing on intellectual
+property rights. The idea is to let chess programmers compete in a free market
+where customers may choose software based on their real needs and not based on
+artificial requirements created by a secret data format.
+
+3) The system must work for a variety of programs. The format should be such
+that it can be used by chess database programs, chess publishing programs,
+chess server programs, and chessplaying programs without being unnecessarily
+specific to any particular application class.
+
+4) The system must be easily expandable and scalable. The expansion ability
+must include handling data items that may not exist currently but could be
+expected to emerge in the future. (Examples: new opening classifications and
+new country names.) The system should be scalable in that it must not have any
+arbitrary restrictions concerning the quantity of stored data. Also, planned
+modes of expansion should either preserve earlier databases or at least allow
+for their automatic conversion.
+
+5) The system must be international. Chess software users are found in many
+countries and the system should be free of difficulties caused by conventions
+local to a given region.
+
+6) Finally, the system should handle the same kinds and amounts of data that
+are already handled by existing chess software and by print media.
+
+
+2.3: A sample PGN game
+
+Although its description may seem rather lengthy, PGN is actually fairly
+simple. A sample PGN game follows; it has most of the important features
+described in later sections of this document.
+
+[Event "F/S Return Match"]
+[Site "Belgrade, Serbia JUG"]
+[Date "1992.11.04"]
+[Round "29"]
+[White "Fischer, Robert J."]
+[Black "Spassky, Boris V."]
+[Result "1/2-1/2"]
+
+1. e4 e5 2. Nf3 Nc6 3. Bb5 a6 4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8. c3
+O-O 9. h3 Nb8 10. d4 Nbd7 11. c4 c6 12. cxb5 axb5 13. Nc3 Bb7 14. Bg5 b4 15.
+Nb1 h6 16. Bh4 c5 17. dxe5 Nxe4 18. Bxe7 Qxe7 19. exd6 Qf6 20. Nbd2 Nxd6 21.
+Nc4 Nxc4 22. Bxc4 Nb6 23. Ne5 Rae8 24. Bxf7+ Rxf7 25. Nxf7 Rxe1+ 26. Qxe1 Kxf7
+27. Qe3 Qg5 28. Qxg5 hxg5 29. b3 Ke6 30. a3 Kd6 31. axb4 cxb4 32. Ra5 Nd5 33.
+f3 Bc8 34. Kf2 Bf5 35. Ra7 g6 36. Ra6+ Kc5 37. Ke1 Nf4 38. g3 Nxh3 39. Kd2 Kb5
+40. Rd6 Kc5 41. Ra6 Nf2 42. g4 Bd3 43. Re6 1/2-1/2
+
+
+3: Formats: import and export
+
+There are two formats in the PGN specification. These are the "import" format
+and the "export" format. These are the two different ways of formatting the
+same PGN data according to its source. The details of the two formats are
+described throughout the following sections of this document.
+
+Other than formats, there is the additional topic of PGN presentation. While
+both PGN import and export formats are designed to be readable by humans, there
+is no recommendation that either of these be an ultimate mode of chess data
+presentation. Rather, software developers are urged to consider all of the
+various techniques at their disposal to enhance the display of chess data at
+the presentation level (i.e., highest level) of their programs. This means
+that the use of different fonts, character sizes, color, and other tools of
+computer aided interaction and publishing should be explored to provide a high
+quality presentation appropriate to the function of the particular program.
+
+
+3.1: Import format allows for manually prepared data
+
+The import format is rather flexible and is used to describe data that may have
+been prepared by hand, much like a source file for a high level programming
+language. A program that can read PGN data should be able to handle the
+somewhat lax import format.
+
+
+3.2: Export format used for program generated output
+
+The export format is rather strict and is used to describe data that is usually
+prepared under program control, something like a pretty printed source program
+reformatted by a compiler.
+
+
+3.2.1: Byte equivalence
+
+For a given PGN data file, export format representations generated by different
+PGN programs on the same computing system should be exactly equivalent, byte
+for byte.
+
+
+3.2.2: Archival storage and the newline character
+
+Export format should also be used for archival storage. Here, "archival"
+storage is defined as storage that may be accessed by a variety of computing
+systems. The only extra requirement for archival storage is that the newline
+character have a specific representation that is independent of its value for a
+particular computing system's text file usage. The archival representation of
+a newline is the ASCII control character LF (line feed, decimal value 10,
+hexadecimal value 0x0a).
+
+Sadly, there are some accidents of history that survive to this day that have
+baroque representations for a newline: multicharacter sequences, end-of-line
+record markers, start-of-line byte counts, fixed length records, and so forth.
+It is well beyond the scope of the PGN project to reconcile all of these to the
+unified world of ANSI C and the those enjoying the bliss of a single '\n'
+convention. Some systems may just not be able to handle an archival PGN text
+file with native text editors. In these cases, an indulgence of sorts is
+granted to use the local newline convention in non-archival PGN files for those
+text editors.
+
+
+3.2.3: Speed of processing
+
+Several parts of the export format deal with exact descriptions of line and
+field justification that are absent from the import format details. The main
+reason for these restrictions on the export format are to allow the
+construction of simple data translation programs that can easily scan PGN data
+without having to have a full chess engine or other complex parsing routines.
+The idea is to encourage chess software authors to always allow for at least a
+limited PGN reading capability. Even when a full chess engine parsing
+capability is available, it is likely to be at least two orders of magnitude
+slower than a simple text scanner.
+
+
+3.2.4: Reduced export format
+
+A PGN game represented using export format is said to be in "reduced export
+format" if all of the following hold: 1) it has no commentary, 2) it has only
+the standard seven tag roster identification information ("STR", see below), 3)
+it has no recursive annotation variations ("RAV", see below), and 4) it has no
+numeric annotation glyphs ("NAG", see below). Reduced export format is used
+for bulk storage of unannotated games. It represents a minimum level of
+standard conformance for a PGN exporting application.
+
+
+4: Lexicographical issues
+
+PGN data is composed of characters; non-overlapping contiguous sequences of
+characters form lexical tokens.
+
+
+4.1: Character codes
+
+PGN data is represented using a subset of the eight bit ISO 8859/1 (Latin 1)
+character set. ("ISO" is an acronym for the International Standards
+Organization.) This set is also known as ECMA-94 and is similar to other ISO
+Latin character sets. ISO 8859/1 includes the standard seven bit ASCII
+character set for the 32 control character code values from zero to 31. The 95
+printing character code values from 32 to 126 are also equivalent to seven bit
+ASCII usage. (Code value 127, the ASCII DEL control character, is a graphic
+character in ISO 8859/1; it is not used for PGN data representation.)
+
+The 32 ISO 8859/1 code values from 128 to 159 are non-printing control
+characters. They are not used for PGN data representation. The 32 code values
+from 160 to 191 are mostly non-alphabetic printing characters and their use for
+PGN data is discouraged as their graphic representation varies considerably
+among other ISO Latin sets. Finally, the 64 code values from 192 to 255 are
+mostly alphabetic printing characters with various diacritical marks; their use
+is encouraged for those languages that require such characters. The graphic
+representations of this last set of 64 characters is fairly constant for the
+ISO Latin family.
+
+Printing character codes outside of the seven bit ASCII range may only appear
+in string data and in commentary. They are not permitted for use in symbol
+construction.
+
+Because some PGN users' environments may not support presentation of non-ASCII
+characters, PGN game authors should refrain from using such characters in
+critical commentary or string values in game data that may be referenced in
+such environments. PGN software authors should have their programs handle such
+environments by displaying a question mark ("?") for non-ASCII character codes.
+This is an important point because there are many computing systems that can
+display eight bit character data, but the display graphics may differ among
+machines and operating systems from different manufacturers.
+
+Only four of the ASCII control characters are permitted in PGN import format;
+these are the horizontal and vertical tabs along with the linefeed and carriage
+return codes.
+
+The external representation of the newline character may differ among
+platforms; this is an acceptable variation as long as the details of the
+implementation are hidden from software implementors and users. When a choice
+is practical, the Unix "newline is linefeed" convention is preferred.
+
+
+4.2: Tab characters
+
+Tab characters, both horizontal and vertical, are not permitted in the export
+format. This is because the treatment of tab characters is highly dependent
+upon the particular software in use on the host computing system. Also, tab
+characters may not appear inside of string data.
+
+
+4.3: Line lengths
+
+PGN data are organized as simple text lines without any special bytes or
+markers for secondary record structure imposed by specific operating systems.
+Import format PGN text lines are limited to having a maximum of 255 characters
+per line including the newline character. Lines with 80 or more printing
+characters are strongly discouraged because of the difficulties experienced by
+common text editors with long lines.
+
+In some cases, very long tag values will require 80 or more columns, but these
+are relatively rare. An example of this is the "FEN" tag pair; it may have a
+long tag value, but this particular tag pair is only used to represent a game
+that doesn't start from the usual initial position.
+
+
+5: Commentary
+
+Comment text may appear in PGN data. There are two kinds of comments. The
+first kind is the "rest of line" comment; this comment type starts with a
+semicolon character and continues to the end of the line. The second kind
+starts with a left brace character and continues to the next right brace
+character. Comments cannot appear inside any token.
+
+Brace comments do not nest; a left brace character appearing in a brace comment
+loses its special meaning and is ignored. A semicolon appearing inside of a
+brace comment loses its special meaning and is ignored. Braces appearing
+inside of a semicolon comments lose their special meaning and are ignored.
+
+*** Export format representation of comments needs definition work.
+
+
+6: Escape mechanism
+
+There is a special escape mechanism for PGN data. This mechanism is triggered
+by a percent sign character ("%") appearing in the first column of a line; the
+data on the rest of the line is ignored by publicly available PGN scanning
+software. This escape convention is intended for the private use of software
+developers and researchers to embed non-PGN commands and data in PGN streams.
+
+A percent sign appearing in any other place other than the first position in a
+line does not trigger the escape mechanism.
+
+
+7: Tokens
+
+PGN character data is organized as tokens. A token is a contiguous sequence of
+characters that represents a basic semantic unit. Tokens may be separated from
+adjacent tokens by white space characters. (White space characters include
+space, newline, and tab characters.) Some tokens are self delimiting and do
+not require white space characters.
+
+A string token is a sequence of zero or more printing characters delimited by a
+pair of quote characters (ASCII decimal value 34, hexadecimal value 0x22). An
+empty string is represented by two adjacent quotes. (Note: an apostrophe is
+not a quote.) A quote inside a string is represented by the backslash
+immediately followed by a quote. A backslash inside a string is represented by
+two adjacent backslashes. Strings are commonly used as tag pair values (see
+below). Non-printing characters like newline and tab are not permitted inside
+of strings. A string token is terminated by its closing quote. Currently, a
+string is limited to a maximum of 255 characters of data.
+
+An integer token is a sequence of one or more decimal digit characters. It is
+a special case of the more general "symbol" token class described below.
+Integer tokens are used to help represent move number indications (see below).
+An integer token is terminated just prior to the first non-symbol character
+following the integer digit sequence.
+
+A period character (".") is a token by itself. It is used for move number
+indications (see below). It is self terminating.
+
+An asterisk character ("*") is a token by itself. It is used as one of the
+possible game termination markers (see below); it indicates an incomplete game
+or a game with an unknown or otherwise unavailable result. It is self
+terminating.
+
+The left and right bracket characters ("[" and "]") are tokens. They are used
+to delimit tag pairs (see below). Both are self terminating.
+
+The left and right parenthesis characters ("(" and ")") are tokens. They are
+used to delimit Recursive Annotation Variations (see below). Both are self
+terminating.
+
+The left and right angle bracket characters ("<" and ">") are tokens. They are
+reserved for future expansion. Both are self terminating.
+
+A Numeric Annotation Glyph ("NAG", see below) is a token; it is composed of a
+dollar sign character ("$") immediately followed by one or more digit
+characters. It is terminated just prior to the first non-digit character
+following the digit sequence.
+
+A symbol token starts with a letter or digit character and is immediately
+followed by a sequence of zero or more symbol continuation characters. These
+continuation characters are letter characters ("A-Za-z"), digit characters
+("0-9"), the underscore ("_"), the plus sign ("+"), the octothorpe sign ("#"),
+the equal sign ("="), the colon (":"), and the hyphen ("-"). Symbols are used
+for a variety of purposes. All characters in a symbol are significant. A
+symbol token is terminated just prior to the first non-symbol character
+following the symbol character sequence. Currently, a symbol is limited to a
+maximum of 255 characters in length.
+
+
+8: Parsing games
+
+A PGN database file is a sequential collection of zero or more PGN games. An
+empty file is a valid, although somewhat uninformative, PGN database.
+
+A PGN game is composed of two sections. The first is the tag pair section and
+the second is the movetext section. The tag pair section provides information
+that identifies the game by defining the values associated with a set of
+standard parameters. The movetext section gives the usually enumerated and
+possibly annotated moves of the game along with the concluding game termination
+marker. The chess moves themselves are represented using SAN (Standard
+Algebraic Notation), also described later in this document.
+
+
+8.1: Tag pair section
+
+The tag pair section is composed of a series of zero or more tag pairs.
+
+A tag pair is composed of four consecutive tokens: a left bracket token, a
+symbol token, a string token, and a right bracket token. The symbol token is
+the tag name and the string token is the tag value associated with the tag
+name. (There is a standard set of tag names and semantics described below.)
+The same tag name should not appear more than once in a tag pair section.
+
+A further restriction on tag names is that they are composed exclusively of
+letters, digits, and the underscore character. This is done to facilitate
+mapping of tag names into key and attribute names for use with general purpose
+database programs.
+
+For PGN import format, there may be zero or more white space characters between
+any adjacent pair of tokens in a tag pair.
+
+For PGN export format, there are no white space characters between the left
+bracket and the tag name, there are no white space characters between the tag
+value and the right bracket, and there is a single space character between the
+tag name and the tag value.
+
+Tag names, like all symbols, are case sensitive. All tag names used for
+archival storage begin with an upper case letter.
+
+PGN import format may have multiple tag pairs on the same line and may even
+have a tag pair spanning more than a single line. Export format requires each
+tag pair to appear left justified on a line by itself; a single empty line
+follows the last tag pair.
+
+Some tag values may be composed of a sequence of items. For example, a
+consultation game may have more than one player for a given side. When this
+occurs, the single character ":" (colon) appears between adjacent items.
+Because of this use as an internal separator in strings, the colon should not
+otherwise appear in a string.
+
+The tag pair format is designed for expansion; initially only strings are
+allowed as tag pair values. Tag value formats associated with the STR (Seven
+Tag Roster, see below) will not change; they will always be string values.
+However, there are long term plans to allow general list structures as tag
+values for non-STR tag pairs. Use of these expanded tag values will likely be
+restricted to special research programs. In all events, the top level
+structure of a tag pair remains the same: left bracket, tag name, tag value,
+and right bracket.
+
+
+8.1.1: Seven Tag Roster
+
+There is a set of tags defined for mandatory use for archival storage of PGN
+data. This is the STR (Seven Tag Roster). The interpretation of these tags is
+fixed as is the order in which they appear. Although the definition and use of
+additional tag names and semantics is permitted and encouraged when needed, the
+STR is the common ground that all programs should follow for public data
+interchange.
+
+For import format, the order of tag pairs is not important. For export format,
+the STR tag pairs appear before any other tag pairs. (The STR tag pairs must
+also appear in order; this order is described below). Also for export format,
+any additional tag pairs appear in ASCII order by tag name.
+
+The seven tag names of the STR are (in order):
+
+1) Event (the name of the tournament or match event)
+
+2) Site (the location of the event)
+
+3) Date (the starting date of the game)
+
+4) Round (the playing round ordinal of the game)
+
+5) White (the player of the white pieces)
+
+6) Black (the player of the black pieces)
+
+7) Result (the result of the game)
+
+A set of supplemental tag names is given later in this document.
+
+For PGN export format, a single blank line appears after the last of the tag
+pairs to conclude the tag pair section. This helps simple scanning programs to
+quickly determine the end of the tag pair section and the beginning of the
+movetext section.
+
+
+8.1.1.1: The Event tag
+
+The Event tag value should be reasonably descriptive. Abbreviations are to be
+avoided unless absolutely necessary. A consistent event naming should be used
+to help facilitate database scanning. If the name of the event is unknown, a
+single question mark should appear as the tag value.
+
+Examples:
+
+[Event "FIDE World Championship"]
+
+[Event "Moscow City Championship"]
+
+[Event "ACM North American Computer Championship"]
+
+[Event "Casual Game"]
+
+
+8.1.1.2: The Site tag
+
+The Site tag value should include city and region names along with a standard
+name for the country. The use of the IOC (International Olympic Committee)
+three letter names is suggested for those countries where such codes are
+available. If the site of the event is unknown, a single question mark should
+appear as the tag value. A comma may be used to separate a city from a region.
+No comma is needed to separate a city or region from the IOC country code. A
+later section of this document gives a list of three letter nation codes along
+with a few additions for "locations" not covered by the IOC.
+
+Examples:
+
+[Site "New York City, NY USA"]
+
+[Site "St. Petersburg RUS"]
+
+[Site "Riga LAT"]
+
+
+8.1.1.3: The Date tag
+
+The Date tag value gives the starting date for the game. (Note: this is not
+necessarily the same as the starting date for the event.) The date is given
+with respect to the local time of the site given in the Event tag. The Date
+tag value field always uses a standard ten character format: "YYYY.MM.DD". The
+first four characters are digits that give the year, the next character is a
+period, the next two characters are digits that give the month, the next
+character is a period, and the final two characters are digits that give the
+day of the month. If the any of the digit fields are not known, then question
+marks are used in place of the digits.
+
+Examples:
+
+[Date "1992.08.31"]
+
+[Date "1993.??.??"]
+
+[Date "2001.01.01"]
+
+
+8.1.1.4: The Round tag
+
+The Round tag value gives the playing round for the game. In a match
+competition, this value is the number of the game played. If the use of a
+round number is inappropriate, then the field should be a single hyphen
+character. If the round is unknown, a single question mark should appear as
+the tag value.
+
+Some organizers employ unusual round designations and have multipart playing
+rounds and sometimes even have conditional rounds. In these cases, a multipart
+round identifier can be made from a sequence of integer round numbers separated
+by periods. The leftmost integer represents the most significant round and
+succeeding integers represent round numbers in descending hierarchical order.
+
+Examples:
+
+[Round "1"]
+
+[Round "3.1"]
+
+[Round "4.1.2"]
+
+
+8.1.1.5: The White tag
+
+The White tag value is the name of the player or players of the white pieces.
+The names are given as they would appear in a telephone directory. The family
+or last name appears first. If a first name or first initial is available, it
+is separated from the family name by a comma and a space. Finally, one or more
+middle initials may appear. (Wherever a comma appears, the very next character
+should be a space. Wherever an initial appears, the very next character should
+be a period.) If the name is unknown, a single question mark should appear as
+the tag value.
+
+The intent is to allow meaningful ASCII sorting of the tag value that is
+independent of regional name formation customs. If more than one person is
+playing the white pieces, the names are listed in alphabetical order and are
+separated by the colon character between adjacent entries. A player who is
+also a computer program should have appropriate version information listed
+after the name of the program.
+
+The format used in the FIDE Rating Lists is appropriate for use for player name
+tags.
+
+Examples:
+
+[White "Tal, Mikhail N."]
+
+[White "van der Wiel, Johan"]
+
+[White "Acme Pawngrabber v.3.2"]
+
+[White "Fine, R."]
+
+
+8.1.1.6: The Black tag
+
+The Black tag value is the name of the player or players of the black pieces.
+The names are given here as they are for the White tag value.
+
+Examples:
+
+[Black "Lasker, Emmanuel"]
+
+[Black "Smyslov, Vasily V."]
+
+[Black "Smith, John Q.:Woodpusher 2000"]
+
+[Black "Morphy"]
+
+
+8.1.1.7: The Result tag
+
+The Result field value is the result of the game. It is always exactly the
+same as the game termination marker that concludes the associated movetext. It
+is always one of four possible values: "1-0" (White wins), "0-1" (Black wins),
+"1/2-1/2" (drawn game), and "*" (game still in progress, game abandoned, or
+result otherwise unknown). Note that the digit zero is used in both of the
+first two cases; not the letter "O".
+
+All possible examples:
+
+[Result "0-1"]
+
+[Result "1-0"]
+
+[Result "1/2-1/2"]
+
+[Result "*"]
+
+
+8.2: Movetext section
+
+The movetext section is composed of chess moves, move number indications,
+optional annotations, and a single concluding game termination marker.
+
+Because illegal moves are not real chess moves, they are not permitted in PGN
+movetext. They may appear in commentary, however. One would hope that illegal
+moves are relatively rare in games worthy of recording.
+
+
+8.2.1: Movetext line justification
+
+In PGN import format, tokens in the movetext do not require any specific line
+justification.
+
+In PGN export format, tokens in the movetext are placed left justified on
+successive text lines each of which has less than 80 printing characters. As
+many tokens as possible are placed on a line with the remainder appearing on
+successive lines. A single space character appears between any two adjacent
+symbol tokens on the same line in the movetext. As with the tag pair section,
+a single empty line follows the last line of data to conclude the movetext
+section.
+
+Neither the first or the last character on an export format PGN line is a
+space. (This may change in the case of commentary; this area is currently
+under development.)
+
+
+8.2.2: Movetext move number indications
+
+A move number indication is composed of one or more adjacent digits (an integer
+token) followed by zero or more periods. The integer portion of the indication
+gives the move number of the immediately following white move (if present) and
+also the immediately following black move (if present).
+
+
+8.2.2.1: Import format move number indications
+
+PGN import format does not require move number indications. It does not
+prohibit superfluous move number indications anywhere in the movetext as long
+as the move numbers are correct.
+
+PGN import format move number indications may have zero or more period
+characters following the digit sequence that gives the move number; one or more
+white space characters may appear between the digit sequence and the period(s).
+
+
+8.2.2.2: Export format move number indications
+
+There are two export format move number indication formats, one for use
+appearing immediately before a white move element and one for use appearing
+immediately before a black move element. A white move number indication is
+formed from the integer giving the fullmove number with a single period
+character appended. A black move number indication is formed from the integer
+giving the fullmove number with three period characters appended.
+
+All white move elements have a preceding move number indication. A black move
+element has a preceding move number indication only in two cases: first, if
+there is intervening annotation or commentary between the black move and the
+previous white move; and second, if there is no previous white move in the
+special case where a game starts from a position where Black is the active
+player.
+
+There are no other cases where move number indications appear in PGN export
+format.
+
+
+8.2.3: Movetext SAN (Standard Algebraic Notation)
+
+SAN (Standard Algebraic Notation) is a representation standard for chess moves
+using the ASCII Latin alphabet.
+
+Examples of SAN recorded games are found throughout most modern chess
+publications. SAN as presented in this document uses English language single
+character abbreviations for chess pieces, although this is easily changed in
+the source. English is chosen over other languages because it appears to be
+the most widely recognized.
+
+An alternative to SAN is FAN (Figurine Algebraic Notation). FAN uses miniature
+piece icons instead of single letter piece abbreviations. The two notations
+are otherwise identical.
+
+
+8.2.3.1: Square identification
+
+SAN identifies each of the sixty four squares on the chessboard with a unique
+two character name. The first character of a square identifier is the file of
+the square; a file is a column of eight squares designated by a single lower
+case letter from "a" (leftmost or queenside) up to and including "h" (rightmost
+or kingside). The second character of a square identifier is the rank of the
+square; a rank is a row of eight squares designated by a single digit from "1"
+(bottom side [White's first rank]) up to and including "8" (top side [Black's
+first rank]). The initial squares of some pieces are: white queen rook at a1,
+white king at e1, black queen knight pawn at b7, and black king rook at h8.
+
+
+8.2.3.2: Piece identification
+
+SAN identifies each piece by a single upper case letter. The standard English
+values: pawn = "P", knight = "N", bishop = "B", rook = "R", queen = "Q", and
+king = "K".
+
+The letter code for a pawn is not used for SAN moves in PGN export format
+movetext. However, some PGN import software disambiguation code may allow for
+the appearance of pawn letter codes. Also, pawn and other piece letter codes
+are needed for use in some tag pair and annotation constructs.
+
+It is admittedly a bit chauvinistic to select English piece letters over those
+from other languages. There is a slight justification in that English is a de
+facto universal second language among most chessplayers and program users. It
+is probably the best that can be done for now. A later section of this
+document gives alternative piece letters, but these should be used only for
+local presentation software and not for archival storage or for dynamic
+interchange among programs.
+
+
+8.2.3.3: Basic SAN move construction
+
+A basic SAN move is given by listing the moving piece letter (omitted for
+pawns) followed by the destination square. Capture moves are denoted by the
+lower case letter "x" immediately prior to the destination square; pawn
+captures include the file letter of the originating square of the capturing
+pawn immediately prior to the "x" character.
+
+SAN kingside castling is indicated by the sequence "O-O"; queenside castling is
+indicated by the sequence "O-O-O". Note that the upper case letter "O" is
+used, not the digit zero. The use of a zero character is not only incompatible
+with traditional text practices, but it can also confuse parsing algorithms
+which also have to understand about move numbers and game termination markers.
+Also note that the use of the letter "O" is consistent with the practice of
+having all chess move symbols start with a letter; also, it follows the
+convention that all non-pwn move symbols start with an upper case letter.
+
+En passant captures do not have any special notation; they are formed as if the
+captured pawn were on the capturing pawn's destination square. Pawn promotions
+are denoted by the equal sign "=" immediately following the destination square
+with a promoted piece letter (indicating one of knight, bishop, rook, or queen)
+immediately following the equal sign. As above, the piece letter is in upper
+case.
+
+
+8.2.3.4: Disambiguation
+
+In the case of ambiguities (multiple pieces of the same type moving to the same
+square), the first appropriate disambiguating step of the three following steps
+is taken:
+
+First, if the moving pieces can be distinguished by their originating files,
+the originating file letter of the moving piece is inserted immediately after
+the moving piece letter.
+
+Second (when the first step fails), if the moving pieces can be distinguished
+by their originating ranks, the originating rank digit of the moving piece is
+inserted immediately after the moving piece letter.
+
+Third (when both the first and the second steps fail), the two character square
+coordinate of the originating square of the moving piece is inserted
+immediately after the moving piece letter.
+
+Note that the above disambiguation is needed only to distinguish among moves of
+the same piece type to the same square; it is not used to distinguish among
+attacks of the same piece type to the same square. An example of this would be
+a position with two white knights, one on square c3 and one on square g1 and a
+vacant square e2 with White to move. Both knights attack square e2, and if
+both could legally move there, then a file disambiguation is needed; the
+(nonchecking) knight moves would be "Nce2" and "Nge2". However, if the white
+king were at square e1 and a black bishop were at square b4 with a vacant
+square d2 (thus an absolute pin of the white knight at square c3), then only
+one white knight (the one at square g1) could move to square e2: "Ne2".
+
+
+8.2.3.5: Check and checkmate indication characters
+
+If the move is a checking move, the plus sign "+" is appended as a suffix to
+the basic SAN move notation; if the move is a checkmating move, the octothorpe
+sign "#" is appended instead.
+
+Neither the appearance nor the absence of either a check or checkmating
+indicator is used for disambiguation purposes. This means that if two (or
+more) pieces of the same type can move to the same square the differences in
+checking status of the moves does not allieviate the need for the standard rank
+and file disabiguation described above. (Note that a difference in checking
+status for the above may occur only in the case of a discovered check.)
+
+Neither the checking or checkmating indicators are considered annotation as
+they do not communicate subjective information. Therefore, they are
+qualitatively different from move suffix annotations like "!" and "?".
+Subjective move annotations are handled using Numeric Annotation Glyphs as
+described in a later section of this document.
+
+There are no special markings used for double checks or discovered checks.
+
+There are no special markings used for drawing moves.
+
+
+8.2.3.6: SAN move length
+
+SAN moves can be as short as two characters (e.g., "d4"), or as long as seven
+characters (e.g., "Qa6xb7#", "fxg1=Q+"). The average SAN move length seen in
+realistic games is probably just fractionally longer than three characters. If
+the SAN rules seem complicated, be assured that the earlier notation systems of
+LEN (Long English Notation) and EDN (English Descriptive Notation) are much
+more complex, and that LAN (Long Algebraic Notation, the predecessor of SAN) is
+unnecessarily bulky.
+
+
+8.2.3.7: Import and export SAN
+
+PGN export format always uses the above canonical SAN to represent moves in the
+movetext section of a PGN game. Import format is somewhat more relaxed and it
+makes allowances for moves that do not conform exactly to the canonical format.
+However, these allowances may differ among different PGN reader programs. Only
+data appearing in export format is in all cases guaranteed to be importable
+into all PGN readers.
+
+There are a number of suggested guidelines for use with implementing PGN reader
+software for permitting non-canonical SAN move representation. The idea is to
+have a PGN reader apply various transformations to attempt to discover the move
+that is represented by non-canonical input. Some suggested transformations
+include: letter case remapping, capture indicator insertion, check indicator
+insertion, and checkmate indicator insertion.
+
+
+8.2.3.8: SAN move suffix annotations
+
+Import format PGN allows for the use of traditional suffix annotations for
+moves. There are exactly six such annotations available: "!", "?", "!!", "!?",
+"?!", and "??". At most one such suffix annotation may appear per move, and if
+present, it is always the last part of the move symbol.
+
+When exported, a move suffix annotation is translated into the corresponding
+Numeric Annotation Glyph as described in a later section of this document. For
+example, if the single move symbol "Qxa8?" appears in an import format PGN
+movetext, it would be replaced with the two adjacent symbols "Qxa8 $2".
+
+
+8.2.4: Movetext NAG (Numeric Annotation Glyph)
+
+An NAG (Numeric Annotation Glyph) is a movetext element that is used to
+indicate a simple annotation in a language independent manner. An NAG is
+formed from a dollar sign ("$") with a non-negative decimal integer suffix.
+The non-negative integer must be from zero to 255 in value.
+
+
+8.2.5: Movetext RAV (Recursive Annotation Variation)
+
+An RAV (Recursive Annotation Variation) is a sequence of movetext containing
+one or more moves enclosed in parentheses. An RAV is used to represent an
+alternative variation. The alternate move sequence given by an RAV is one that
+may be legally played by first unplaying the move that appears immediately
+prior to the RAV. Because the RAV is a recursive construct, it may be nested.
+
+*** The specification for import/export representation of RAV elements needs
+further development.
+
+
+8.2.6: Game Termination Markers
+
+Each movetext section has exactly one game termination marker; the marker
+always occurs as the last element in the movetext. The game termination marker
+is a symbol that is one of the following four values: "1-0" (White wins), "0-1"
+(Black wins), "1/2-1/2" (drawn game), and "*" (game in progress, result
+unknown, or game abandoned). Note that the digit zero is used in the above;
+not the upper case letter "O". The game termination marker appearing in the
+movetext of a game must match the value of the game's Result tag pair. (While
+the marker appears as a string in the Result tag, it appears as a symbol
+without quotes in the movetext.)
+
+
+9: Supplemental tag names
+
+The following tag names and their associated semantics are recommended for use
+for information not contained in the Seven Tag Roster.
+
+
+9.1: Player related information
+
+Note that if there is more than one player field in an instance of a player
+(White or Black) tag, then there will be corresponding multiple fields in any
+of the following tags. For example, if the White tag has the three field value
+"Jones:Smith:Zacharias" (a consultation game), then the WhiteTitle tag could
+have a value of "IM:-:GM" if Jones was an International Master, Smith was
+untitled, and Zacharias was a Grandmaster.
+
+
+9.1.1: Tags: WhiteTitle, BlackTitle
+
+These use string values such as "FM", "IM", and "GM"; these tags are used only
+for the standard abbreviations for FIDE titles. A value of "-" is used for an
+untitled player.
+
+
+9.1.2: Tags: WhiteElo, BlackElo
+
+These tags use integer values; these are used for FIDE Elo ratings. A value of
+"-" is used for an unrated player.
+
+
+9.1.3: Tags: WhiteUSCF, BlackUSCF
+
+These tags use integer values; these are used for USCF (United States Chess
+Federation) ratings. Similar tag names can be constructed for other rating
+agencies.
+
+
+9.1.4: Tags: WhiteNA, BlackNA
+
+These tags use string values; these are the e-mail or network addresses of the
+players. A value of "-" is used for a player without an electronic address.
+
+
+9.1.5: Tags: WhiteType, BlackType
+
+These tags use string values; these describe the player types. The value
+"human" should be used for a person while the value "program" should be used
+for algorithmic (computer) players.
+
+
+9.2: Event related information
+
+The following tags are used for providing additional information about the
+event.
+
+
+9.2.1: Tag: EventDate
+
+This uses a date value, similar to the Date tag field, that gives the starting
+date of the Event.
+
+
+9.2.2: Tag: EventSponsor
+
+This uses a string value giving the name of the sponsor of the event.
+
+
+9.2.3: Tag: Section
+
+This uses a string; this is used for the playing section of a tournament (e.g.,
+"Open" or "Reserve").
+
+
+9.2.4: Tag: Stage
+
+This uses a string; this is used for the stage of a multistage event (e.g.,
+"Preliminary" or "Semifinal").
+
+
+9.2.5: Tag: Board
+
+This uses an integer; this identifies the board number in a team event and also
+in a simultaneous exhibition.
+
+
+9.3: Opening information (locale specific)
+
+The following tag pairs are used for traditional opening names. The associated
+tag values will vary according to the local language in use.
+
+
+9.3.1: Tag: Opening
+
+This uses a string; this is used for the traditional opening name. This will
+vary by locale. This tag pair is associated with the use of the EPD opcode
+"v0" described in a later section of this document.
+
+
+9.3.2: Tag: Variation
+
+This uses a string; this is used to further refine the Opening tag. This will
+vary by locale. This tag pair is associated with the use of the EPD opcode
+"v1" described in a later section of this document.
+
+
+9.3.3: Tag: SubVariation
+
+This uses a string; this is used to further refine the Variation tag. This
+will vary by locale. This tag pair is associated with the use of the EPD
+opcode "v2" described in a later section of this document.
+
+
+9.4: Opening information (third party vendors)
+
+The following tag pairs are used for representing opening identification
+according to various third party vendors and organizations. References to
+these organizations does not imply any endorsement of them or any endorsement
+by them.
+
+
+9.4.1: Tag: ECO
+
+This uses a string of either the form "XDD" or the form "XDD/DD" where the "X"
+is a letter from "A" to "E" and the "D" positions are digits; this is used for
+an opening designation from the five volume _Encyclopedia of Chess Openings_.
+This tag pair is associated with the use of the EPD opcode "eco" described in a
+later section of this document.
+
+
+9.4.2: Tag: NIC
+
+This uses a string; this is used for an opening designation from the _New in
+Chess_ database. This tag pair is associated with the use of the EPD opcode
+"nic" described in a later section of this document.
+
+
+9.5: Time and date related information
+
+The following tags assist with further refinement of the time and data
+information associated with a game.
+
+
+9.5.1: Tag: Time
+
+This uses a time-of-day value in the form "HH:MM:SS"; similar to the Date tag
+except that it denotes the local clock time (hours, minutes, and seconds) of
+the start of the game. Note that colons, not periods, are used for field
+separators for the Time tag value. The value is taken from the local time
+corresponding to the location given in the Site tag pair.
+
+
+9.5.2: Tag: UTCTime
+
+This tag is similar to the Time tag except that the time is given according to
+the Universal Coordinated Time standard.
+
+
+9.5.3: Tag:; UTCDate
+
+This tag is similar to the Date tag except that the date is given according to
+the Universal Coordinated Time standard.
+
+
+9.6: Time control
+
+The follwing tag is used to help describe the time control used with the game.
+
+
+9.6.1: Tag: TimeControl
+
+This uses a list of one or more time control fields. Each field contains a
+descriptor for each time control period; if more than one descriptor is present
+then they are separated by the colon character (":"). The descriptors appear
+in the order in which they are used in the game. The last field appearing is
+considered to be implicitly repeated for further control periods as needed.
+
+There are six kinds of TimeControl fields.
+
+The first kind is a single question mark ("?") which means that the time
+control mode is unknown. When used, it is usually the only descriptor present.
+
+The second kind is a single hyphen ("-") which means that there was no time
+control mode in use. When used, it is usually the only descriptor present.
+
+The third Time control field kind is formed as two positive integers separated
+by a solidus ("/") character. The first integer is the number of moves in the
+period and the second is the number of seconds in the period. Thus, a time
+control period of 40 moves in 2 1/2 hours would be represented as "40/9000".
+
+The fourth TimeControl field kind is used for a "sudden death" control period.
+It should only be used for the last descriptor in a TimeControl tag value. It
+is sometimes the only descriptor present. The format consists of a single
+integer that gives the number of seconds in the period. Thus, a blitz game
+would be represented with a TimeControl tag value of "300".
+
+The fifth TimeControl field kind is used for an "incremental" control period.
+It should only be used for the last descriptor in a TimeControl tag value and
+is usually the only descriptor in the value. The format consists of two
+positive integers separated by a plus sign ("+") character. The first integer
+gives the minimum number of seconds allocated for the period and the second
+integer gives the number of extra seconds added after each move is made. So,
+an incremental time control of 90 minutes plus one extra minute per move would
+be given by "4500+60" in the TimeControl tag value.
+
+The sixth TimeControl field kind is used for a "sandclock" or "hourglass"
+control period. It should only be used for the last descriptor in a
+TimeControl tag value and is usually the only descriptor in the value. The
+format consists of an asterisk ("*") immediately followed by a positive
+integer. The integer gives the total number of seconds in the sandclock
+period. The time control is implemented as if a sandclock were set at the
+start of the period with an equal amount of sand in each of the two chambers
+and the players invert the sandclock after each move with a time forfeit
+indicated by an empty upper chamber. Electronic implementation of a physical
+sandclock may be used. An example sandclock specification for a common three
+minute egg timer sandclock would have a tag value of "*180".
+
+Additional TimeControl field kinds will be defined as necessary.
+
+
+9.7: Alternative starting positions
+
+There are two tags defined for assistance with describing games that did not
+start from the usual initial array.
+
+
+9.7.1: Tag: SetUp
+
+This tag takes an integer that denotes the "set-up" status of the game. A
+value of "0" indicates that the game has started from the usual initial array.
+A value of "1" indicates that the game started from a set-up position; this
+position is given in the "FEN" tag pair. This tag must appear for a game
+starting with a set-up position. If it appears with a tag value of "1", a FEN
+tag pair must also appear.
+
+
+9.7.2: Tag: FEN
+
+This tag uses a string that gives the Forsyth-Edwards Notation for the starting
+position used in the game. FEN is described in a later section of this
+document. If a SetUp tag appears with a tag value of "1", the FEN tag pair is
+also required.
+
+
+9.8: Game conclusion
+
+There is a single tag that discusses the conclusion of the game.
+
+
+9.8.1: Tag: Termination
+
+This takes a string that describes the reason for the conclusion of the game.
+While the Result tag gives the result of the game, it does not provide any
+extra information and so the Termination tag is defined for this purpose.
+
+Strings that may appear as Termination tag values:
+
+* "abandoned": abandoned game.
+
+* "adjudication": result due to third party adjudication process.
+
+* "death": losing player called to greater things, one hopes.
+
+* "emergency": game concluded due to unforeseen circumstances.
+
+* "normal": game terminated in a normal fashion.
+
+* "rules infraction": administrative forfeit due to losing player's failure to
+observe either the Laws of Chess or the event regulations.
+
+* "time forfeit": loss due to losing player's failure to meet time control
+requirements.
+
+* "unterminated": game not terminated.
+
+
+9.9: Miscellaneous
+
+These are tags that can be briefly described and that doon't fit well inother
+sections.
+
+
+9.9.1: Tag: Annotator
+
+This tag uses a name or names in the format of the player name tags; this
+identifies the annotator or annotators of the game.
+
+
+9.9.2: Tag: Mode
+
+This uses a string that gives the playing mode of the game. Examples: "OTB"
+(over the board), "PM" (paper mail), "EM" (electronic mail), "ICS" (Internet
+Chess Server), and "TC" (general telecommunication).
+
+
+9.9.3: Tag: PlyCount
+
+This tag takes a single integer that gives the number of ply (moves) in the
+game.
+
+
+10: Numeric Annotation Glyphs
+
+NAG zero is used for a null annotation; it is provided for the convenience of
+software designers as a placeholder value and should probably not be used in
+external PGN data.
+
+NAGs with values from 1 to 9 annotate the move just played.
+
+NAGs with values from 10 to 135 modify the current position.
+
+NAGs with values from 136 to 139 describe time pressure.
+
+Other NAG values are reserved for future definition.
+
+Note: the number assignments listed below should be considered preliminary in
+nature; they are likely to be changed as a result of reviewer feedback.
+
+NAG Interpretation
+--- --------------
+ 0 null annotation
+ 1 good move (traditional "!")
+ 2 poor move (traditional "?")
+ 3 very good move (traditional "!!")
+ 4 very poor move (traditional "??")
+ 5 speculative move (traditional "!?")
+ 6 questionable move (traditional "?!")
+ 7 forced move (all others lose quickly)
+ 8 singular move (no reasonable alternatives)
+ 9 worst move
+ 10 drawish position
+ 11 equal chances, quiet position
+ 12 equal chances, active position
+ 13 unclear position
+ 14 White has a slight advantage
+ 15 Black has a slight advantage
+ 16 White has a moderate advantage
+ 17 Black has a moderate advantage
+ 18 White has a decisive advantage
+ 19 Black has a decisive advantage
+ 20 White has a crushing advantage (Black should resign)
+ 21 Black has a crushing advantage (White should resign)
+ 22 White is in zugzwang
+ 23 Black is in zugzwang
+ 24 White has a slight space advantage
+ 25 Black has a slight space advantage
+ 26 White has a moderate space advantage
+ 27 Black has a moderate space advantage
+ 28 White has a decisive space advantage
+ 29 Black has a decisive space advantage
+ 30 White has a slight time (development) advantage
+ 31 Black has a slight time (development) advantage
+ 32 White has a moderate time (development) advantage
+ 33 Black has a moderate time (development) advantage
+ 34 White has a decisive time (development) advantage
+ 35 Black has a decisive time (development) advantage
+ 36 White has the initiative
+ 37 Black has the initiative
+ 38 White has a lasting initiative
+ 39 Black has a lasting initiative
+ 40 White has the attack
+ 41 Black has the attack
+ 42 White has insufficient compensation for material deficit
+ 43 Black has insufficient compensation for material deficit
+ 44 White has sufficient compensation for material deficit
+ 45 Black has sufficient compensation for material deficit
+ 46 White has more than adequate compensation for material deficit
+ 47 Black has more than adequate compensation for material deficit
+ 48 White has a slight center control advantage
+ 49 Black has a slight center control advantage
+ 50 White has a moderate center control advantage
+ 51 Black has a moderate center control advantage
+ 52 White has a decisive center control advantage
+ 53 Black has a decisive center control advantage
+ 54 White has a slight kingside control advantage
+ 55 Black has a slight kingside control advantage
+ 56 White has a moderate kingside control advantage
+ 57 Black has a moderate kingside control advantage
+ 58 White has a decisive kingside control advantage
+ 59 Black has a decisive kingside control advantage
+ 60 White has a slight queenside control advantage
+ 61 Black has a slight queenside control advantage
+ 62 White has a moderate queenside control advantage
+ 63 Black has a moderate queenside control advantage
+ 64 White has a decisive queenside control advantage
+ 65 Black has a decisive queenside control advantage
+ 66 White has a vulnerable first rank
+ 67 Black has a vulnerable first rank
+ 68 White has a well protected first rank
+ 69 Black has a well protected first rank
+ 70 White has a poorly protected king
+ 71 Black has a poorly protected king
+ 72 White has a well protected king
+ 73 Black has a well protected king
+ 74 White has a poorly placed king
+ 75 Black has a poorly placed king
+ 76 White has a well placed king
+ 77 Black has a well placed king
+ 78 White has a very weak pawn structure
+ 79 Black has a very weak pawn structure
+ 80 White has a moderately weak pawn structure
+ 81 Black has a moderately weak pawn structure
+ 82 White has a moderately strong pawn structure
+ 83 Black has a moderately strong pawn structure
+ 84 White has a very strong pawn structure
+ 85 Black has a very strong pawn structure
+ 86 White has poor knight placement
+ 87 Black has poor knight placement
+ 88 White has good knight placement
+ 89 Black has good knight placement
+ 90 White has poor bishop placement
+ 91 Black has poor bishop placement
+ 92 White has good bishop placement
+ 93 Black has good bishop placement
+ 84 White has poor rook placement
+ 85 Black has poor rook placement
+ 86 White has good rook placement
+ 87 Black has good rook placement
+ 98 White has poor queen placement
+ 99 Black has poor queen placement
+100 White has good queen placement
+101 Black has good queen placement
+102 White has poor piece coordination
+103 Black has poor piece coordination
+104 White has good piece coordination
+105 Black has good piece coordination
+106 White has played the opening very poorly
+107 Black has played the opening very poorly
+108 White has played the opening poorly
+109 Black has played the opening poorly
+110 White has played the opening well
+111 Black has played the opening well
+112 White has played the opening very well
+113 Black has played the opening very well
+114 White has played the middlegame very poorly
+115 Black has played the middlegame very poorly
+116 White has played the middlegame poorly
+117 Black has played the middlegame poorly
+118 White has played the middlegame well
+119 Black has played the middlegame well
+120 White has played the middlegame very well
+121 Black has played the middlegame very well
+122 White has played the ending very poorly
+123 Black has played the ending very poorly
+124 White has played the ending poorly
+125 Black has played the ending poorly
+126 White has played the ending well
+127 Black has played the ending well
+128 White has played the ending very well
+129 Black has played the ending very well
+130 White has slight counterplay
+131 Black has slight counterplay
+132 White has moderate counterplay
+133 Black has moderate counterplay
+134 White has decisive counterplay
+135 Black has decisive counterplay
+136 White has moderate time control pressure
+137 Black has moderate time control pressure
+138 White has severe time control pressure
+139 Black has severe time control pressure
+
+
+11: File names and directories
+
+File names chosen for PGN data should be both informative and portable. The
+directory names and arrangements should also be chosen for the same reasons and
+also for ease of navigation.
+
+Some of suggested file and directory names may be difficult or impossible to
+represent on certain computing systems. Use of appropriate conversion customs
+is encouraged.
+
+
+11.1: File name suffix for PGN data
+
+The use of the file suffix ".pgn" is encouraged for ASCII text files containing
+PGN data.
+
+
+11.2: File name formation for PGN data for a specific player
+
+PGN games for a specific player should have a file name consisting of the
+player's last name followed by the ".pgn" suffix.
+
+
+11.3: File name formation for PGN data for a specific event
+
+PGN games for a specific event should have a file name consisting of the
+event's name followed by the ".pgn" suffix.
+
+
+11.4: File name formation for PGN data for chronologically ordered games
+
+PGN data files used for chronologically ordered (oldest first) archives use
+date information as file name root strings. A file containing all the PGN
+games for a given year would have an eight character name in the format
+"YYYY.pgn". A file containing PGN data for a given month would have a ten
+character name in the format "YYYYMM.pgn". Finally, a file for PGN games for a
+single day would have a twelve character name in the format "YYYYMMDD.pgn".
+Large files are split into smaller files as needed.
+
+As game files are commonly arranged by chronological order, games with missing
+or incomplete Date tag pair data are to be avoided. Any question mark
+characters in a Date tag value will be treated as zero digits for collation
+within a file and also for file naming.
+
+Large quantities of PGN data arranged by chronological order should be
+organized into hierarchical directories. A directory containing all PGN data
+for a given year would have a four character name in the format "YYYY";
+directories containing PGN files for a given month would have a six character
+name in the format "YYYYMM".
+
+
+11.5: Suggested directory tree organization
+
+A suggested directory arrangement for ftp sites and CD-ROM distributions:
+
+* PGN: master directory of the PGN subtree (pub/chess/Game-Databases/PGN)
+
+* PGN/Events: directory of PGN files, each for a specific event
+
+* PGN/Events/News: news and status of the event collection
+
+* PGN/Events/ReadMe: brief description of the local directory contents
+
+* PGN/MGR: directory of the Master Games Repository subtree
+
+* PGN/MGR/News: news and status of the entire PGN/MGR subtree
+
+* PGN/MGR/ReadMe: brief description of the local directory contents
+
+* PGN/MGR/YYYY: directory of games or subtrees for the year YYYY
+
+* PGN/MGR/YYYY/ReadMe: description of local directory for year YYYY
+
+* PGN/MGR/YYYY/News: news and status for year YYYY data
+
+* PGN/News: news and status of the entire PGN subtree
+
+* PGN/Players: directory of PGN files, each for a specific player
+
+* PGN/Players/News: news and status of the player collection
+
+* PGN/Players/ReadMe: brief description of the local directory contents
+
+* PGN/ReadMe: brief description of the local directory contents
+
+* PGN/Standard: the PGN standard (this document)
+
+* PGN/Tools: software utilities that access PGN data
+
+
+12: PGN collating sequence
+
+There is a standard sorting order for PGN games within a file. This collation
+is based on eight keys; these are the seven tag values of the STR and also the
+movetext itself.
+
+The first (most important, primary key) is the Date tag. Earlier dated games
+appear prior to games played at a later date. This field is sorted by
+ascending numeric value first with the year, then the month, and finally the
+day of the month. Query characters used for unknown date digit values will be
+treated as zero digit characters for ordering comparison.
+
+The second key is the Event tag. This is sorted in ascending ASCII order.
+
+The third key is the Site tag. This is sorted in ascending ASCII order.
+
+The fourth key is the Round tag. This is sorted in ascending numeric order
+based on the value of the integer used to denote the playing round. A query or
+hyphen used for the round is ordered before any integer value. A query
+character is ordered before a hyphen character.
+
+The fifth key is the White tag. This is sorted in ascending ASCII order.
+
+The sixth key is the Black tag. This is sorted in ascending ASCII order.
+
+The seventh key is the Result tag. This is sorted in ascending ASCII order.
+
+The eighth key is the movetext itself. This is sorted in ascending ASCII order
+with the entire text including spaces and newline characters.
+
+
+13: PGN software
+
+This section describes some PGN software that is either currently available or
+expected to be available in the near future. The entries are presented in
+rough chronological order of their being made known to the PGN standard
+coordinator. Authors of PGN capable software are encouraged to contact the
+coordinator (e-mail address listed near the start of this document) so that the
+information may be included here in this section.
+
+In addition to the PGN standard, there are two more chess standards of interest
+to the chess software community. These are the FEN standard (Forsyth-Edwards
+Notation) for position notation and the EPD standard (Extended Position
+Description) for comprehensive position description for automated interprogram
+processing. These are described in a later section of this document.
+
+Some PGN software is freeware and can be gotten from ftp sites and other
+sources. Other PGN software is payware and appears as part of commercial
+chessplaying programs and chess database managers. Those who are interested in
+the propagation of the PGN standard are encouraged to support manufacturers of
+chess software that use the standard. If a particular vendor does not offer
+PGN compatibility, it is likely that a few letters to them along with a copy of
+this specification may help them decide to include PGN support in their next
+release.
+
+The staff at the University of Oklahoma at Norman (USA) have graciously
+provided an ftp site (chess.uoknor.edu) for the storage of chess related data
+and programs. Because file names change over time, those accessing the site
+are encouraged to first retrieve the file "pub/chess/ls-lR.gz" for a current
+listing. A scan of this listing will also help locate versions of PGN programs
+for machine types and operating systems other than those listed below. Further
+information about this archive can be gotten from its administrator, Chris
+Petroff (chris@uoknor.edu).
+
+For European users, the kind staff at the University of Hamburg (Germany) have
+provided the ftp site ftp.math.uni-hamburg.de; this carries a daily mirror of
+the pub/chess directory at the chess.uoknor.edu site.
+
+
+13.1: The SAN Kit
+
+The "SAN Kit" is an ANSI C source chess programming toolkit available for free
+from the ftp site chess.uoknor.edu in the directory pub/chess/Unix as the file
+"SAN.tar.gz" (a gzip tar archive). This kit contains code for PGN import and
+export and can be used to "regularize" PGN data into reduced export format by
+use of its "tfgg" command. The SAN Kit also supports FEN I/O. Code from this
+kit is freely redistributable for anyone as long as future distribution is
+unhindered for everyone. The SAN Kit is undergoing continuous development,
+although dates of future deliveries are quite difficult to predict and releases
+sometimes appear months apart. Suggestions and comments should be directed to
+its author, Steven J. Edwards (sje@world.std.com).
+
+
+13.2: pgnRead
+
+The program "pgnRead" runs under MS Windows 3.1 and provides an interactive
+graphical user interface for scanning PGN data files. This program includes a
+colorful figurine chessboard display and scrolling controls for game and game
+text selection. It is available from the chess.uoknor.edu ftp site in the
+pub/chess/DOS directory; several versions are available with names of the form
+"pgnrd**.exe"; the latest at this writing is "PGNRD130.EXE". Suggestions and
+comments should be directed to its author, Keith Fuller (keithfx@aol.com).
+
+
+13.3: mail2pgn/GIICS
+
+The program "mail2pgn" produces a PGN version of chess game data generated by
+the ICS (Internet Chess Server). It can be found at the chess.uoknor.edu ftp
+site in the pub/chess/DOS directory as the file "mail2pgn.zip" A C language
+version is in the directory pub/chess/Unix as the file "mail2pgn.c".
+Suggestions and comments should be directed to its author, John Aronson
+(aronson@helios.ece.arizona.edu). This code has been reportedly incorporated
+into the GIICS (Graphical Interface for the ICS); suggestions and comments
+should be directed to its author, Tony Acero (ace3@midway.uchicago.edu).
+
+There is a report that mail2pgn has been superseded by the newer program
+"MV2PGN" described below.
+
+
+13.4: XBoard
+
+"XBoard" is a comprehensive chess utility running under the X Window System
+that provides a graphical user interface in a portable manner. A new version
+now handles PGN data. It is available from the chess.uoknor.edu ftp site in
+the pub/chess/X directory as the file "xboard-3.0.pl9.tar.gz". Suggestions and
+comments should be directed to its author, Tim Mann (mann@src.dec.com).
+
+
+13.5: cupgn
+
+The program "cupgn" converts game data stored in the ChessBase format into PGN.
+It is available from the chess.uoknor.edu ftp site in the
+pub/chess/Game-Databases/CBUFF directory as the file "cupgn.tar.gz". Another
+version is in the directory pub/chess/DOS as the file "cupgn120.exe".
+Suggestions and comments should be directed to its author, Anjo Anjewierden
+(anjo@swi.psy.uva.nl).
+
+
+13.6: Zarkov
+
+The current version (3.0) of the commercial chessplaying program "Zarkov" can
+read and write games using PGN. This program can also use the EPD standard for
+communication with other EPD capable programs. Historically, Zarkov is the
+very first program to use EPD. Suggestions and comments should be directed to
+its author, John Stanback (jhs@icbdfcs1.fc.hp.com).
+
+A vendor for North America is:
+
+ International Chess Enterprises
+ P.O. Box 19457
+ Seattle, WA 98109
+ USA
+ (800) 262-4277
+
+A vendor for Europe is:
+
+ Gambit-Soft
+ Feckenhauser Strasse 27
+ D-78628 Rottweil
+ GERMANY
+ 49-741-21573
+
+
+13.7: Chess Assistant
+
+The upcoming version of the multifunction commercial database program "Chess
+Assistant" will be able to use the PGN standard as an import and export option.
+There is a report of a freeware program, "PGN2CA", that will convert PGN
+databases into Chess Assistant format. For more information, the contact is
+Victor Zakharov, one of the members of the Chess Assistant development team
+(VICTOR@ldis.cs.msu.su).
+
+A vendor for North America is:
+
+ International Chess Enterprises
+ P.O. Box 19457
+ Seattle, WA 98109
+ USA
+ (800) 262-4277
+
+
+13.8: BOOKUP
+
+The MS-DOS edition of the multifunction commercial program BOOKUP, version 8.1,
+is able to use the EPD standard for communication with other EPD capable
+programs. It may also be PGN capable as well.
+
+The BOOKUP 8.1.1 Addenda notes dated 1993.12.17 provide comprehensive
+information on how to use EPD in conjunction with "analyst" programs such as
+Zarkov and HIARCS. Specifically, the search and evaluation abilities of an
+analyst program are combined with the information organization abilities of the
+BOOKUP database program to provide position scoring. This is done by first
+having BOOKUP export a database in EPD format, then having an analyst program
+annotate each EPD record with a numeric score, and then having BOOKUP import
+the changed EPD file. BOOKUP can then apply minimaxing to the imported
+database; this results in scores from terminal positions being propagated back
+to earlier positions and even back to moves from the starting array.
+
+For some reason, BOOKUP calls this process "backsolving", but it's really just
+standard minimaxing. In any case, it's a good example of how different
+programs from different authors performing different types of tasks can be
+integrated by use of a common, non-proprietary standard. This allows for a new
+set of powerful features that are beyond the capabilities of any one of the
+individual component programs.
+
+BOOKUP allows for some customizing of EPD actions. One such customization is
+to require the positional evaluations to follow the EPD standard; this means
+that the score is always given from the viewpoint of the active player. This
+is explained more fully in the section on the "ce" (centipawn evaluation)
+opcode in the EPD description in a later section of this document. To ensure
+that BOOKUP handles the centipawn evaluations in the "right" way, the EPD
+setting "Positive for White" must be set to "N". This makes BOOKUP work
+correctly with Zarkov and with all other programs that use the "right"
+centipawn evaluation convention. There is an apparent problem with HIARCS that
+requires this option to be set to "Y"; but this really means that, if true,
+HIARCS needs to be adjusted to use the "right" centipawn evaluation convention.
+
+A vendor in North America is:
+
+ BOOKUP
+ 2763 Kensington Place West
+ Columbus, OH 43202
+ USA
+ (800) 949-5445
+ (614) 263-7219
+
+
+13.9: HIARCS
+
+The current version (2.1) of the commercial chessplaying program "HIARCS" is
+able to use the EPD standard for communication with other EPD capable programs.
+It may also be PGN capable as well. More details will appear here as they
+become available.
+
+A vendor in North America is:
+
+ HIARCS
+ c/o BOOKUP
+ 2763 Kensington Place West
+ Columbus, OH 43202
+ USA
+ (800) 949-5445
+ (614) 263-7219
+
+
+13.10: Deja Vu
+
+The chess database "Deja Vu" from ChessWorks is a PGN compatible collection of
+over 300,000 games. It is available only on CD-ROM and is scheduled for
+release in 1994.05 with periodic revisions thereafter. The introductory price
+is US$329. For further information, the authors are John Crayton and Eric
+Schiller and they can be contacted via e-mail (chesswks@netcom.com).
+
+
+13.11: MV2PGN
+
+The program "MV2PGN" can be used to convert game data generated by both current
+and older versions of the GIICS (Graphical Interface - Internet Chess Server).
+The program is included in the self extracting archive available from
+chess.uoknor.edu in the directory pub/chess/DOS as the file "ics2pgn.exe".
+Source code is also included. This program is reported to supersede the older
+"mail2pgn" and was needed due to a change in ICS recording format in late 1993.
+For further information about MV2PGN, the contact person is Gary Bastin
+(gbastin@x102a.ess.harris.com).
+
+
+13.12: The Hansen utilities (cb2pgn, nic2pgn, pgn2cb, pgn2nic)
+
+The Hansen utilities are used to convert among various chess data
+representation formats. The PGN related programs include: "cb2pgn.exe"
+(convert ChessBase to PGN), "nic2pgn.exe" (convert NIC to PGN), "pgn2cb.exe"
+(convert PGN to ChessBase), and "pgn2nic.exe" (convert PGN to NIC).
+
+The ChessBase related utilities (cb2pgn/pgn2cb) are found at chess.uoknor.edu
+in the pub/chess/Game-Databases/ChessBase directory.
+
+The NIC related utilities (nic2pgn/pgn2nic) are found at chess.uoknor.edu in
+the pub/chess/Game-Databases/NIC directory.
+
+For further information about the Hansen utilities, the contact person is the
+author, Carsten Hansen (ch0506@hdc.hha.dk).
+
+
+13.13: Slappy the Database
+
+"Slappy the Database" is a commercial chess database and translation program
+scheduled for release no sooner than late 1994. It is a low cost utility with
+a simple character interface intended for those who want a supported product
+but who do not need (or cannot afford) a comprehensive, feature-laden program
+with a graphical user interface. Slappy's two most important features are its
+batch processing ability and its full implementation of each and every standard
+described in this document. Versions of Slappy the Database will be provided
+for various platforms including: Intel 386/486 Unix, Apple Macintosh, and
+MS-DOS.
+
+Slappy may also be useful to those who have a full feature program who also
+need to run time consuming chess database tasks on a spare computer.
+
+Suggestions and comments should be directed to its author, Steven J. Edwards
+(sje@world.std.com). More details will appear here as they become available.
+
+
+13.14: CBASCII
+
+"CBASCII" is a general utility for converting chess data between ChessBase
+format and ASCII representations. It has PGN capability, and it is available
+from the chess.uoknor.edu ftp site in the pub/chess/DOS directory as the file
+"cba1_2.zip". The contact person is the program's author, Andy Duplain
+(duplain@btcs.bt.co.uk).
+
+
+13.15: ZZZZZZ
+
+"ZZZZZZ" is a chessplaying program, complete with source, that also includes
+some database functions. A recent version is reported to have both PGN and EPD
+capabilities. It is available from the chess.uoknor.edu ftp site in the
+pub/chess/Unix directory as the file "zzzzzz-3.2b1.tar.gz". The contact person
+is its author, Gijsbert Wiesenecker (wiesenecker@sara.nl).
+
+
+13.16: icsconv
+
+The program "icsconv" can be used to convert Internet Chess Server games, both
+old and new format, to PGN. It is available from the chess.uoknor.edu site in
+the pub/chess/Game-Databases/PGN/Tools directory as the file "icsconv.exe".
+The contact person is the author, Kevin Nomura (chow@netcom.com).
+
+
+13.17: CHESSOP (CHESSOPN/CHESSOPG)
+
+CHESSOP is an openings database and viewing tool with support for reading PGN
+games. It runs under MS-DOS and displays positions rather than games. For
+each position, both good and bad moves are listed with appropriate annotation.
+Transpositions are handled as well. The distributed database contains over
+100,000 positions covering all the common openings. Users can feed in their
+own PGN data as well. CHESSOP takes 3 Mbyte of hard disk, costs US$39 and can
+be obtained from:
+
+ CHESSX Software
+ 12 Bluebell Close
+ Glenmore Park
+ AUSTRALIA 2745.
+
+The ideas behind CHESSOP can be seen in CHESSOPN (alias CHESSOPG), a free
+version on the ICS server which has a reduced openings database (25,000
+positions) and no PGN or transposition support but is otherwise the same as
+CHESSOP. (These are the files "chessopg.zip" in the directory pub/chess/DOS at
+the chess.uoknor.edu ftp site.)
+
+
+13.18: CAT2PGN
+
+The program "CAT2PGN" is a utility that translates data from the format used by
+Chess Assistant into PGN. It is available from the chess.uoknor.edu ftp site.
+The contact person for CAT2PGN is its author, David Myers
+(myers@frodo.biochem.duke.edu).
+
+
+13.19: pgn2opg
+
+The utility "pgn2opg" can be used to convert PGN files into a text format used
+by the "CHESSOPG" program mentioned above. Although it does not perform any
+semantic analysis on PGN input, it has been demonstrated to handle known
+correct PGN input properly. The file can be found in the pub/chess/PGN/Tools
+directory at the chess.uoknor.edu ftp site. For more information, the author
+is David Barnes (djb@ukc.ac.uk).
+
+
+14: PGN data archives
+
+The primary PGN data archive repository is located at the ftp site
+chess.uoknor.edu as the directory "pub/chess/Game-Databases/PGN". It is
+organized according to the description given in section C.5 of this document.
+The European site ftp.math.uni-hamburg.de is also reported to carry a regularly
+updated copy of the repository.
+
+
+15: International Olympic Committee country codes
+
+International Olympic Committee country codes are employed for Site nation
+information because of their traditional use with the reporting of
+international sporting events. Due to changes in geography and linguistic
+custom, some of the following may be incorrect or outdated. Corrections and
+extensions should be sent via e-mail to the PGN coordinator whose address
+listed near the start of this document.
+
+AFG: Afghanistan
+AIR: Aboard aircraft
+ALB: Albania
+ALG: Algeria
+AND: Andorra
+ANG: Angola
+ANT: Antigua
+ARG: Argentina
+ARM: Armenia
+ATA: Antarctica
+AUS: Australia
+AZB: Azerbaijan
+BAN: Bangladesh
+BAR: Bahrain
+BHM: Bahamas
+BEL: Belgium
+BER: Bermuda
+BIH: Bosnia and Herzegovina
+BLA: Belarus
+BLG: Bulgaria
+BLZ: Belize
+BOL: Bolivia
+BRB: Barbados
+BRS: Brazil
+BRU: Brunei
+BSW: Botswana
+CAN: Canada
+CHI: Chile
+COL: Columbia
+CRA: Costa Rica
+CRO: Croatia
+CSR: Czechoslovakia
+CUB: Cuba
+CYP: Cyprus
+DEN: Denmark
+DOM: Dominican Republic
+ECU: Ecuador
+EGY: Egypt
+ENG: England
+ESP: Spain
+EST: Estonia
+FAI: Faroe Islands
+FIJ: Fiji
+FIN: Finland
+FRA: France
+GAM: Gambia
+GCI: Guernsey-Jersey
+GEO: Georgia
+GER: Germany
+GHA: Ghana
+GRC: Greece
+GUA: Guatemala
+GUY: Guyana
+HAI: Haiti
+HKG: Hong Kong
+HON: Honduras
+HUN: Hungary
+IND: India
+IRL: Ireland
+IRN: Iran
+IRQ: Iraq
+ISD: Iceland
+ISR: Israel
+ITA: Italy
+IVO: Ivory Coast
+JAM: Jamaica
+JAP: Japan
+JRD: Jordan
+JUG: Yugoslavia
+KAZ: Kazakhstan
+KEN: Kenya
+KIR: Kyrgyzstan
+KUW: Kuwait
+LAT: Latvia
+LEB: Lebanon
+LIB: Libya
+LIC: Liechtenstein
+LTU: Lithuania
+LUX: Luxembourg
+MAL: Malaysia
+MAU: Mauritania
+MEX: Mexico
+MLI: Mali
+MLT: Malta
+MNC: Monaco
+MOL: Moldova
+MON: Mongolia
+MOZ: Mozambique
+MRC: Morocco
+MRT: Mauritius
+MYN: Myanmar
+NCG: Nicaragua
+NET: The Internet
+NIG: Nigeria
+NLA: Netherlands Antilles
+NLD: Netherlands
+NOR: Norway
+NZD: New Zealand
+OST: Austria
+PAK: Pakistan
+PAL: Palestine
+PAN: Panama
+PAR: Paraguay
+PER: Peru
+PHI: Philippines
+PNG: Papua New Guinea
+POL: Poland
+POR: Portugal
+PRC: People's Republic of China
+PRO: Puerto Rico
+QTR: Qatar
+RIN: Indonesia
+ROM: Romania
+RUS: Russia
+SAF: South Africa
+SAL: El Salvador
+SCO: Scotland
+SEA: At Sea
+SEN: Senegal
+SEY: Seychelles
+SIP: Singapore
+SLV: Slovenia
+SMA: San Marino
+SPC: Aboard spacecraft
+SRI: Sri Lanka
+SUD: Sudan
+SUR: Surinam
+SVE: Sweden
+SWZ: Switzerland
+SYR: Syria
+TAI: Thailand
+TMT: Turkmenistan
+TRK: Turkey
+TTO: Trinidad and Tobago
+TUN: Tunisia
+UAE: United Arab Emirates
+UGA: Uganda
+UKR: Ukraine
+UNK: Unknown
+URU: Uruguay
+USA: United States of America
+UZB: Uzbekistan
+VEN: Venezuela
+VGB: British Virgin Islands
+VIE: Vietnam
+VUS: U.S. Virgin Islands
+WLS: Wales
+YEM: Yemen
+YUG: Yugoslavia
+ZAM: Zambia
+ZIM: Zimbabwe
+ZRE: Zaire
+
+
+16: Additional chess data standards
+
+While PGN is used for game storage, there are other data representation
+standards for other chess related purposes. Two important standards are FEN
+and EPD, both described in this section.
+
+
+16.1: FEN
+
+FEN is "Forsyth-Edwards Notation"; it is a standard for describing chess
+positions using the ASCII character set.
+
+A single FEN record uses one text line of variable length composed of six data
+fields. The first four fields of the FEN specification are the same as the
+first four fields of the EPD specification.
+
+A text file composed exclusively of FEN data records should have a file name
+with the suffix ".fen".
+
+
+16.1.1: History
+
+FEN is based on a 19th century standard for position recording designed by the
+Scotsman David Forsyth, a newspaper journalist. The original Forsyth standard
+has been slightly extended for use with chess software by Steven Edwards with
+assistance from commentators on the Internet. This new standard, FEN, was
+first implemented in Edwards' SAN Kit.
+
+
+16.1.2: Uses for a position notation
+
+Having a standard position notation is particularly important for chess
+programmers as it allows them to share position databases. For example, there
+exist standard position notation databases with many of the classical benchmark
+tests for chessplaying programs, and by using a common position notation format
+many hours of tedious data entry can be saved. Additionally, a position
+notation can be useful for page layout programs and for confirming position
+status for e-mail competition.
+
+Many interesting chess problem sets represented using FEN can be found at the
+chess.uoknor.edu ftp site in the directory pub/chess/SAN_testsuites.
+
+
+16.1.3: Data fields
+
+FEN specifies the piece placement, the active color, the castling availability,
+the en passant target square, the halfmove clock, and the fullmove number.
+These can all fit on a single text line in an easily read format. The length
+of a FEN position description varies somewhat according to the position. In
+some cases, the description could be eighty or more characters in length and so
+may not fit conveniently on some displays. However, these positions aren't too
+common.
+
+A FEN description has six fields. Each field is composed only of non-blank
+printing ASCII characters. Adjacent fields are separated by a single ASCII
+space character.
+
+
+16.1.3.1: Piece placement data
+
+The first field represents the placement of the pieces on the board. The board
+contents are specified starting with the eighth rank and ending with the first
+rank. For each rank, the squares are specified from file a to file h. White
+pieces are identified by uppercase SAN piece letters ("PNBRQK") and black
+pieces are identified by lowercase SAN piece letters ("pnbrqk"). Empty squares
+are represented by the digits one through eight; the digit used represents the
+count of contiguous empty squares along a rank. A solidus character "/" is
+used to separate data of adjacent ranks.
+
+
+16.1.3.2: Active color
+
+The second field represents the active color. A lower case "w" is used if
+White is to move; a lower case "b" is used if Black is the active player.
+
+
+16.1.3.3: Castling availability
+
+The third field represents castling availability. This indicates potential
+future castling that may of may not be possible at the moment due to blocking
+pieces or enemy attacks. If there is no castling availability for either side,
+the single character symbol "-" is used. Otherwise, a combination of from one
+to four characters are present. If White has kingside castling availability,
+the uppercase letter "K" appears. If White has queenside castling
+availability, the uppercase letter "Q" appears. If Black has kingside castling
+availability, the lowercase letter "k" appears. If Black has queenside
+castling availability, then the lowercase letter "q" appears. Those letters
+which appear will be ordered first uppercase before lowercase and second
+kingside before queenside. There is no white space between the letters.
+
+
+16.1.3.4: En passant target square
+
+The fourth field is the en passant target square. If there is no en passant
+target square then the single character symbol "-" appears. If there is an en
+passant target square then is represented by a lowercase file character
+immediately followed by a rank digit. Obviously, the rank digit will be "3"
+following a white pawn double advance (Black is the active color) or else be
+the digit "6" after a black pawn double advance (White being the active color).
+
+An en passant target square is given if and only if the last move was a pawn
+advance of two squares. Therefore, an en passant target square field may have
+a square name even if there is no pawn of the opposing side that may
+immediately execute the en passant capture.
+
+
+16.1.3.5: Halfmove clock
+
+The fifth field is a nonnegative integer representing the halfmove clock. This
+number is the count of halfmoves (or ply) since the last pawn advance or
+capturing move. This value is used for the fifty move draw rule.
+
+
+16.1.3.6: Fullmove number
+
+The sixth and last field is a positive integer that gives the fullmove number.
+This will have the value "1" for the first move of a game for both White and
+Black. It is incremented by one immediately after each move by Black.
+
+
+16.1.4: Examples
+
+Here's the FEN for the starting position:
+
+rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
+
+And after the move 1. e4:
+
+rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq e3 0 1
+
+And then after 1. ... c5:
+
+rnbqkbnr/pp1ppppp/8/2p5/4P3/8/PPPP1PPP/RNBQKBNR w KQkq c6 0 2
+
+And then after 2. Nf3:
+
+rnbqkbnr/pp1ppppp/8/2p5/4P3/5N2/PPPP1PPP/RNBQKB1R b KQkq - 1 2
+
+For two kings on their home squares and a white pawn on e2 (White to move) with
+thirty eight full moves played with five halfmoves since the last pawn move or
+capture:
+
+4k3/8/8/8/8/8/4P3/4K3 w - - 5 39
+
+
+16.2: EPD
+
+EPD is "Extended Position Description"; it is a standard for describing chess
+positions along with an extended set of structured attribute values using the
+ASCII character set. It is intended for data and command interchange among
+chessplaying programs. It is also intended for the representation of portable
+opening library repositories.
+
+A single EPD uses one text line of variable length composed of four data field
+followed by zero or more operations. The four fields of the EPD specification
+are the same as the first four fields of the FEN specification.
+
+A text file composed exclusively of EPD data records should have a file name
+with the suffix ".epd".
+
+
+16.2.1: History
+
+EPD is based in part on the earlier FEN standard; it has added extensions for
+use with opening library preparation and also for general data and command
+interchange among advanced chess programs. EPD was developed by John Stanback
+and Steven Edwards; its first implementation is in Stanback's master strength
+chessplaying program Zarkov.
+
+
+16.2.2: Uses for an extended position notation
+
+Like FEN, EPD can also be used for general position description. However,
+unlike FEN, EPD is designed to be expandable by the addition of new operations
+that provide new functionality as needs arise.
+
+Many interesting chess problem sets represented using EPD can be found at the
+chess.uoknor.edu ftp site in the directory pub/chess/SAN_testsuites.
+
+
+16.2.3: Data fields
+
+EPD specifies the piece placement, the active color, the castling availability,
+and the en passant target square of a position. These can all fit on a single
+text line in an easily read format. The length of an EPD position description
+varies somewhat according to the position and any associated operations. In
+some cases, the description could be eighty or more characters in length and so
+may not fit conveniently on some displays. However, most EPD descriptions pass
+among programs only and these are not usually seen by program users.
+
+(Note: due to the likelihood of future expansion of EPD, implementors are
+encouraged to have their programs handle EPD text lines of up to 1024
+characters long.)
+
+Each EPD data field is composed only of non-blank printing ASCII characters.
+Adjacent data fields are separated by a single ASCII space character.
+
+
+16.2.3.1: Piece placement data
+
+The first field represents the placement of the pieces on the board. The board
+contents are specified starting with the eighth rank and ending with the first
+rank. For each rank, the squares are specified from file a to file h. White
+pieces are identified by uppercase SAN piece letters ("PNBRQK") and black
+pieces are identified by lowercase SAN piece letters ("pnbrqk"). Empty squares
+are represented by the digits one through eight; the digit used represents the
+count of contiguous empty squares along a rank. A solidus character "/" is
+used to separate data of adjacent ranks.
+
+
+16.2.3.2: Active color
+
+The second field represents the active color. A lower case "w" is used if
+White is to move; a lower case "b" is used if Black is the active player.
+
+
+16.2.3.3: Castling availability
+
+The third field represents castling availability. This indicates potential
+future castling that may or may not be possible at the moment due to blocking
+pieces or enemy attacks. If there is no castling availability for either side,
+the single character symbol "-" is used. Otherwise, a combination of from one
+to four characters are present. If White has kingside castling availability,
+the uppercase letter "K" appears. If White has queenside castling
+availability, the uppercase letter "Q" appears. If Black has kingside castling
+availability, the lowercase letter "k" appears. If Black has queenside
+castling availability, then the lowercase letter "q" appears. Those letters
+which appear will be ordered first uppercase before lowercase and second
+kingside before queenside. There is no white space between the letters.
+
+
+16.2.3.4: En passant target square
+
+The fourth field is the en passant target square. If there is no en passant
+target square then the single character symbol "-" appears. If there is an en
+passant target square then is represented by a lowercase file character
+immediately followed by a rank digit. Obviously, the rank digit will be "3"
+following a white pawn double advance (Black is the active color) or else be
+the digit "6" after a black pawn double advance (White being the active color).
+
+An en passant target square is given if and only if the last move was a pawn
+advance of two squares. Therefore, an en passant target square field may have
+a square name even if there is no pawn of the opposing side that may
+immediately execute the en passant capture.
+
+
+16.2.4: Operations
+
+An EPD operation is composed of an opcode followed by zero or more operands and
+is concluded by a semicolon.
+
+Multiple operations are separated by a single space character. If there is at
+least one operation present in an EPD line, it is separated from the last
+(fourth) data field by a single space character.
+
+
+16.2.4.1: General format
+
+An opcode is an identifier that starts with a letter character and may be
+followed by up to fourteen more characters. Each additional character may be a
+letter or a digit or the underscore character.
+
+An operand is either a set of contiguous non-white space printing characters or
+a string. A string is a set of contiguous printing characters delimited by a
+quote character at each end. A string value must have less than 256 bytes of
+data.
+
+If at least one operand is present in an operation, there is a single space
+between the opcode and the first operand. If more than one operand is present
+in an operation, there is a single blank character between every two adjacent
+operands. If there are no operands, a semicolon character is appended to the
+opcode to mark the end of the operation. If any operands appear, the last
+operand has an appended semicolon that marks the end of the operation.
+
+Any given opcode appears at most once per EPD record. Multiple operations in a
+single EPD record should appear in ASCII order of their opcode names
+(mnemonics). However, a program reading EPD records may allow for operations
+not in ASCII order by opcode mnemonics; the semantics are the same in either
+case.
+
+Some opcodes that allow for more than one operand may have special ordering
+requirements for the operands. For example, the "pv" (predicted variation)
+opcode requires its operands (moves) to appear in the order in which they would
+be played. All other opcodes that allow for more than one operand should have
+operands appearing in ASCII order. An example of the latter set is the "bm"
+(best move[s]) opcode; its operands are moves that are all immediately playable
+from the current position.
+
+Some opcodes require one or more operands that are chess moves. These moves
+should be represented using SAN. If a different representation is used, there
+is no guarantee that the EPD will be read correctly during subsequent
+processing.
+
+Some opcodes require one or more operands that are integers. Some opcodes may
+require that an integer operand must be within a given range; the details are
+described in the opcode list given below. A negative integer is formed with a
+hyphen (minus sign) preceding the integer digit sequence. An optional plus
+sign may be used for indicating a non-negative value, but such use is not
+required and is indeed discouraged.
+
+Some opcodes require one or more operands that are floating point numbers.
+Some opcodes may require that a floating point operand must be within a given
+range; the details are described in the opcode list given below. A floating
+point operand is constructed from an optional sign character ("+" or "-"), a
+digit sequence (with at least one digit), a radix point (always "."), and a
+final digit sequence (with at least one digit).
+
+
+16.2.4.2: Opcode mnemonics
+
+An opcode mnemonic used for archival storage and for interprogram communication
+starts with a lower case letter and is composed of only lower case letters,
+digits, and the underscore character (i.e., no upper case letters). These
+mnemonics will also all be at least two characters in length.
+
+Opcode mnemonics used only by a single program or an experimental suite of
+programs should start with an upper case letter. This is so they may be easily
+distinguished should they be inadvertently be encountered by other programs.
+When a such a "private" opcode be demonstrated to be widely useful, it should
+be brought into the official list (appearing below) in a lower case form.
+
+If a given program does not recognize a particular opcode, that operation is
+simply ignored; it is not signaled as an error.
+
+
+16.2.5: Opcode list
+
+The opcodes are listed here in ASCII order of their mnemonics. Suggestions for
+new opcodes should be sent to the PGN standard coordinator listed near the
+start of this document.
+
+
+16.2.5.1: Opcode "acn": analysis count: nodes
+
+The opcode "acn" takes a single non-negative integer operand. It is used to
+represent the number of nodes examined in an analysis. Note that the value may
+be quite large for some extended searches and so use of (at least) a long (four
+byte) representation is suggested.
+
+
+16.2.5.2: Opcode "acs": analysis count: seconds
+
+The opcode "acs" takes a single non-negative integer operand. It is used to
+represent the number of seconds used for an analysis. Note that the value may
+be quite large for some extended searches and so use of (at least) a long (four
+byte) representation is suggested.
+
+
+16.2.5.3: Opcode "am": avoid move(s)
+
+The opcode "am" indicates a set of zero or more moves, all immediately playable
+from the current position, that are to be avoided in the opinion of the EPD
+writer. Each operand is a SAN move; they appear in ASCII order.
+
+
+16.2.5.4: Opcode "bm": best move(s)
+
+The opcode "bm" indicates a set of zero or more moves, all immediately playable
+from the current position, that are judged to the best available by the EPD
+writer. Each operand is a SAN move; they appear in ASCII order.
+
+
+16.2.5.5: Opcode "c0": comment (primary, also "c1" though "c9")
+
+The opcode "c0" (lower case letter "c", digit character zero) indicates a top
+level comment that applies to the given position. It is the first of ten
+ranked comments, each of which has a mnemonic formed from the lower case letter
+"c" followed by a single decimal digit. Each of these opcodes takes either a
+single string operand or no operand at all.
+
+This ten member comment family of opcodes is intended for use as descriptive
+commentary for a complete game or game fragment. The usual processing of these
+opcodes are as follows:
+
+1) At the beginning of a game (or game fragment), a move sequence scanning
+program initializes each element of its set of ten comment string registers to
+be null.
+
+2) As the EPD record for each position in the game is processed, the comment
+operations are interpreted from left to right. (Actually, all operations in n
+EPD record are interpreted from left to right.) Because operations appear in
+ASCII order according to their opcode mnemonics, opcode "c0" (if present) will
+be handled prior to all other opcodes, then opcode "c1" (if present), and so
+forth until opcode "c9" (if present).
+
+3) The processing of opcode "cN" (0 <= N <= 9) involves two steps. First, all
+comment string registers with an index equal to or greater than N are set to
+null. (This is the set "cN" though "c9".) Second, and only if a string
+operand is present, the value of the corresponding comment string register is
+set equal to the string operand.
+
+
+16.2.5.6: Opcode "ce": centipawn evaluation
+
+The opcode "ce" indicates the evaluation of the indicated position in centipawn
+units. It takes a single operand, an optionally signed integer that gives an
+evaluation of the position from the viewpoint of the active player; i.e., the
+player with the move. Positive values indicate a position favorable to the
+moving player while negative values indicate a position favorable to the
+passive player; i.e., the player without the move. A centipawn evaluation
+value close to zero indicates a neutral positional evaluation.
+
+Values are restricted to integers that are equal to or greater than -32767 and
+are less than or equal to 32766.
+
+A value greater than 32000 indicates the availability of a forced mate to the
+active player. The number of plies until mate is given by subtracting the
+evaluation from the value 32767. Thus, a winning mate in N fullmoves is a mate
+in ((2 * N) - 1) halfmoves (or ply) and has a corresponding centipawn
+evaluation of (32767 - ((2 * N) - 1)). For example, a mate on the move (mate
+in one) has a centipawn evaluation of 32766 while a mate in five has a
+centipawn evaluation of 32758.
+
+A value less than -32000 indicates the availability of a forced mate to the
+passive player. The number of plies until mate is given by subtracting the
+evaluation from the value -32767 and then negating the result. Thus, a losing
+mate in N fullmoves is a mate in (2 * N) halfmoves (or ply) and has a
+corresponding centipawn evaluation of (-32767 + (2 * N)). For example, a mate
+after the move (losing mate in one) has a centipawn evaluation of -32765 while
+a losing mate in five has a centipawn evaluation of -32757.
+
+A value of -32767 indicates an illegal position. A stalemate position has a
+centipawn evaluation of zero as does a position drawn due to insufficient
+mating material. Any other position known to be a certain forced draw also has
+a centipawn evaluation of zero.
+
+
+16.2.5.7: Opcode "dm": direct mate fullmove count
+
+The "dm" opcode is used to indicate the number of fullmoves until checkmate is
+to be delivered by the active color for the indicated position. It always
+takes a single operand which is a positive integer giving the fullmove count.
+For example, a position known to be a "mate in three" would have an operation
+of "dm 3;" to indicate this.
+
+This opcode is intended for use with problem sets composed of positions
+requiring direct mate answers as solutions.
+
+
+16.2.5.8: Opcode "draw_accept": accept a draw offer
+
+The opcode "draw_accept" is used to indicate that a draw offer made after the
+move that lead to the indicated position is accepted by the active player.
+This opcode takes no operands.
+
+
+16.2.5.9: Opcode "draw_claim": claim a draw
+
+The opcode "draw_claim" is used to indicate claim by the active player that a
+draw exists. The draw is claimed because of a third time repetition or because
+of the fifty move rule or because of insufficient mating material. A supplied
+move (see the opcode "sm") is also required to appear as part of the same EPD
+record. The draw_claim opcode takes no operands.
+
+
+16.2.5.10: Opcode "draw_offer": offer a draw
+
+The opcode "draw_offer" is used to indicate that a draw is offered by the
+active player. A supplied move (see the opcode "sm") is also required to
+appear as part of the same EPD record; this move is considered played from the
+indicated position. The draw_offer opcode takes no operands.
+
+
+16.2.5.11: Opcode "draw_reject": reject a draw offer
+
+The opcode "draw_reject" is used to indicate that a draw offer made after the
+move that lead to the indicated position is rejected by the active player.
+This opcode takes no operands.
+
+
+16.2.5.12: Opcode "eco": _Encyclopedia of Chess Openings_ opening code
+
+The opcode "eco" is used to associate an opening designation from the
+_Encyclopedia of Chess Openings_ taxonomy with the indicated position. The
+opcode takes either a single string operand (the ECO opening name) or no
+operand at all. If an operand is present, its value is associated with an
+"ECO" string register of the scanning program. If there is no operand, the ECO
+string register of the scanning program is set to null.
+
+The usage is similar to that of the "ECO" tag pair of the PGN standard.
+
+
+16.2.5.13: Opcode "fmvn": fullmove number
+
+The opcode "fmvn" represents the fullmove n umber associated with the position.
+It always takes a single operand that is the positive integer value of the move
+number.
+
+This opcode is used to explicitly represent the fullmove number in EPD that is
+present by default in FEN as the sixth field. Fullmove number information is
+usually omitted from EPD because it does not affect move generation (commonly
+needed for EPD-using tasks) but it does affect game notation (commonly needed
+for FEN-using tasks). Because of the desire for space optimization for large
+EPD files, fullmove numbers were dropped from EPD's parent FEN. The halfmove
+clock information was similarly dropped.
+
+
+16.2.5.14: Opcode "hmvc": halfmove clock
+
+The opcode "hmvc" represents the halfmove clock associated with the position.
+The halfmove clock of a position is equal to the number of plies since the last
+pawn move or capture. This information is used to implement the fifty move
+draw rule. It always takes a single operand that is the non-negative integer
+value of the halfmove clock.
+
+This opcode is used to explicitly represent the halfmove clock in EPD that is
+present by default in FEN as the fifth field. Halfmove clock information is
+usually omitted from EPD because it does not affect move generation (commonly
+needed for EPD-using tasks) but it does affect game termination issues
+(commonly needed for FEN-using tasks). Because of the desire for space
+optimization for large EPD files, halfmove clock values were dropped from EPD's
+parent FEN. The fullmove number information was similarly dropped.
+
+
+16.2.5.15: Opcode "id": position identification
+
+The opcode "id" is used to provide a simple identifying label for the indicated
+position. It takes a single string operand.
+
+This opcode is intended for use with test suites used for measuring
+chessplaying program strength. An example "id" operand for the seven hundred
+fifty seventh position of the one thousand one problems in Reinfeld's _1001
+Winning Chess Sacrifices and Combinations_ would be "WCSAC.0757" while the
+fifteenth position in the twenty four problem Bratko-Kopec test suite would
+have an "id" operand of "BK.15".
+
+
+16.2.5.16: Opcode "nic": _New In Chess_ opening code
+
+The opcode "nic" is used to associate an opening designation from the _New In
+Chess_ taxonomy with the indicated position. The opcode takes either a single
+string operand (the NIC opening name) or no operand at all. If an operand is
+present, its value is associated with an "NIC" string register of the scanning
+program. If there is no operand, the NIC string register of the scanning
+program is set to null.
+
+The usage is similar to that of the "NIC" tag pair of the PGN standard.
+
+
+16.2.5.17: Opcode "noop": no operation
+
+The "noop" opcode is used to indicate no operation. It takes zero or more
+operands, each of which may be of any type. The operation involves no
+processing. It is intended for use by developers for program testing purposes.
+
+
+16.2.5.18: Opcode "pm": predicted move
+
+The "pm" opcode is used to provide a single predicted move for the indicated
+position. It has exactly one operand, a move playable from the position. This
+move is judged by the EPD writer to represent the best move available to the
+active player.
+
+If a non-empty "pv" (predicted variation) line of play is also present in the
+same EPD record, the first move of the predicted variation is the same as the
+predicted move.
+
+The "pm" opcode is intended for use as a general "display hint" mechanism.
+
+
+16.2.5.19: Opcode "pv": predicted variation
+
+The "pv" opcode is used to provide a predicted variation for the indicated
+position. It has zero or more operands which represent a sequence of moves
+playable from the position. This sequence is judged by the EPD writer to
+represent the best play available.
+
+If a "pm" (predicted move) operation is also present in the same EPD record,
+the predicted move is the same as the first move of the predicted variation.
+
+
+16.2.5.20: Opcode "rc": repetition count
+
+The "rc" opcode is used to indicate the number of occurrences of the indicated
+position. It takes a single, positive integer operand. Any position,
+including the initial starting position, is considered to have an "rc" value of
+at least one. A value of three indicates a candidate for a draw claim by the
+position repetition rule.
+
+
+16.2.5.21: Opcode "resign": game resignation
+
+The opcode "resign" is used to indicate that the active player has resigned the
+game. This opcode takes no operands.
+
+
+16.2.5.22: Opcode "sm": supplied move
+
+The "sm" opcode is used to provide a single supplied move for the indicated
+position. It has exactly one operand, a move playable from the position. This
+move is the move to be played from the position.
+
+The "sm" opcode is intended for use to communicate the most recent played move
+in an active game. It is used to communicate moves between programs in
+automatic play via a network. This includes correspondence play using e-mail
+and also programs acting as network front ends to human players.
+
+
+16.2.5.23: Opcode "tcgs": telecommunication: game selector
+
+The "tcgs" opcode is one of the telecommunication family of opcodes used for
+games conducted via e-mail and similar means. This opcode takes a single
+operand that is a positive integer. It is used to select among various games
+in progress between the same sender and receiver.
+
+
+16.2.5.24: Opcode "tcri": telecommunication: receiver identification
+
+The "tcri" opcode is one of the telecommunication family of opcodes used for
+games conducted via e-mail and similar means. This opcode takes two order
+dependent string operands. The first operand is the e-mail address of the
+receiver of the EPD record. The second operand is the name of the player
+(program or human) at the address who is the actual receiver of the EPD record.
+
+
+16.2.5.25: Opcode "tcsi": telecommunication: sender identification
+
+The "tcsi" opcode is one of the telecommunication family of opcodes used for
+games conducted via e-mail and similar means. This opcode takes two order
+dependent string operands. The first operand is the e-mail address of the
+sender of the EPD record. The second operand is the name of the player
+(program or human) at the address who is the actual sender of the EPD record.
+
+
+16.2.5.26: Opcode "v0": variation name (primary, also "v1" though "v9")
+
+The opcode "v0" (lower case letter "v", digit character zero) indicates a top
+level variation name that applies to the given position. It is the first of
+ten ranked variation names, each of which has a mnemonic formed from the lower
+case letter "v" followed by a single decimal digit. Each of these opcodes
+takes either a single string operand or no operand at all.
+
+This ten member variation name family of opcodes is intended for use as
+traditional variation names for a complete game or game fragment. The usual
+processing of these opcodes are as follows:
+
+1) At the beginning of a game (or game fragment), a move sequence scanning
+program initializes each element of its set of ten variation name string
+registers to be null.
+
+2) As the EPD record for each position in the game is processed, the variation
+name operations are interpreted from left to right. (Actually, all operations
+in n EPD record are interpreted from left to right.) Because operations appear
+in ASCII order according to their opcode mnemonics, opcode "v0" (if present)
+will be handled prior to all other opcodes, then opcode "v1" (if present), and
+so forth until opcode "v9" (if present).
+
+3) The processing of opcode "vN" (0 <= N <= 9) involves two steps. First, all
+variation name string registers with an index equal to or greater than N are
+set to null. (This is the set "vN" though "v9".) Second, and only if a string
+operand is present, the value of the corresponding variation name string
+register is set equal to the string operand.
+
+
+17: Alternative chesspiece identifier letters
+
+English language piece names are used to define the letter set for identifying
+chesspieces in PGN movetext. However, authors of programs which are used only
+for local presentation or scanning of chess move data may find it convenient to
+use piece letter codes common in their locales. This is not a problem as long
+as PGN data that resides in archival storage or that is exchanged among
+programs still uses the SAN (English) piece letter codes: "PNBRQK".
+
+For the above authors only, a list of alternative piece letter codes are
+provided:
+
+Language Piece letters (pawn knight bishop rook queen king)
+---------- --------------------------------------------------
+Czech P J S V D K
+Danish B S L T D K
+Dutch O P L T D K
+English P N B R Q K
+Estonian P R O V L K
+Finnish P R L T D K
+French P C F T D R
+German B S L T D K
+Hungarian G H F B V K
+Icelandic P R B H D K
+Italian P C A T D R
+Norwegian B S L T D K
+Polish P S G W H K
+Portuguese P C B T D R
+Romanian P C N T D R
+Spanish P C A T D R
+Swedish B S L T D K
+
+
+18: Formal syntax
+
+ ::=
+
+
+ ::=
+
+ ::=
+
+
+ ::= [ ]
+
+ ::=
+
+ ::=
+
+ ::=
+
+ ::=
+
+
+
+ ::=
+
+
+
+ ::= ( )
+
+ ::= 1-0
+ 0-1
+ 1/2-1/2
+ *
+ ::=
+
+
+19: Canonical chess position hash coding
+
+*** This section is under development.
+
+
+20: Binary representation (PGC)
+
+*** This section is under development.
+
+The binary coded version of PGN is PGC (PGN Game Coding). PGC is a binary
+representation standard of PGN data designed for the dual goals of storage
+efficiency and program I/O. A file containing PGC data should have a name with
+a suffix of ".pgc".
+
+Unlike PGN text files that may have locale dependent representations for
+newlines, PGC files have data that does not vary due to local processing
+environment. This means that PGC files may be transferred among systems using
+general binary file methods.
+
+PGC files should be used only when the use of PGN is impractical due to time
+and space resource constraints. As the general level of processing
+capabilities increases, the need for PGC over PGN will decrease. Therefore,
+implementors are encouraged not to use PGC as the default representation
+because it is much more difficult (than PGN) to understand without proper
+software.
+
+PGC data is composed of a sequence of PGC records. Each record is composed of
+a sequence of one or more bytes. The first byte is the PGN record marker and
+it specifies the interpretation of the remaining portion of the record. This
+remaining portion is composed of zero or more PGN record items. Item types
+include move sequences, move sets, and character strings.
+
+
+20.1: Bytes, words, and doublewords
+
+At the lowest level, PGC binary data is organized as bytes, words (two
+contiguous bytes), and doublewords (four contiguous bytes). All eight bits of
+a byte are used. Longwords (eight contiguous bytes) are not used. Integer
+values are stored using two's complement representation. Integers may be
+signed or unsigned depending on context. Multibyte integers are stored in
+low-endian format with the least significant byte appearing first.
+
+A one byte integer item is called "int-1". A two byte integer item is called
+"int-2". A four byte integer item is called "int-4".
+
+Characters are stored as bytes using the ISO 8859/1 Latin-1 (ECMA-94) code set.
+There is no provision for other characters sets or representations.
+
+
+20.2: Move ordinals
+
+A chess move is represented using a move ordinal. This is a single unsigned
+byte quantity with values from zero to 255. A move ordinal is interpreted as
+an index into the list of legal moves from the current position. This list is
+constructed by generating the legal moves from the current position, assigning
+SAN ASCII strings to each move, and then sorting these strings in ascending
+order. Note that a seven bit ordinal, as used by some inferior representation
+systems, is insufficient as there are some positions that have more than 128
+moves available.
+
+Examples: From the initial position, there are twenty moves. Move ordinal 0
+corresponds to the SAN move string "Na3"; move ordinal 1 corresponds to "Nc3",
+move ordinal 4 corresponds to "a3", and move ordinal 19 corresponds to "h4".
+
+Moves can be organized into sequences and sets. A move sequence is an ordered
+list of moves that are played, one after another from first to last. A move
+set is a list of moves that are all playable from the current position.
+
+Move sequence data is represented using a length header followed by move
+ordinal data. The length header is an unsigned integer that may be a byte or a
+word. The integer gives the number, possibly zero, of following move ordinal
+bytes. Most move sequences can be represented using just a byte header; these
+are called "mvseq-1" items. Move sequence data using a word header are called
+"mvseq-2" items.
+
+Move set data is represented using a length header followed by move ordinal
+data. The length header is an unsigned integer that is a byte. The integer
+gives the number, possibly zero, of following move ordinal bytes. All move
+sets are be represented using just a byte header; these are called "mvset-1"
+items. (Note the implied restriction that a move set can only have a maximum
+of 255 of the possible 256 ordinals present at one time.)
+
+
+20.3: String data
+
+PGC string data is represented using a length header followed by bytes of
+character data. The length header is an unsigned integer that may be a byte, a
+word, or a doubleword. The integer gives the number, possibly zero, of
+following character bytes. Most strings can be represented using just a byte
+header; these are called "string-1" items. String data using a word header are
+called "string-2" items and string data using a doubleword header are called
+"string-4" items. No special ASCII NUL termination byte is required for PGC
+storage of a string as the length is explicitly given in the item header.
+
+
+20.4: Marker codes
+
+PGC marker codes are given in hexadecimal format. PGC marker code zero (marker
+0x00) is the "noop" marker and carries no meaning. Each additional marker code
+defined appears in its own subsection below.
+
+
+20.4.1: Marker 0x01: reduced export format single game
+
+Marker 0x01 is used to indicate a single complete game in reduced export
+format. This refers to a game that has only the Seven Tag Roster data, played
+moves, and no annotations or comments. This record type is used as an
+alternative to the general game data begin/end record pairs described below.
+The general marker pair (0x05/0x06) is used to help represent game data that
+can't be adequately represented in reduced export format. There are eight
+items that follow marker 0x01 to form the "reduced export format single game"
+record. In order, these are:
+
+1) string-1 (Event tag value)
+
+2) string-1 (Site tag value)
+
+3) string-1 (Date tag value)
+
+4) string-1 (Round tag value)
+
+5) string-1 (White tag value)
+
+6) string-1 (Black tag value)
+
+7) string-1 (Result tag value)
+
+8) mvseq-2 (played moves)
+
+
+20.4.2: Marker 0x02: tag pair
+
+Marker 0x02 is used to indicate a single tag pair. There are two items that
+follow marker 0x02 to form the "tag pair" record; in order these are:
+
+1) string-1 (tag pair name)
+
+2) string-1 (tag pair value)
+
+
+20.4.3: Marker 0x03: short move sequence
+
+Marker 0x03 is used to indicate a short move sequence. There is one item that
+follows marker 0x03 to form the "short move sequence" record; this is:
+
+1) mvseq-1 (played moves)
+
+
+20.4.4: Marker 0x04: long move sequence
+
+Marker 0x04 is used to indicate a long move sequence. There is one item that
+follows marker 0x04 to form the "long move sequence" record; this is:
+
+1) mvseq-2 (played moves)
+
+
+20.4.5: Marker 0x05: general game data begin
+
+Marker 0x05 is used to indicate the beginning of data for a game. It has no
+associated items; it is a complete record by itself. Instead, it marks the
+beginning of PGC records used to describe a game. All records up to the
+corresponding "general game data end" record are considered to be part of the
+same game. (PGC record type 0x01, "reduced export format single game", is not
+permitted to appear within a general game begin/end record pair. The general
+game construct is to be used as an alternative to record type 0x01 in those
+cases where the latter is too restrictive to contain the data for a game.)
+
+
+20.4.6: Marker 0x06: general game data end
+
+Marker 0x06 is used to indicate the end of data for a game. It has no
+associated items; it is a complete record by itself. Instead, it marks the end
+of PGC records used to describe a game. All records after the corresponding
+(and earlier appearing) "general game data begin" record are considered to be
+part of the same game.
+
+
+20.4.7: Marker 0x07: simple-nag
+
+Marker 0x07 is used to indicate the presence of a simple NAG (Numeric
+Annotation Glyph). This is an annotation marker that has only a short type
+identification and no operands. There is one item that follows marker 0x07 to
+form the "simple-nag" record; this is:
+
+1) int-1 (unsigned NAG value, from 0 to 255)
+
+
+20.4.8: Marker 0x08: rav-begin
+
+Marker 0x08 is used to indicate the beginning of an RAV (Recursive Annotation
+Variation). It has no associated items; it is a complete record by itself.
+Instead, it marks the beginning of PGC records used to describe a recursive
+annotation. It is considered an opening bracket for a later rav-end record;
+the recursive annotation is completely described between the bracket pair. The
+rav-begin/data/rav-end structures can be nested.
+
+
+20.4.9: Marker 0x09: rav-end
+
+Marker 0x09 is used to indicate the end of an RAV (Recursive Annotation
+Variation). It has no associated items; it is a complete record by itself.
+Instead, it marks the end of PGC records used to describe a recursive
+annotation. It is considered a closing bracket for an earlier rav-begin
+record; the recursive annotation is completely described between the bracket
+pair. The rav-begin/data/rav-end structures can be nested.
+
+
+20.4.10: Marker 0x0a: escape-string
+
+Marker 0x0a is used to indicate the presence of an escape string. This is a
+string represented by the use of the percent sign ("%") escape mechanism in
+PGN. The data that is escaped is the sequence of characters immediately
+follwoing the percent sign up to but not including the terminating newline. As
+is the case with the PGN percent sign escape, the use of a PGC escape-string
+record is limited to use for non-archival data. There is one item that follows
+marker 0x0a to form the "escape-string" record; this is the string data being
+escaped:
+
+1) string-2 (escaped string data)
+
+
+21: E-mail correspondence usage
+
+*** This section is under development.
+
+
+Standard: EOF
diff --git a/_assets/vendor/pgn4web/pgn4web-help.html b/_assets/vendor/pgn4web/pgn4web-help.html
new file mode 100644
index 0000000..dd75a61
--- /dev/null
+++ b/_assets/vendor/pgn4web/pgn4web-help.html
@@ -0,0 +1,456 @@
+
+
+
+
+
+
+
+pgn4web help
+
+
+
+
+
+
+
+
+
+
+
+
+
+pgn4web help
+
+
+
+
+
+
+
+
+
+
+
+
+The user can interact with the pgn4web chessboard using the keyboard, clicking chessboard squares (hovering the mouse on each square displays an help summary) or using touch gestures.
+
+A search tool allows searching within the PGN games.
+
+Errors alert messages are logged, such as failures to load PGN games, incorrect PGN games or incorrect FEN strings. When an error is encountered, the top left chessboard square will flash to signal the exception. The error alert log can be reviewed clicking on the same top left chessboard square.
+
+See the pgn4web wiki for more information. Please note, the wiki information always refers to the latest version of pgn4web.
+
+
+
+
+
+The user can interact with the pgn4web chessboard using the keyboard. See the pgn4web wiki for more information. Most commonly used shortcut keys:
+
+
+
+
+
+
+
+
+The user can interact with the pgn4web chessboard clicking chessboard squares:
+
+
+
+
+
+
+
+
+
+
+
+
+For full details about the search tool (implemented as regular expression match of the text of the PGN game), please refer to the pgn4web wiki; please find below a sample list of useful search patterns:
+
+
+
+
+
+
+
+
+pgn4web supports chess annotations symbols as defined by the Chess Informant publishing company:
+
+
+
+
+
+
+
+Technical note: Chess Informant symbols display requires a modern browser supporting web fonts, otherwise the game notation might result garbled.
+
+
⊥
+