Lines Matching refs:to

15 tribute to the quality of the work done by the original authors.
17 Steven Edwards, the author, appears unfortunately to be no longer involved with
25 encoding time information relating to each move.
29 either to resort to proprietary formats or to break the standard.
32 way to encode such simple and recognised concepts as numeric position
39 It thus seems important to us to attempt an incremental improvement to PGN
40 intended to eliminate the functional weaknesses described above.
42 This document proposes an extension to PGN designed to offer an immediate 'work
43 around' solution to the problems outlined above.
58 2.3 If new command structures are to be introduced they should be specified in
61 The intention here is to provide a generalised syntax that will enable other
68 The only way to extend the syntax without breaking the standard is to embed the
76 We also propose the addition of a tag to the header to handle the state of the
78 tags designed to handle special cases where the clock start times are needed.
81 adding new tags to the header (outside the mandatory seven tag roster)
85 it should be regarded as mandatory when time information is to be embedded into
109 The characters [% are redefined to indicate the start of a command sequence when
112 As all ASCII characters are legal in a comment string it is not possible to rely
113 on any single character as an unambiguous opening delimiter. We have chosen to
123 We are *not* proposing any fixed canonical list of commands. The idea is to
124 describe a generalised command syntax, not to impose a particular set of
127 We *are* proposing a set of commands to deal with time handling. "clk" in the
136 default strip out all commands before display in order to improve legibility.
170 So it is possible to pass a full FEN string as an unquoted operand as in the
173 [%command "very tense start to the
190 that DGT boards will be using to transmit times via pgn.
199 The comments containing the embedded commands are to be taken as referring to
207 remaining to the next time control. It is proposed that future versions of
213 mechanical clocks which show a clock time rather than the time remaining to the
220 The elapsed time that a player has used for all moves in the game up to that
238 The syntax described above allows us to encode a move time for a *completed
240 also be interesting to know the state of the clock of the player whose turn it
241 is to move *but who has not yet done so*.
259 the situation where a player forgets to switch the clocks. It also allows us to
265 represents the remaining time to the next time control.
269 Two optional tags are proposed to record the clock setting at the start of the
271 While it may be helpfull to record normal clock start values here (as is done in
272 the example below) they are mainly intended to cover the case where a game is
305 8.1. The time control is specified as 40 moves in two hours and then one hour to
306 finish. This tag must be specified in order to permit calculation of such
311 this was redundant as the clocks were set as normal to show that two hours
312 remained to the first time control. If the White and BlackClock tags are absent
317 here shows that it is whites turn to move and that he/she has 1 hour 34 minutes
323 8.5. In this example we imagine that the pgn has been further edited to include
339 Many thanks to Axel Fritz and Robert Ericsson
352 this to specify several new tags.