julianandrews / sgf-render Goto Github PK

There should be a flag that allows marking the last move made (possibly with a +).

Apologies if this is the wrong place to leave this. But when you try to render from a SGF gotten from IGS/PandaNet, you receive the error: "Failed to load SGF node: Error tokenizing: Unexpected end of property". It seems that the only issue is with the copyright section from the IGS/PandaNet SGF, as when I remove that line from the SGF, it renders.

with 02.sgf , we show step 1 without black stone outline, which should be shown as custom tradition convention

with 01.sgf , we show even no step 1, as convention, we should show text "3 = 1 " at bottom, and step 3 is still on image with stone outline

sgfs.zip

I should be able to more or less copy the CI from sgf-parse to build and lint this, as well as running any unit tests I write.

• I am looking for a technical roadmap to realize the read/write of the full information of an analyzed kifu.
• A complete kifu can be render in an image in a Go book.pdf, why not conversely(SVG is editable)?
• Why not SGF or why SVG? It seems that the SGF standard doesn't change since 2007. However, the Go analysis has changed since AlphaGo 2016. The information of an analyzed kifu are much more than ever, i.e. win-rate, visit/playout, ownership, see KataGo GTP Extensions for more.

It would be nice to have a way to specify the labels to use.

Implementation should be easy, but the CLI UI design is a little tricky. I think I probably want independent flags for the --x-labels and --y-labels but I'm not sure what they should look like.

Ideally, I'd like to support

• A fixed list of labels or
• Ranges of characters (something like A-Z)
• Numbers (same as ranges of characters?)

Besides figuring out what an argument that allows that would look like, I also have to worry about label length. Options:

• Only allow single unicode character labels
• Resize margins to allow longer labels, and display x-label text vertically

That second option is definitely a lot more work, and finicky (since SVG 1.1 text rendering isn't the most graceful), so at least for the first version of this, I'm thinking to limit labels to one character.

This should be easy enough to implement once I decide how to answer these questions, but I'm not really happy with any of the UI options I can think of.

This is split off from #12.

Right now we don't support annotations at all. It would be nice to include them (and comments).

At a minimum we need support for adding annotations indicating overwritten move numbers when rendering those!

See #6

Original issue: julianandrews/sgf-parse#17

It would be good to add an option to draw coordinate labels on all four sides of the board.

Actually, it would be good to generally support more coordinate options, so I should at least figure out what the CLI options will look like. Ideally it would be possible to specify:

• Which of the four sides to draw coordinate labels on
• Direction of the coordinates (for horizontal/vertical independently)
  • I think right now, the letters may be going reverse of what you'd expect
• Maybe an option to specify the labels to use for horizontal/vertical labels
  • This way users could use numbers on both or letters, or could choose not to skip 'I'

This is going to require a bit of a refactor. If I remember right, there's a bit of a mess between the scaling logic and the labeling logic that doesn't make this easy.

Hi! Finally I found a simple working and modern project which did what I needed. Thanks for setting this up.

I'm planning to use this to create some notes on various endgame situations, and one very common usecase for me would be to show both the move numbers (to show possible endgame sequences), but also keep the markup which is used to highlight the respective point differences. I assume the reason why move numbers disables markup is because you couldn't show both when they're both located on a stone (or you might, but it would be confusing anyway). But in my use-case, the markup would only be in the empty intersections anyway. Would it be possible to include this feature? Removing the markup only from the numbered moves would be sufficient for my use case.

Thanks again!

In particular, the default of showing the first node is often confusing, and a short sentence would probably help with that.

See #20.

Now, --first-move-number 51 --move-numbers 100 produce 1,2,...,50 numbers in the output

I need 51,52,...,100 numbers in the output

P.S. sgf-render near perfect tool! after some minor improvements, it has the potential to become an almost ideal solution for creating diagrams

01.sgf.zip

mac bin v1.3.3
not show moves (this case B[br] in attached sgf)

sgf-render 01.sgf -r am-ls --style minimalist -o a.svg --no-board-labels
sgf-render 01.sgf -r am-ls --style minimalist -o a.svg --no-board-labels --move-numbers

neither works

I should add a bunch of integration tests.

At a minimum, I'd like to test move numbers, markup, node selection, and different styles.

Probably it makes sense for all the examples I'm currently using in the README to come straight from the integration tests.

Right now, --kifu mode doesn't pay any attention to --first-move-number which could lead to annotations pointing to unmarked stones.

Instead, --kifu mode should:

• only show annotations for stones in the numbered range,
• they should only point at stones actually marked on the board, and
• move numbers should show on the first stone in the requested range that has a number.

See https://www.reddit.com/r/baduk/comments/plmunm/new_version_of_sgfrender_cli/hcimtt0/ for context.

When rendering to PNG the arrows aren't getting rendered.

.

The vertical layout for the text seems to be off:

Interestingly, the issue doesn't seem to happen if I open the SVG directly in Chrome. I think there must be some elements of the SVG spec I'm not quite respecting right.

The text moves in the box at the bottom are not centered in the box. Some text is on the top line.

the box is off to the right, when coordinates are not on , but ok when coordinates are on.

nice program by the way.

Not many good native options on linux.

Mybe have an option to include sgf header section such as players, komi, result, etc.

I like to have 4 diagrams, 1 to 50, 51 to 100, 101 to 150, 151 to end. On one page in two columns.

And a convert to pdf option but I can use rsvg-convert which works well to centre the svg on a page.

All the best, Neil

Right now, if there are any setup properties between the numbered moves in --kifu, the program ignores them.

I don't think there's a sensible way to handle those properties, but probably at least we should detect them and throw an error.

opened new issue, ref: #29

The first line of annotation text is outside the box.

Thanks for the quick response. I've put a link on Sensei library for sgf-render as I'm sure others will find it useful too.
Neil

Hello, Julian.
Thank you for this great and helpful project.
But I have one issue with SGF-formats. For example, I use the game in SGF-format from https://github.com/featurecat/go-dataset.
Link to file example in SGF-format: https://drive.google.com/file/d/1a5a7kD3bQFIR-_CY5HBbfeZzH6WDVddG/view?usp=sharing
Then, I run path/to/repo/target/release/sgf-render path/to/file/1486988818019999291.sgf -o test.png.
And this command generates an empty board correct size (board without stones, but with correct dimension).
I also tried SGF-format from https://online-go.com/, and it does not work for me also.
Link to file example in SGF-format: https://drive.google.com/file/d/1OH5L7aqDV3Bf1gzeWeKTPnEZ0isqmsNb/view?usp=sharing
I guess it's because SGF-format in this file contains chat messages and other metadata from the site, I tried to clean it, but still does not work (but it was like monkey cleaning :) ).
Your sgf-render/tests/data/prob45/input.sgf work clearly for me.
Again thank you for your work and apologize if I haven't figured out your project clearly and this issue is trash.

If it will be useful:
cargo 1.46.0

Right now I'm just calling display on a float. As a result, floats that aren't precisely represented by a few digits are stupid long. There's no need for that!

It could be useful to pick out a variation, and then go to the end, and this should be a 100% backwards compatible change.

Shrink wrap can cut off the board edge in a way that's confusing.

If going one tile further would show the edge of the board, I should include that!

Possibly there should be a separate option to do the dumb shrink wrap? Or maybe no one cares - you can always use an explicit range.

It shouldn't be hard to read the style for from some sort of markup (either yaml or toml).

The various colors can just be strings, defs can be a list of svg element strings, arrowhead and linehead can be marker elements.

The only tricky part is that draw stone will need to be refactored. I can either take an SVG and scale/translate it, or I can take an SVG template and substitute in the coordinates. I'm leaning towards the second since I don't want the final SVG to be full of unecessary transforms.

Right now the default behavior is to render the root node. the --node-num argument can be used to render other nodes on the main variation, but there's no support for rendering variations. Fundamentally, this should be easy to implement if I can come up with a satisfactory way to specify a variation from the command line.

Most paths will be long sequences of "take the first node x times, then switch variation."

I'm leaning towards something like 20,3v12,2v10 which would mean "go 20 moves, switch to variation 3, go 12 more moves, switch to variation 2, go 10 more moves." A nice thing with this is that simple numerical paths retain the same meaning (well, there would be 0 vs. 1 indexed difference - I should never have 1-indexed).

          sorry, another bug...

When doing something like this:

for m in {50,100,150}; do sgf-render input.sgf -o move-$m.svg --move-numbers --node $m --first-move-number $(( $m - 49 )); done

The annotations at the bottom box keep the original move numbering in the sgf, and not the --first-move-number change.

Originally posted by @AprilInParis in #29 (comment)

The current system is functional, but pretty confusing. Looking at sgftopng, a system of labeled variations and a way to query the sgf to get the variation numbers seems like a winning combination. See the docs here for inspiration.

Right now, specifying no output means the program outputs an svg to stdout. I'd like to have a -format or -f option with options png and/or sgf. Should have a pull request ready soon.

I should add a flag for generating kifu. When using --kifu:

• --move-numbers will be enabled
• --node will default to last
• Captured stones will still be displayed on the board.
• Annotations will be added to the bottom showing repeated stones
  • Each repeated mode will get its own entry referencing the first stone played.

See issues #6 and #9 for more context.

I should, at a minimum add a test that verifies that a standard sgf generates a reasonable svg with all default settings.

Ultimately lots of tests by feature would be a good idea.

See #6.

This should definitely be the default for the minimalist theme. I'm not 100% sure I want to do the same thing for other themes.