Date: Thu, 10 Apr 1997 11:49:29 -0400
From: David Fotland <fotland@hpihoah.cup.hp.com>
Subject: Re: SGF FF[4] - some answers 

> 
> So let's start:
> 
> Pass '[]' issue:
> I'll include Anders' proposal in the standard:
> > for boards with size <= 19, allow [tt] as a legal FF[4] alternative 
> > representation of Pass, in addition to []. Programs have to read both, 
> > but you're free to choose which representation to write.

Great!  This was my main objection to writing FF[4], so now I can probably
do this.

> 
> Anders writes:
> > I don't like the restriction of LB to 3 characters. The file format 
> > should not restrict this, but rather people need to be aware that the 
> > display of labels may be restricted to 3 or even 2 characters on some 
> > systems. There are always ways to show more than that, e.g. using 
> > tooltips. I'd prefer the length of label text to be unlimited, but at 
> > least it should correspond to the FF[3] restriction of 4 characters. 
> > (This is not important enough to create a distinction between the two 
> > file formats.)
> 
> I agree. I know that a lot of you hate labels with unlimited length.
> But we should at least increase it to 4 chars as in FF[3].
> Again: why not allow longer labels but make it very clear that not
> all programs can display labels longer than 3 chars?
> Then the restriction wouldn't be in the fileformat but in the applications.
> It's just like rectangular boards & boards >19x19.
> The fileformat allows those boards, but not every app does support them.

This is OK with me.  I will display 2 or 3 characters, depending on the
board size and screen resolution.  I like Ander's tooltip idea.

> 
> 
> Some answers to David's questions:
> 
> > for converting from Ishi, I can't deal with some of the formatting 
> > requirements for game info - ince Ishi Format fields are free format.
> Then just move these non-standard info's into the GC field.

OK, I can do this.

> 
> > I don't like formatted text anyway, and planned to ignore your
> > formatting rules.  I have a comment text window, which will have different
> > size depending on the screen resolution and board size.  I plan to fill 
> 
> I don't understand this. The spec says: word wrap all lines that don't 
> fit onto the display (just like your paragraphs). So why not handle
> it the standard way? Different resolutions can't be the reason.

Example:

Input is:

In this game the two professionals act like children and
start a hige battle for control of the entire board.  There
has never been a game like this before in the history of go.

If I have a narrower text display, and I wrap long lines, but
preserve line breaks from the original, I get:

In this game the two professionals act like
children and
start a hige battle for control of the entire
board.  There
has never been a game like this before in the
history of go.

This looks awful.  I will ignore the line breaks in the original,
and fill the text like:

In this game the two professionals act like
children and start a hige battle for control
of the entire board.  There has never been a
game like this before in the history of go.

Word wrap is not enough.  I have to fill paragraphs to make the text
look good.

> 
> > Right - no spec!  I've seen files without a ; before the root node,
> > files with moves in the root node, and many other problems.
> Moves in the root node are legal. They are bad style though.

I can't handle moves in the root node, so I correct the file by adding
an new node after the root to hold the move.

> 
> > Third, the triples for describing the position are confusing.  For example
> > DM (even position) is mentioned in FF[4], but is not in Martin's spec
> It is in Martin's spec. Have a look again.

We probably have different versions of Martin's spec.

> > Do people find these generally useful?  I'd guess not since the definition
> > changes so often.  Is it legal to have several of these in the same node?

Do people use these triples when they edit games?  I don't see them much.

OK.  For the moment I'm ignoring all of these, and not allowing the user
to add or change them.

> 
> Having several properties in the same node: FF[3] doesn't say anything about
> it. FF[4] says it's illegal to e.g. mix BM & TE in the same node, because 
> they are mutual exclusive. But you might have e.g. GB,TE in the same node.
> 
> > Another suggestion for the FF[4] Specification: include a list of
> > recommended obsolete properties to parse correctly and convert.  This
> Will be done.

Thanks.

David