Go4Go printable kifu - mutiple diagrams

[macelee]

After moving Go4Go.net to a new server, a few people reported that the printable kifu function was broken. This was fixed a few days ago. I replaced the old Java based code by a new PHP code so that I do not need to manage an extra application server on the hosting machine.

I moved on to write more code splitting the printable kifu on a single diagram to multiple diagrams. An example is shown below.

test-5.png (20.02 KiB) Viewed 5997 times

Also please find the attached PDF file for a whole game.

Before posting this work online, I want to know that for players with different strengths, how many moves per diagram are most suitable. At 5-dan, I personally use 40 or 50. But I can obviously make this configurable for different users.

When this is finalised, I can present on Go4Go something similar to the E-books created by logan in this thread: http://lifein19x19.com/forum/viewtopic.php?f=17&t=10643

[SoDesuNe]

I prefer 50 moves per diagram, simply because I like to print my collections (4 diagrams à 50 moves per page) and everything below would just take too much paper and toner.

[quantumf]

50 has been good for me since I was a DDK.

[xed_over]

I like printing all the moves on a single diagram.
Not many people like that though, I think.

[ez4u]

I am not sure why you would implement a function to print diagrams of only one size. It would seem simple to give the reader a choice. In any case, however, I find fixed-length diagrams annoying. That's why after all these years my Collected Games of Go Seigen sit proudly on my shelf while all studying of his games is done with GoGoD.

Personally I would prefer to make more use of the computer's capabilities and produce a flexible list of diagrams of different lengths that show parts of the game based on how things develop. For example, in the game you posted I would like to see the basic fuseki, moves 1-10 in the first diagram. The second diagram should show development of the bottom right corner, moves 10 through 45. The third diagram should show the upper left, moves 45 through 75; the fourth the ko in the upper right, moves 75 through 97. Since inevitably different people would have different opinions of what moves to put in each diagram, this would need to be implemented as some sort of tool where users could build a list of diagrams.

Quite a few years ago I wrote a request like this on the Drago request list on SL but I don't think it was ever implemented.

[macelee]

I will address your two points separately.

Of course many players prefer to use interactive tools to study games. That is a different story. The static kifus I talk about is not just for producing ebooks and keep paper records of your games. One way to improve reading skill is to read the game sequence from these diagrams. I know quite a few strong players regularly doing do. Even for professional level players, it sometimes can be difficult to read hundred of moves from a single diagram (as we often see from live commentaries, in which pro players have trouble locating next move). I personally can read about 50 moves per diagram comfortably. I guess for kyu level players 20 moves per diagram is probably more suitable but I am not sure. That's why I ask the question initially.

Then I need to consider technical issues. Of course it would be very useful to give user complete freedom generating whatever diagrams they like. And my code can actually support this. However I need to control the amount of computer resources used. In my test, the image file of a single diagram for an average 200-move game is about 40k in size. I have 48000+ games. That is about 2GB of disk space if all diagrams are cached on my server. If I have several options, for example, 20, 30 and 50 moves per diagram, I will need twenty times more storage. I haven't even considered generating better quality images. If I use Imagemagick to create antialised images, the file size is about 8 times larger.

[ez4u]

I will address your two points separately.

Of course many players prefer to use interactive tools to study games. That is a different story. The static kifus I talk about is not just for producing ebooks and keep paper records of your games. One way to improve reading skill is to read the game sequence from these diagrams. I know quite a few strong players regularly doing do. Even for professional level players, it sometimes can be difficult to read hundred of moves from a single diagram (as we often see from live commentaries, in which pro players have trouble locating next move). I personally can read about 50 moves per diagram comfortably. I guess for kyu level players 20 moves per diagram is probably more suitable but I am not sure. That's why I ask the question initially.

Then I need to consider technical issues. Of course it would be very useful to give user complete freedom generating whatever diagrams they like. And my code can actually support this. However I need to control the amount of computer resources used. In my test, the image file of a single diagram for an average 200-move game is about 40k in size. I have 48000+ games. That is about 2GB of disk space if all diagrams are cached on my server. If I have several options, for example, 20, 30 and 50 moves per diagram, I will need twenty times more storage. I haven't even considered generating better quality images. If I use Imagemagick to create antialised images, the file size is about 8 times larger.

I am honestly at a loss (well, almost...). Why would you ever consider caching all the images when you have the code to produce the diagrams on demand?

[macelee]

Right I don't have to cache the images and I can always generate them on the fly. Running a website long enough, just everything is about performance, even when I am hosting the site by myself now.

OK, the function is online now. Find the extra links below the game viewer.

screen.png (53.38 KiB) Viewed 5797 times

I also replaced the graphics library code so now I have higher quality images. I found that GIF files are more suitable than PNG files as the diagrams in GIF are much smaller without noticeable visual difference.