GOWrite 2.2.1

[lpaatero]

Installing and uninstalling GOWrite 2.2.1

It is possible to have both 2.1 and 2.2 installed at the same time, but I do not recommend it. It is generally better to install 2.2 on top of 2.1. Should one want to revert back to 2.1, just install 2.1 again on top of 2.2. This prevents any adverse interactions between versions. It is not necessary to uninstall other version before installing another version over it.

Questions or comments on this version?

Please post any comments or questions as replies to this post.

If GOWrite is started manually from command line, please use command

Code: Select all

java -Xmx200m -jar GOWrite.jar

GOWrite 2.2.1 contains lots of updates (partial list):

• Support for both sibling-style variations and children-style variations, menu view->Show move before variation.
  
  view->Show Variation Labels shows labels "B", "C" for variations.
  
  Now it is possible to move into variation using keyboard: just press letter of desired variation ("a" is main variation). In order to go to "up and into variation" enter upper case letter.
  
  Wizard to speed up adding multiple diagrams to SGF file (menu file->print&export wizard).
  
  "single window mode": New SGF files are opened into same window, not in new (view->reuse window). This has been (I believe) last significant GOWrite 1.4 feature missing from GOWrite 2.
  
  SVG export for exporting (x)html and svg. Tested with firefox 1.5 and latest Scribus. SVG implementations seem to differ to the point that prevents good working in many cases. When exporting to (X)HTML move comments may use graphics to refer the commented move.
  
  Now it is possible to copy just move, no board at all: select move and edit->copy single move.
  
  Some pre-selected board colors in board color change dialog.
  
  Minor refreshing to visual outlook. Now GOWrite works better with different desktop color settings.
  
  Cleaning help from outdated information done. Help is now divided into use guide and reference sections. Most new features are at least mentioned in help.
  
  Now it is possible to automatically include move number range (like "(1-101)" ) in diagram title. This option can be selected for diagram in diagram settings dialog in detail pane, or set as default in Options->Default Diagram Settings.
  
  Diagram can now include few (ro all) moves from previous diagram. This makes it easy to do diagrams like 1-101, 101-201, where same move is numbered in two diagrams. This option can be selected for diagram in diagram settings dialog in detail pane, or set as default in Options->Default Diagram Settings.
  
  Settings are stored in .gowrite directory in file .gowrite/gowrite22.cfg
  
  Linux rpm installation package installs icon and menu entry.

partially ready features (works, but more features to come):

• Copy wizard to make guided clipboard copies.
  Search engine for searching games in disk. This probably needs wizard-style tool to get started with.

Things not ready:

• Translation of 2.2.1 is NOT (yet) possible.

[agusmba]

I just downloaded, and got a couple of SVGs out. They look good so far.
No problems loading with Inkscape, now to see how Scribus behaves...

I've noticed one thing (maybe it's the same in older versions):
When I insert a diagram just after a capture, and in the options the diagram has "show previous numbers" and not "remove captures", the captured stones are not shown anyway. Is this the normal behavior?

If so, is there a way for diagrams not to remove the captured stones so the exported diagrams can be used in printing?

Will report on scribus. Great so far

[agusmba]

On scribus the diagrams look great too, both color and B/W.

There is a minor thing with the B/W ones, when exporting whole diagrams, there is no "bounding box" like in the color one, and depending on whether there are stones on the borders or not, the actual width of the diagram may be different.

I think it would be better to put a bounding sqare the size of the board (invisible in B/W). That way, color and B/W diagrams would all be the same size.

Besides this also helps select the bounding box in scribus in order to make text flow around

Does this make sense to you?

[agusmba]

Mmm, just found it's really easy to add the bounding box in scribus by hand, so there is really no need.

[agusmba]

Another comment: the menu file->print&export wizard
does nothing in my installation.

[lpaatero]

Thank you for feedback!

Another comment: the menu file->print&export wizard
does nothing in my installation.

This is bug, more specifically interaction of two new features... fix is in next release (2.2.2, probably out soon).

There is a minor thing with the B/W ones, when exporting whole diagrams, there is no "bounding box" like in the color one, and depending on whether there are stones on the borders or not, the actual width of the diagram may be different.

There should be bounding box in all cases (have to check that...), but not all programs do honor bounding boxes. Perhaps I should add some invisible object, so that programs calculating their own bounding boxes would get it right.

When I insert a diagram just after a capture, and in the options the diagram has "show previous numbers" and not "remove captures", the captured stones are not shown anyway. Is this the normal behavior?

It is normal in sense that it got implemented that way:) Probably it makes more sense to not remove captured?

regards
Lauri

[lpaatero]

If so, is there a way for diagrams not to remove the captured stones so the exported diagrams can be used in printing?

To prevent any misunderstanding by other readers: This "show previous moves" is quite special feature, it is not needed in basic printing / exporting. In "normal use" moves after diagram are numbered, and captures are not done. Moves before diagram are not numbered and stones are captured. "show previous moves" can add numbers to stones before diagram, and it seems that it should also prevent removes.

Right now there is no way to prevent captures in moves shown due to "show previous moves".

regards
Lauri

[agusmba]

In "normal use" moves after diagram are numbered, and captures are not done. Moves before diagram are not numbered and stones are captured.

Ok, so I was using diagrams in the wrong way
I didn't remember a diagram would include all movements up to the next diagram.
Sorry for the misunderstanding, all is well now.
Thanks for the clarification!

[agusmba]

There should be bounding box in all cases (have to check that...)

I'm pretty sure the bounding box is there in B/W also, because when I opened it with Inkscape, the paper size was the size of the board.
Instead of bounding box I should have said "invisible board square", as an invisible object. This would help programs that import svgs and lose the bounding box. Anyway, this is not a very big issue.

[lpaatero]

2.2.2 version fixes 3 bugs in 2.2.1:

• Print wizard starts again.
  Captured removal not done for pre-diagram stones.
  Invisible board added to SVG output, when exporting B&W diagram.

[agusmba]

Print wizard starts again.

Nice, I had not seen it before. It works now.

Captured removal not done for pre-diagram stones.

Working as expected, it can be turned on/off via diagram properties.

Invisible board added to SVG output, when exporting B&W diagram.

Very nice. Thank you! That was fast.

I found a small issue with the white numbers in the exported svg:
The option to vectorize the fonts is great, and I will be using it a lot, at least until scribus manages to import text properly from svgs.
However, I noticed that the white numbers are slightly bigger than the black ones (with native fonts, all numbers have the same size). It looks as if the font was "bold" or stroked, but I don't think it is, so there must be something in the vectorization that does it. It's a very minor issue, barely noticeable at all at normal sizes, so I wouldn't worry too much about this one.

Thanks for the quick fixes!
Regards,
Agustín.

[lpaatero]

However, I noticed that the white numbers are slightly bigger than the black ones (with native fonts, all numbers have the same size). It looks as if the font was "bold" or stroked, but I don't think it is, so there must be something in the vectorization that does it.

It is actually not bug at all:)

White numbers in black stones tend to look "thinner" to eye, even when they are actually of same weight. When creating small stones with numbers over 100, this can be really annoying and even limiting factor if nothing is done.

In order to counter this, gowrite makes numbers on black stones bit more thick. But this cannot be done, when using format's native font (at least not easily / reliably).

You can adjust this behaviour: options->fonts dialog has adjustment for this thikness in bottom of dialog.

Current default value (0.56mm) is based on my (limited) experimentation with readability in different move sizes. I would be happy to hear any opinions / experiments on this.

regards
Lauri

[agusmba]

Lol, so I found a feature
I know white numbers should be a bit thicker, but when I compared it with the native svg I thought the native svg was correct. My mistake

It's great that the thickness is a parameter that can be modified. I'll make a few tests, although, probably your defaults are fine.

Thanks!
Agustín.

[Vesa]

The variation labels are a convenient feature. However, the main line is marked with an "A" and additional variations start from "B". I would suggest that the main line is labeled with some other symbol, for example "o".

Vesa

[lpaatero]

I used convention advocated in SGF style guide:

http://www.red-bean.com/sgf/user_guide/index.html

There main variation is 'A' etc. For me it sometimes makes sense and sometimes feels funny (sounds funny when game is variation A...).

Only way to support that and some other scheme would be additional option for seleting the main variation indicator. Have to think about this.

regards
Lauri