NAME

Chess::PGN::EPD - Perl extension to produce and manipulate EPD text.

VERSION

version 0.34

SYNOPSIS

From "Working With Epd Files" by Steve Lopez <http://www.chessbaseusa.com/portals/6/tn/Issues_Back/1999_autumn/1999_1031.htm>,

"There's a lot of chess information available on the Internet in a variety of formats. One of these is called EPD (Extended Position Description) format; it's just a convenient way to provide a board position (rather than a full game) in an ASCII text notation. For example, here's what the board position after 1.e4 looks like in EPD format:

rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq e3 0 1

This was designed as a way for chess players and chess programs to pass board positions back and forth for analysis. You'll frequently see posts to Usenet chess newsgroups or other message boards containing these EPD positions.

There's a quick, easy way to copy and paste these board descriptions into ChessBase or any of our playing programs (Fritz, Hiarcs, Nimzo, Junior). Just highlight the EPD line from a post or web page and hit CRTL-C on your keyboard. Then open ChessBase, go to the Game menu, select "Setup position", and click the button marked "Paste FEN". You'll instantly see the position appear on the board in the "Setup position" window. Click "OK" and you'll now have an "Enter new game" window with the proper board position on it taken from the EPD file. You can then save the position into a database just like any other game..."

Chess::PGN::EPD attempts to bring ease and convenience to its users programmatically by providing a set of functions that manipulate EPD text.

CODE examples

THIS

#!/usr/bin/perl
#
#
use warnings;
use strict;
use Chess::PGN::Parse;
use Chess::PGN::EPD;

if ($ARGV[0]) {
    my $pgn = new Chess::PGN::Parse($ARGV[0]) or die "Can't open $ARGV[0]: $!\n";
    while ($pgn->read_game()) {
        $pgn->parse_game();
        print join ( "\n", epdlist(  @{$pgn->moves()} ) ), "\n\n";
    }
}

#!/usr/bin/perl
#
#
use warnings;
use strict;
use Chess::PGN::EPD;

my $position = 'rnbqkb1r/ppp1pppp/5n2/3P4/8/8/PPPP1PPP/RNBQKBNR w KQkq -';
print join("\n",epdstr(epd => $position,type => 'latex'));

#!/usr/bin/perl
#
#
use strict;
use warnings;
use Chess::PGN::Parse;
use Chess::PGN::EPD;

if ($ARGV[0]) {
    my $pgn = new Chess::PGN::Parse($ARGV[0]) or die "Can't open $ARGV[0]: $!\n";
    while ($pgn->read_game()) {
        my @epd;

        $pgn->parse_game();
        my @moves = @{ $game{'GameMoves'} };
        print join("\n",epdTaxonomy(moves => \@moves,all => 1,astags => 1)),"\n";
    }
}

DESCRIPTION

epdcode(code,epdlistref)

Determines the requested code given a list of epd strings in reverse order. Allowed codes are:

'ECO' from The Encyclopedia of Chess Openings.
'NIC' from New in Chess.
'Opening' Traditional Opening name in English.

At the moment, this routine depends on three database files installed along with the module. On demand other formats (the current is JSON) may be implemented. The 'ToDo' list also mentions the possibility of extending the databases, although that might come in the form of a 'How To' rather than any code solution. NOTE: This routine is deprecated in favor of epdTaxonomy and will at some point be removed.

epdfromto(movelist)

Returns an array of hashes that contain move information. Useful for conversions to other forms of notation; i.e. telegraphic or english notation.

epdgetboard([epd])

Provides access to the 'board' with the current epd postition set up. If given an EPD string, set board accordingly. The returned values are:

$w - boolean, white to move?
$Kc - boolean, has white castled king side?
$Qc - boolean, has white castled queen side?
$kc - boolean, has black castled king side?
$qc - boolean, has black castled queen side?
%board - hash board, keys are algebraic square names, values are occupying piece.

epdlist(movelist)

Returns an array of strings that represent the conversion of game text into positional shorthand, one entry for each move made in the game.

Concepts

EPD

"Extended Position Description" 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".

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.

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.

FEN

"Forsyth-Edwards Notation" 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".

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

NOTE

With only a little observation, the astute user will notice that actually this function doesn't return either EPD or FEN, but rather a bit of both. It is mostly FEN, but it lacks the Fullmove number field, since for most usage that information is available else where or can easily be reconstructed. As to why the module is called EPD, well I figured since it wasn't one and it wasn't the other, that left it up to me to choose--besides, who would want a module named after a swamp?!

epdset(epd)

For those instances where the game in question does not begin with a complete move list, this function allows the user to set the starting position using a 'EPD' string as described elsewhere in the document.

epdstr(epd|board,type [border,corner,legend])

Returns an array of strings that represent a diagramatic conversion of the specified epd string or board postion to the specified type. Parameters are passed as a anonymous hash, i.e. epdstr(epd => $position,type => 'diagram') or similar.

Types Supported

The following types are understood by epdstr:

'diagram'

A plain ASCII diagram with simple border showing rank and file. Typical output:

8  rnbqkb r
7  ppp pppp
6   - - n -
5  - -P- -
4   - - - -
3  - - - -
2  PPPP PPP
1  RNBQKBNR
   abcdefgh

'text'

A plain ASCII diagram. Typical output:

rnbqkb r
ppp pppp
 - - n -
- -P- -
 - - - -
- - - -
PPPP PPP
RNBQKBNR

'palview'

An array of HTML information that represents the tabular diagram information for PalView. Typical output:

'latex'

The necessary text fragment to 'set' the diagram in LaTeX using any variation of Piet Tutelars original chess12.tar.Z package. As given, the LaTeX command 'diagram' is used. As an example here is the source to test.tex:

%%
%% test.tex -- example LaTeX file to demonstrate output from Chess::PGN::EPD
%%
\documentclass{article}
\usepackage{chess}
\usepackage{bdfchess}
\begin{document}
\newenvironment{diagram}{\begin{nochess}}{$$\showboardwithnotation$$\end{nochess}}
%%
%% fragment as produced by epdstr(epd => $position,type => 'latex');
%%
\begin{diagram}
\board
{rnbqkb r}
{ppp pppp}
{ * * n *}
{* *P* * }
{ * * * *}
{* * * * }
{PPPP PPP}
{RNBQKBNR}
\end{diagram}
%%
%% end of fragment
%%
\end{document}

'linares'

Alpine Electronics' LinaresDiagram font. Mapping also works with both HastingsDiagram and ZurichDiagram fonts. Single or double border, With or without algebraic legend.

'linares1'

Standard mapping, single border, squares offset.

'linares2'

Standard mapping, thick single border.

'tilburg'

A borderless font designed by Eric Schiller and Bill Cone.

'marroquin'

This type refers to any font designed by Armando H. Marroquin, excepting his FigurineSymbol fonts. They having a different purpose, have a different mapping.

'leschemelle'

The map for Chess Cases designed by Matthieu Leschemelle.

'bentzen1'

The map for Chess Alpha designed by Eric Bentzen.

'bentzen2'

The map for Chess Berlin designed by Eric Bentzen.

'hickey'

The map for Chess Plain designed by Alan Hickey.

'scott1'

The map for Chess Regular a port of Adobe Cheq ported to True Type by Alistair Scott.

'scott2'

The map for Chess Usual a modification of Chess Regular by Armando H. Marroquin.

'bodlaender'

The map for Chess Utrecht designed by Hans Bodlaender.

'cowderoy'

The map for Traveller Standard v3 designed by Alan Cowderoy.

Note that 'type' is not case sensative so that 'latex' and 'LaTeX' will both work equally well.

Fonts Supported

List with font name, font author, and type name:

Chess Cases -- Matthieu Leschemelle -- leschemelle
Chess Adventurer -- Armando H. Marroquin -- marroquin
Chess Alfonso-X -- Armando H. Marroquin -- marroquin
Chess Alpha -- Eric Bentzen -- bentzen1
Chess Berlin -- Eric Bentzen -- bentzen2
Chess Condal -- Armando H. Marroquin -- marroquin
Chess Harlequin -- Armando H. Marroquin -- marroquin
Chess Kingdom -- Armando H. Marroquin -- marroquin
Chess Leipzig -- Armando H. Marroquin -- marroquin
Chess Line -- Armando H. Marroquin -- marroquin
Chess Lucena -- Armando H. Marroquin -- marroquin
Chess Magnetic -- Armando H. Marroquin -- marroquin
Chess Mark -- Armando H. Marroquin -- marroquin
Chess Marroquin -- Armando H. Marroquin -- marroquin
Chess Maya -- Armando H. Marroquin -- marroquin
Chess Mediaeval -- Armando H. Marroquin -- marroquin
Chess Merida -- Armando H. Marroquin -- marroquin
Chess Millennia -- Armando H. Marroquin -- marroquin
Chess Miscel -- Armando H. Marroquin -- marroquin
Chess Montreal -- Gary Katch -- katch
Chess Motif -- Armando H. Marroquin -- marroquin
Chess Plain -- Alan Hickey -- hickey
Chess Regular -- Alistair Scott -- scott1
Chess Usual -- Armando H. Marroquin -- scott2
Chess Utrecht -- Hans Bodlaender -- bodlaender
Tilburg -- Eric Schiller and Bill Cone -- tilburg
Traveller Standard v3 -- Alan Cowderoy -- cowderoy

These are available at http://www.enpassant.dk/chess/fonteng.htm along with a good deal of useful information on chess desktop publishing.

Font Designers Supported

Eric Bentzen
Bill Cone
Alan Cowderoy
Alan Hickey
Gary Katch
Armondo H. Marroquin
Eric Schiller
Alastair Scott
Steve Smith
Piet Tutelaers

Borders and Such Like

Some fonts, for example those designed by Armondo H. Marroquin support a variety of border styles and decorations. The border may be single or double, with square corners or rounded, and with an algebraic legend. These effects are supported by the addition of the necessary parameters to the allowed parameter list. In particular:

Border, values can be either 'single' or 'double' (default is 'single')
Corner, values can be either 'square' or 'rounded' (default is 'square')
Legend, values can be either 'yes' or 'no' (default is 'no')

Again, letter case is not particularly important, 'yes' works as well as 'Yes' etc. As for those fonts that don't support a particular feature, epdstr will fail silently, that is, the parameter will be ignored and processing will continue as though no such request had been made.

epdTaxonomy(options)

At one point the following was required in order to properly 'tag' a PGN file with opening names and information:

if ($ARGV[0]) {
    my $pgn = new Chess::PGN::Parse($ARGV[0]) or die "Can't open $ARGV[0]: $!\n";
    while ($pgn->read_game()) {
        my @epd;

        $pgn->parse_game();
        @epd = reverse epdlist( @{$pgn->moves()} );
        print '[ECO,"',epdcode('ECO',\@epd),"\"]\n";
        print '[NIC,"',epdcode('NIC',\@epd),"\"]\n";
        print '[Opening,"',epdcode('Opening',\@epd),"\"]\n";
    }
}

Not all that bad, but not all that clear either. As can be seen from the examples shown at the begining of this documentation, I've created a new subroutine called epdTaxonomy that replaces all of the above with:

if ($ARGV[0]) {
    my $pgn = new Chess::PGN::Parse($ARGV[0]) or die "Can't open $ARGV[0]: $!\n";
    while ($pgn->read_game()) {
        my @epd;

        $pgn->parse_game();
        my @moves = @{ $game{'GameMoves'} };
        print join("\n",epdTaxonomy(moves => \@moves,all => 1,astags => 1)),"\n";
    }
}

Clearly a win for the parsimonious team! This sub takes a single parameter, a hash with the following possibilities:

'moves' -- required in order to have something to work with.
'all' -- if true, create all three tags supported.
'astags' -- if true, create complete PGN header tags for the specified codes.
'eco' -- create tag information for ECO codes.
'nic' -- create tag information for NIC codes.
'opening' -- create tag information for Opening codes.

See the description of epdcode for brief descriptions of what these codes represent.

psquares(piece,board)

Given a 'piece' (single character, uppercase for white, lowercase for black, KQRBNPkqrbnp) and the current board hash, return a list of square names (algebraic) locating instances of the piece.

EXPORT

epdcode - given a list of EPD strings, return the requested code or 'unknown'.
epdfromto - given a list of moves, return an array of hashes which contain move information.
epdgetboard - given an EPD string setup board and related. Either way return board and related information.
epdlist - given a list of moves, return a list of EPD strings.
epdset - allows the user to specifiy an initial position.
epdstr - given an EPD string or a board, convert it to the specified string representation.
epdTaxonomy - one stop shopping for conversion of epd array to ECO, NIC and opening tag information.
psquares - given the piece and the board, generate and return a list of squares occupied by that type of piece.

DEPENDENCIES

Chess::PGN::Moves => 0.05
Chess::PGN::Parse => 0.20
Test::More => 0.94
File::ShareDir => 1.102
File::Slurper => 0.008
Cpanel::JSON::XS => 3.0213

TODO

Continue to improve documentation.
oo-ify support variables.
Allow font map customization.
Solve the english to algebraic problem.

KNOWN BUGS

None known; Unknown? Of course, though I try to be neat...

INSTALLATION

Traditional recipe based on Makefile.PL:

perl Makefile.PL
make
make test
make install

Note that some distributions will have a Build.PL file instead of or in addition to Makefile.PL. In that case use this recipe:

perl Build.PL
./Build
./Build test
./Build install

AUTHOR

Hugh S. Myers <hsmyers@gmail.com>

LICENSE

The "Artistic License"

   Preamble

The intent of this document is to state the conditions under which a Package may be copied, such that the Copyright Holder maintains some semblance of artistic control over the development of the package, while giving the users of the package the right to use and distribute the Package in a more-or-less customary fashion, plus the right to make reasonable modifications.

Definitions:

"Package" refers to the collection of files distributed by the
Copyright Holder, and derivatives of that collection of files
created through textual modification.

"Standard Version" refers to such a Package if it has not been
modified, or has been modified in accordance with the wishes
of the Copyright Holder as specified below.

"Copyright Holder" is whoever is named in the copyright or
copyrights for the package.

"You" is you, if you're thinking about copying or distributing
this Package.

"Reasonable copying fee" is whatever you can justify on the
basis of media cost, duplication charges, time of people involved,
and so on.  (You will not be required to justify it to the
Copyright Holder, but only to the computing community at large
as a market that must bear the fee.)

"Freely Available" means that no fee is charged for the item
itself, though there may be fees involved in handling the item.
It also means that recipients of the item may redistribute it
under the same conditions they received it.

1. You may make and give away verbatim copies of the source form of the Standard Version of this Package without restriction, provided that you duplicate all of the original copyright notices and associated disclaimers.

2. You may apply bug fixes, portability fixes and other modifications derived from the Public Domain or from the Copyright Holder. A Package modified in such a way shall still be considered the Standard Version.

3. You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following:

a) place your modifications in the Public Domain or otherwise make them
Freely Available, such as by posting said modifications to Usenet or
an equivalent medium, or placing the modifications on a major archive
site such as uunet.uu.net, or by allowing the Copyright Holder to include
your modifications in the Standard Version of the Package.

b) use the modified Package only within your corporation or organization.

c) rename any non-standard executables so the names do not conflict
with standard executables, which must also be provided, and provide
a separate manual page for each non-standard executable that clearly
documents how it differs from the Standard Version.

d) make other distribution arrangements with the Copyright Holder.

4. You may distribute the programs of this Package in object code or executable form, provided that you do at least ONE of the following:

a) distribute a Standard Version of the executables and library files,
together with instructions (in the manual page or equivalent) on where
to get the Standard Version.

b) accompany the distribution with the machine-readable source of
the Package with your modifications.

c) give non-standard executables non-standard names, and clearly
document the differences in manual pages (or equivalent), together
with instructions on where to get the Standard Version.

d) make other distribution arrangements with the Copyright Holder.

5. You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself. However, you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you do not advertise this Package as a product of your own. You may embed this Package's interpreter within an executable of yours (by linking); this shall be construed as a mere form of aggregation, provided that the complete Standard Version of the interpreter is so embedded.

6. The scripts and library files supplied as input to or produced as output from the programs of this Package do not automatically fall under the copyright of this Package, but belong to whoever generated them, and may be sold commercially, and may be aggregated with this Package. If such scripts or library files are aggregated with this Package via the so-called "undump" or "unexec" methods of producing a binary executable image, then distribution of such an image shall neither be construed as a distribution of this Package nor shall it fall under the restrictions of Paragraphs 3 and 4, provided that you do not represent such an executable image as a Standard Version of this Package.

7. C subroutines (or comparably compiled subroutines in other languages) supplied by you and linked into this Package in order to emulate subroutines and variables of the language defined by this Package shall not be considered part of this Package, but are the equivalent of input as in Paragraph 6, provided these subroutines do not change the language in any way that would cause it to fail the regression tests for the language.

8. Aggregation of this Package with a commercial distribution is always permitted provided that the use of this Package is embedded; that is, when no overt attempt is made to make this Package's interfaces visible to the end user of the commercial distribution. Such use shall not be construed as a distribution of this Package.

9. The name of the Copyright Holder may not be used to endorse or promote products derived from this software without specific prior written permission.

10. THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.

The End

COPYRIGHT

To install Chess::PGN::EPD, copy and paste the appropriate command in to your terminal.

cpanm

cpanm Chess::PGN::EPD

CPAN shell

perl -MCPAN -e shell
install Chess::PGN::EPD

For more information on module installation, please visit the detailed CPAN module installation guide.

	Global
`s`	Focus search bar
`?`	Bring up this help dialog

	GitHub
`g` `p`	Go to pull requests
`g` `i`	go to github issues (only if github is preferred repository)

	POD
`g` `a`	Go to author
`g` `c`	Go to changes
`g` `i`	Go to issues
`g` `d`	Go to dist
`g` `r`	Go to repository/SCM
`g` `s`	Go to source
`g` `b`	Go to file browse

	Search terms
module: (e.g. module:Plugin)
distribution: (e.g. distribution:Dancer auth)
author: (e.g. author:SONGMU Redis)
version: (e.g. version:1.00)