Page 3 of 3

Re: Go diagram advice, please

Posted: Thu Aug 09, 2018 7:57 am
by PeterHB
John Fairbairn wrote: Or is Gimp so intelligent that it can interpolate data?
Gimp isn't 'intelligent' in the way implied. It can't interpolate the data for a raster image.
Have a look at:
https://vector-conversions.com/vectoriz ... ector.html

Then you will see the trade-off of advantages and disadvantages. For the particular image characteristics of go board diagrams, vector graphics are a good fit. The superiority of infinite scaling to any output resolution, from a single image file, that is much smaller than any of the multiple raster images you need for matching multiple different resolutions for displaying raster images sharply on a variety of output devices.

It's not all gravy. The downside is the normal grief of working with something you are not used to. Persuading the container you insert the .svg file into to obey your wishes about scaling the image to the size you desire relative to the surrounding text.

Re: Go diagram advice, please

Posted: Fri Aug 10, 2018 2:56 am
by pnprog
Hi!
John Fairbairn wrote:It's going off at a tangent, but there are lots of programmers here who write for other users rather than just themselves
In 2013~2014, I was asked by a friend of mine to help making a Go software a bit similar. My friend is teacher in a Chinese Go school for children, and they needed a tool to easily design and print tsumego or joseki, or board position, in small booklet to distribute homework for children. On top of that, they wanted the ability to use it as a virtual Go board, in the same way they would use their big magnet go board.

So for this program, the "magnet go board" metaphor was used: it was possible to add new black stones by left clicking, white stones by right clicking, and remove a stone by middle clicking. When designing/copying tsumego, it's common to have more stones from one colour than another, and the possibility to add all the black stones first, then the white stones after is handy. Then, there was a "mode" that could be toggled to activate numbering, so following stones would be numbered, and undo would undo the stones according to the reverse order.

So with a "magnet go board" metaphor, there is no such thing as history of moves, trees or variations. Also, it could not be used to open/export SGF files.

The important thing (in my opinion) was that, although they were not really good with computer skills, we did our best to work out "specifications" about what they needed (this was helped by me having spent quite a lot of time on site, so I knew how it would be used). Among the "specifications":
  • the diagram can be copy/pasted from the software to the Microsoft Word (in fact, WPS, a local clone) so no need to save, then import into Word
  • possibility to only show one part of the board (like top right corner only, or complete left side only)
  • possibility to have the goban in color, or black and white, or grey shades (depending on what they print, to save on ink)
  • a way to somehow "fix" the image resolution so that they can ensure the quality of diagrams is consistent. They were not tech savvy at all, and I implemented a way for them to set a fix number of pixel per goban intersection.
  • Maybe the usual marking (delta, stone) I don't really remember
  • should work on win xp
  • can be ran from an usb stick
  • later, they ask the possibility to save and reopen a position
John Fairbairn wrote:I understand that is there is no incentive for developers. Go books are no longer popular in any format E.g. at one extreme I have an e-book that sells about 9 copies a year. Paper seems more popular, but you are still looking at 100-200 copies a year except for beginners' books. So there is little reason for a developer to expend energy on a rather tricky aspect of programming, especially as the "market" almost demands that programs be offered for free.
I did that for free, and should still have the sources somewhere on my computer, so if some of you are interested, I could release that on Github. (let's see if I can find it and put some screen-shot)

Now, my point is, there would probably be people willing to do such work for free, at least as a way to support the Go community. But I strongly advise you work out a list of specifications for what you need, and go in great details. It helped me a lot at the time, that I had spend hundreds of hours hanging out at their school, so I had witnessed how they teach children.
In comparison, I am clueless regarding the workflow needed to write a book :)

Re: Go diagram advice, please

Posted: Mon Aug 13, 2018 7:28 am
by Charlie
pnprog wrote:But I strongly advise you work out a list of specifications for what you need, and go in great details.
I would be very, very interesting in such a list of real, concrete requirements from Go authors. Oh, and also from people who use an interactive board for lectures, either projected onto a wall, streamed, recorded, uploaded to YouTube or for something I've never even thought of. (I have seen far too many instances of KGS' Cgoban projected onto walls at tournaments.)

Excessive detail is not necessary and might even be counter-productive but, who knows, such requirements could bear fruit.

Re: Go diagram advice, please

Posted: Tue Aug 14, 2018 4:47 am
by Javaness2
I thought I would try to list my own requirements, inevitably I will omit important points.

That the software is fully supportive of SGF.4
That the export formats contain .eps and .svg
That I can create whole board and partial board diagrams
The ability to display move numbers
The ability to renumber moves
The ability to colour/greyscale the diagrams
Ko coverage - the diagram should contain information about (re)captures
The ability to add a Caption or Title to any diagram

It's quite a small list.

Re: Go diagram advice, please

Posted: Tue Aug 14, 2018 8:39 am
by Charlie
Javaness2 wrote: That the software is fully supportive of SGF.4
That the export formats contain ... .svg
Woah! Careful!

Don't be putting those two next to each other or all the file-format standards engineers in the room will be incapacitated by the giggles. ;-)

Re: Go diagram advice, please

Posted: Thu Aug 16, 2018 1:26 am
by Javaness2
Charlie wrote:
Javaness2 wrote: That the software is fully supportive of SGF.4
That the export formats contain ... .svg
Woah! Careful!

Don't be putting those two next to each other or all the file-format standards engineers in the room will be incapacitated by the giggles. ;-)
I can't really titter since it's not my field, but I can have a bit of a rethink on my requirements.
It would be nice to be able to take an editor and type some pseudocode

Code: Select all

LAST 50 MOVES
TITLE Fig.2 (51-100) 
LABEL a4,a b2,SQ o17,b
Then to have a diagram on the basis of that.

Re: Go diagram advice, please

Posted: Mon Jan 07, 2019 7:08 am
by bernds
I hope it's not considered spamming, but I'll link to my announcement of q5go from yesterday, since the SVG export feature I added to the program was mostly inspired by this thread. I'd welcome feedback whether it is useful.

Re: Go diagram advice, please

Posted: Mon Jan 07, 2019 8:41 am
by aeb
I missed this discussion last August, but do have software to produce Go diagrams from sgf files. This was done using LaTeX. This describes the utility sgftopng I have sometimes used. (I am a Linux user, but others have used this on Windows and Mac. The utility can also produce other formats than png.)