That means that my splitting out the data components might need some rethinking. If it were a Python project - the use of modules would be strongly recommended. At the moment my TCL languages skills are just a little better than my Russian language skills - so I should punt for now.

Still, in modifying the behavior I'm doing a lot of small edits to scid.gui directly.

Here's some changes I've instituted:

1) Player Finder listing now defaults to 500, up from 50.

2) The Player Info window is once more auto-raised on updating (say with a new player). Not sure why this got commented out at some point in the past.

3) The Player Finder window now gray highlights any selected player on mouse-click. Seems more natural. (It still yellow highlights on mouseover).

4) Player Rating Graph windows are auto-raised on update.

5) Default for Insert Mark color in Comment Editor changed to dark blue (from red).

(A personal preference of mine - should be some kind of option. I'm thinking of changing the colors in the rating graphs to match EDO as well - but this might be wandering off into the weeds).

6) Import PGN Window now allows a raw FEN string as input.

I got this idea from <ChessTempo>'s input window - which allows normal PGN and raw FEN input. Very convenient. I use this a lot, and previously had to use the more cumbersome SCID: setup board.

My standard version is 4.4 (since they broke some of the xtab features in later version, and for other reasons). It provides these pieces:

<Alpha, Brauhaus, Eboard, Fantasy, Fantasy2, Kingdom, Leipzig, Merida, Merida1, Merida2, USCF, Blind>

Only a subset of these are truly visually up to snuff. E.g. Alpha, a very good design, has some annoying white random speckle pixels on the outlines of the pieces.

And some others have jagged edges (i.e. random pixelation noticeable on the edges), which we've come to not accept in this post-W95 world.

I often wondered what was going on, as the resolutions should have yielded better results.

Having implemented my own version - the reason has become clear to me.

The best piece design requires image blending of the piece image and background image. Where a boundary pixel can specify an alpha-value for blending.

So, a good high-resolution piece image isn't enough. It must also allow alpha-channel blending.

And that requires PNG images.

click for larger view

1r5k /8/8/1q6/1Q6/8/8/1K3Q1r w - - 0 1

How about the different queen captures here:

click for larger view

1r5k /1Q6/8/1q6/1Q6/8/8/1K3Q1r w - - 0 1

And here:

click for larger view

1r4k1 /1Q6/8/8/1Q2q2Q/8/8/rQ2K2Q w - - 0 1

Interestingly, pgn-extract is still being updated, with this important very recent addition:

<

21st July 2017: Added --nobadresults to suppress games with inconsistent result indications. Fixed failure to correct terminating result with --fixresulttags. <Added --allownullmoves.>

<<>>>

Trying to write a program which understands PGN SAN input, let alone PGN SAN output is quite a challenge, at least in my experience.

I'm almost ready to unveil my 4.4/4.5 merged/improved version of SCID. There are some improvements which are just hacked in - and I'd really appreciate some review/improvement of the mods.

Here's a list of some of the changes - in reverse order:

1) Gamelist is now a hybrid of 4.4 and 4.5.

- Unlike 4.5, only one gamelist (or gameslist) window is used. Much less confussing.

- The 4.5 sorting features are fully implemented - which is a big improvement, perhaps the best feature of 4.5.

2) PNG piece sets have been introduced.

- Alpha, Eboard, and Leipzig all now look like they should, without speckling, or jagged edges.

- Merida2 has been modified to use pure White.

3) FEN input can be given in the PGN input window, as a convenience.

4) Biographical player pages can now allow direct linking to CG, EDO, and Wiki pages.

5) Rating graphs for historical players, using EDOchess ratings, are available for Z-base players.

The code base left behind isn't being keep coherent - as developers modify it for improvements in one area, while breaking sections of the code in others.

Case in point - the xtab treatment, which is why I stayed with 4.4.

But there's some other revealing glitches.

First of all, tcscid.exe isn't distributed with the binary kits. This is really a very important component of SCID - if only for having a tool used to run SCID by hand for debugging.

In principle, it also allows for TCL scripts to be written for automated processing of DB's in various ways as well.

Well, the source code package can be used to build it - but one has to go find the Makefile.vc from some other source than the official sourceforge distribution.

Then there's this - all the documentation for tcscid, which is really fundamental documentation about SCID's underlying code - is written for v3.2.

Now, I've released it in reformatted form with backlinks. But comparing v4.3, v4.4, v4.5 I see that tcscid is a moving target, and lots of changes (both additions and subtractions) have gone undocumented.

It seems that Shane was the last person to keep the documentation synched with the code - even Pascal omitted documenting a number of sc_tree sub-commands.

(In fact, one of the problems I'm having with retrofitting the GamesList window is that the sc_filter command has changed so much between version 4.4 and 4.5 - without explicit being documented.)

I've gone through at least noting the changes, and will release a new version of the documentation soon.

And for the road, one last example.

There was a function - <sc_base ecoStats>, which was supposed to print out ECO opening statistics for games in a db. I couldn't get it to work.

Why not?

Well, I had to muck around with the C++ code in the debugger to find that there was an undocumented option to the open command:

<sc_base open [-readonly] [-fast] <db>>

It turns out that the ECO stats weren't being updated if fast opens were used. One can understand that fast opens might be desirable - for speed and memory usage. Maybe it should even be the default.

In fact, it is the default. Trouble is, there's no <-slow> option. Clearly someone just changed the default without realizing how it might negatively impact tcscid.

---------------

<Spielmann–Schlechter: xtra move, 30…Kd7 – Marco notes some columns omitted it. BCM v26 N8 (Aug 1906) G2740 p332/351 (Notes from ‘New Orleans Times’)>

The move in question is <30...Kd7>. Gillam (p.88) translates Marco's entire note, which includes an affirmation that the move was played. As Marco was there (and could have checked with Schlechter in any event), I dee no reason to doubt his statement.

-------------

<Perlis–Salwe: extra moves, …22 to 35; BDE and Macro both have xtra vs AH source (PB preferred) 1906-06-07 – Algemeen Handelsblad – p6c4 / BDE 1906-06-25 p16c2 https://resolver.kb.nl/resolve?urn=...>

Newspaper report has Black resiging after W22; Marco adds moves from B22-W25. Gillam also quotes these sources:

T.F. Lawernce - The People (a London Sunday newspaper) Deutsches Wochenschach
Schweizer Schachzeitung
Leopold Hoffer (presumably from The Field)

We need to be careful about assuming that Gillam's sources will have the same version of the game which he uses. One of Hoffer's notes refers to one of the extra moves, so on that basis it seems that the longer version was current at the time.

But, for the record, here's a rundown of the 51 R1.1-1.5 games which we presumably both sourced from Marco (you via Gillam, me from Marco directly):

PB/Z ordering...

<<Marshall--Sourin (R1.1) p9/11>

26.Rfd1    vs    26.Rc1 <<>>>

* * *

<<Post--Tanbenhaus (R1.3) p39/41>

10...O-O 11.Bc2 Nxd2 12.Qxd2    vs    10...Nxd2 11.Qxd2 O-O 12.Bc2 <<>>>

* * *

<<Znosko-Borovsky--Perlis (R1.4) p60/62>

34...a5 35.Qf7 Qa3    vs    34...Qa3 Qf7 a5 <<>>>

I've corrected all the obvious Z-errors, so only a few differences now. I'm interested in knowing the details of course.

Should I post my working version of the PGN to the Google drive?

was mentioned earlier. Gillam's <26.Rfd1> is clearly a typo by Marco's <26.Rc1>,. In the game continuation Black would hang a piece after 26.fRd1.

---

The other two cases are less clear-cut. Gillam mentions no sources besides Marco, and gives no indication why he transposed moves. Perhaps he found the games in existing databases as is, and just went along in the crowd.

<<Post--Tanbenhaus (R1.3) p39/41>

Gillam: 10...0-0 11.Bc2 Nxd2 12.Qxd2
Marco: 10...Nxd2 11.Qxd2 0-0 12.Bc2

<CG. follows Gillam.

Hard to say. Two indications that Marco is more likely:

1) Gillam's 10...O-O is by far the more common move

2) After 10...O-O 11.Bc2 Black has three moves more common and with better results than 11...Nxd2.

------------------
<<Znosko-Borovsky--Perlis (R1.4) p60/62>

Gillam: 34...a5 35.Qf7 Qa3
Marco: 34...Qa3 35.Qf7 a5

Very slight indication for Marco's version: after 34...Qa3, 35.Qf7 is indicated to, among things, protect the a-pawn. White has a wider choice of moves after 34...a5, and after 35.Qf7 Black might not consider 35...Qa3 as it doesn't attack the a-pawn.

<Swiderski–Spielmann: Tpos 3,4 (PB bad) 1906-06-09 Algemeen Handelsblad p6c4 – https://resolver.kb.nl/resolve?urn=... 1906-06-08 De Telegraaf p2c1 – https://resolver.kb.nl/resolve?urn=...>

I think Gillam (and <CG>) have s this wrong. Besides your sources, ACB v3 No9 p192 also has the 3...Nc6/ 4...Nf6 move order. Gillam and <CG> seem to be the only ones with 3...Nf6 and 4...Nc6.

<CG> having 3...Nf6 / 4...Nc6 makes me wonder if it's an error in databases in general. That might be where Gillam got it too. It could also be from Tarrasch, whom Gillam mentions as a source for his notes (though without any specific citation.)

By the way, this kibitz cites a source which has White resigning after move 20!

Swiderski vs Spielmann, 1906 (kibitz #3)

So this was not a case when only Marco gave extra moves.

-----

Wolf–Suechting: xtra moves, at move 30 + end (…Bxa3 cxd5+) (PB bad?) DSZ v61 N11 (Nov 1906) G-7578 p326/336

We discussed this in tje Bistro.

Biographer Bistro (kibitz #18146)

The move <30.Qc6 Rd6> definitely belongs in the score. Extra moves at the end of agame are normally analysis of the final position. There seems not reason to add an extra move in the middle of game.

Janowski's note was probably based on the shorter version found in Deutsche Schachzeitung. Rmember, the marco book didn't come out until well into 1907.

---
Salwe–Mieses: xtra moves at end, …43 to 46, clearly a draw, though Marco agrees with PB. (PB bad?) 1906-06-12 De Telegraaf p2c5 – https://resolver.kb.nl/resolve?urn=...

Once again it's Marco with the longer version. I would feel much better about trusting him if it didn't happen every time.

This is the closest case yet, since th extra moves are of the type an annotator would include in a note. . But I would still include them.

This may be wrong, but I'd like to stick with Marco's versions until he is proven guilty. Remember, he is working with the co-operation of the Tournament Committee, probably meaning he has access to their official record, and is working at a relatively leisurely pace (it took almost a year to produce this book). The newspapers are relying on hastily assembled press releases and reports, and have time and space crunches of their own.

<1906.06.07 A00 0 (R3 (1.3.3)) 0-1 Post--Taubenhaus (Marco G-47 p39/41)>

Where I think there's a tpos 10-12 - Macro having:

<10...Nxd2 11.Qxd2 O-O 12.Bc2>

Black would likely have a ...Nxf7 option somewhere in there, otherwise.>

This looks like the same sort of case as Swiderski vs Spielmann, 1906. In that game Marco has 3...Nc6 and 4...Nf6, GIllam (who used Marco as a source of ntoes) had 3...Nf6 and 4...Nc6.

In PostA E Post vs Taubenhaus, 1906, we have these move orders:

Marco: 10...Nxd2 11.Qxd2 0-0 12.Bc2
Gillam: 10...O-O 11.B2 Nxd2 12.Qxd2

In Swiderski-Spielmann we have good contemporary evidence that Mrco's order of moves is correct. There is not the same evidence in Post-Taubenhaus/

In both cases, Gillam's choice is by far the most popular move oderder today, but relatively less popular in 1906. I think it possible that, instead of a contemporary source, he used a databases which included games in which the OOM had been tweaked to fit a standard sequence.

You mentioned something earlier about score corrections in either textual or PGN form. PGN would probably be easier for me to work with, but do but whatever is easier for you

https://drive.google.com/open?id=1H...

BTW- you can update your files on the Google drive. If you drop in a new version with the same name Google will just update it in place (while saving/stacking the old versions).

We had snow flurries here yesterday...

http://orig15.deviantart.net/a220/f...

It's so depressing I can't do any (useful) work, either. Thank goodness for CG!

It's independent of your games, except for the ϵ²-checking to eliminate obvious transcription mistakes/typos.

Is there anyway to get the photos?

He includes thumbnail portraits of everybody except Sournin, but no indication of sources. I haven't looked carefully, but I guess they are publicly available rather than from a special collection of some sort. For example, here's the Teichman shot he uses:

http://www.google.com/url?sa=i&rct=...

And this, of course, is not the original source.

I have no way of scanning or transmitting these.