#17 g-iges to stdout generates wrong iges header

[Manfred Spraul]

The output from g-iges can be set with -o file. If this
option is not set, then the output is sent to stdout.
The iges global header contains the output file name,
thus output to stdout is a special case. I think that
case is wrong: there is an extra "," at the end of the
printf line, thus two fields are printed instead of
just one.
This caused import errors when loading the iges file:
the 7th field doesn't contain the integer word size and
the import fails.

Steps to reproduce:

Take an arbitrary .g file:

$ g-iges test.g whatever.bot > test.iges
$ iges-g -o good.g test.iges
<<<<< Import fails.

$ g-iges -o test.iges test.g whatever.bot
$ iges-g -o good.g test.iges
<<<<< Import succeeds.

I've attached a fix, but it's untested.

[Manfred Spraul]

patch with proposal for fix

[Lee Butler]

Logged In: YES
user_id=1179270

We need to check the IGES standard to see if it has ANYTHING to say
about this sort of thing.

[Manfred Spraul]

Logged In: YES
user_id=127784

Do you have access to the IGES standard? I don't have a copy.
If I understood the descriptions I found on the internet
correctly, "," is the field separator. And the current code is

if( output_file == NULL )
bu_vls_printf( &str , ",7Hstd_out," );
else
bu_vls_printf( &str , ",%dH%s" , strlen(
output_file ) , output_file );

Two commas for stdout, one comma for output to file. That
can't be correct.

[Sean Morrison]

Logged In: YES
user_id=785737

This issue has been resolved in the latest CVS, thanks!

[Sean Morrison]

Logged In: YES
user_id=785737

I reviewed the IGES and the code; it indeed looks like a stray
comma snuck into the stdout case. The only place where a trailing
comma would have been valid is in another section where we could
redefine the delimiter to something other than comma. That wasn't the
case in the global header block. The fix was applied.