artasparks
commented
9 years ago so I suggest that our implementation should support move numbers up to three digits in length (or maybe of arbitrary length) with (optional) zero padding to maintain a nice, human readable alignment.
I don't think our goal should be to reinvent an ASCII format, just to parse what currently exists.
There is one big trickiness with ascii formats: How big is the board? it's a little tricky, especially if the user has chosen to crop the board in some non-trivial way.
dormerod
I'd like to work on a parser for ASCII formatted (human readable) Go diagrams.
I propose we call this format ASCII, rather than Sensei's format, forum format or something else, because its use predates Sensei's Library (e.g. in newsgroups, email, old Go websites, command line Go programs etc). There doesn't seem to be any reference to ASCII in the existing codebase for Glift, so I don't envision any conflicts at the moment.
The 'standard' ASCII format looks like this and can be generated by various SGF editors:
The Sensei's Library/Forum extension looks like this:
These formats are similar enough that the parser should be able to handle both of them. The dollar signs have limited meaning in our case, so we can easily strip them out.
One of the existing issues with these diagrams on sites like Sensei's Library is that move numbers in diagrams can only go up to 10 (represented by 0) after which you need to continue with a new diagram, where the previous moves have been flattened.
My experience is that this can be very frustrating and limiting, so I suggest that our implementation should support move numbers up to three digits in length (or maybe of arbitrary length) with (optional) zero padding to maintain a nice, human readable alignment.