I've been writing an SGF parser and was somewhat surprised to see that the SGF format includes support for lines and arrows from one intersection to another. This sounds like a very useful feature but I don't recall if I've ever seen it used.

What SGF editors/viewers support this feature?

Damn few. It's supported by the Sensei's diagram generator thing we use here, but I don't know of anything else. I've wanted to add support to EidoGo, but haven't ever gotten around to it.

_________________
KGS 4 kyu - Game Archive - Keyboard Otaku

It appears that the SGF viewer I have been using, MultiGo, doesn't even support compressed point lists.

It and CGoban3 also don't appear to handle soft linebreaks. It also seems odd that CGoban also does not supported the dimmed markup, as it is clearly capable of dimming points as it does so when using the score tool to mark a group dead.

Quarry supports it, but the feature is not actually used for general markup, it is only for the game Amazons.

Should be pretty easy to make it work for the general case though (just remove an if statement in the sgf-parser) - we don't have an "arrow drawing tool" though. Should I add one?


EDIT: I'm sorry, I was looking at "AA" (add arrows) instead of "AR" (arrow markup) - Quarry understands what AR means, but doesn't actually do anything about it at the moment. Sounds like another feature to add... soon as I finish UGF import (grumble...)

Although I've had a little time to work on it recently and I've got the header parsed now! Here's my latest debug output:

UGF Property: Title, Value: ,Michael Redmond's "Perfect Commentary" VOL.223,
Property: GN, Value: ,Michael Redmond's "Perfect Commentary" VOL.223,
UGF Property: Place, Value:
UGF Property: Date, Value: 2009/04/30,00:00:00,2009/04/30,00:00:00
Property: DT, Value: 2009/04/30,00:00:00,2009/04/30,00:00:00
UGF Property: Rule, Value: JPN
UGF Property: Size, Value: 19
quarry: sgf-tree.c:293: sgf_game_tree_set_game: Assertion `tree' failed.


Place should be translated to "PC" - I didn't notice that until copy/pasting just now for some reason. Size doesn't have debug output because it's breaking out to a separate function which sets up the board... which is failing and I haven't had a chance to really dig into it yet. (fixed partially while typing this - PC and RU are getting read now; if I can fix the tree pointer before work I'll be almost done... I hope)

It seems like most SGF editors are kinda "stuck". They're sorta satisfied with the state of SGF and don't feel like adding some of the newer features, even though the format has been stable for many years. Like, nobody uses markers like GW, GB, BM, TE, IT, etc. I think they would be good for SGF problem collections. And I think lines and arrows would be awesome for reviewing games on KGS.

_________________
KGS 4 kyu - Game Archive - Keyboard Otaku

I agree that line support on KGS would be a great addition. Many times I have seen people in reviews attempt to draw lines staircase- style with the square markup tool. Real lines & arrows would be incredibly useful for explaining radiating influence, sector boundaries, illustrating moyo, etc.

I imagine there's a bit of a chicken & egg problem. Perhaps Go software authors don't feel a need to introduce such features since SGF files that use them are so rare. But there will never be any SGF files that use them if no editors support it!

I decided to implement lines & arrows in my project. I have them working, but there are some interesting considerations to make:

• What color should lines & arrows be? Should they be different colors?
• When an arrow is drawn to a cell containing a stone, should it touch the center or outside?
• Should arrows be drawn ontop or underneath other markup?

I would value any input

Personal preferences: Red arrows are easy to see with the board and stone colors.
Arrows on top makes sense and seems visible enough.
Drawing the arrow from center to center seems fine.

_________________
Someday I want to be strong enough to earn KGS[-].

Red is often bad for color-blind people (1/15 of men are substantially color-blind). It's not actually a disaster in the above diagram, but the blue has much better contrast.

_________________
Occupy Babel!

In the few situations where I've actually seen the lines and arrows supported, they've been blue (e.g. try the line and arrow code in the diagrams for the fourm). IIRC, we actually have at least one color-blind forum member who might be able to help you with color selection...

_________________
KGS 4 kyu - Game Archive - Keyboard Otaku

No experience with it, but there's a web based color blindness image filter. If you google color blind filter, you'll get one that operates on webpages.

_________________
Occupy Babel!

Your black stones appear as if they were smaller than the white ones.

The arrows should approach the centre of the target intersection, but not cross it.

I think that the arrows and lines should go over the stone markup, but be thin enough not to cover them completely.

_________________
A good system naturally covers all corner cases without further effort.

Thank you all for your input. The color-blind filter was very interesting. I added an outer stroke to the arrow rendering so that they stand out a bit better.


This is a known optical illusion - see mention of it here http://www.kiseido.com/go_equipment.htm I will probably render the white stones slightly smaller to compensate. I'm not entirely happy with the gradient I am using for the black stones either, which probably only worsens the effect as it lightens the edge of the stone as a 'shiny' effect. It looks nice when the stones are large but adds aliasing problems when the stones are this small. Perhaps I will use different gradients at different stone sizes.


Should be fixed now.

The actual width of the arrows & lines I am not sure of.

If there is no compelling reason to color lines & arrows differently, I think I will draw them both in the same style.