[GRASS5] v.out.dxf: small updates to DXF12 but RFC first

[Bernhard Reiter]

On Sun, Aug 24, 2003 at 06:23:14PM +0200, Thierry Laronde wrote:
> I want to update a litle `v.out.dxf', mainly because setting $LINMAX and
> $LINMIN is merely ignored by some applications (it seems -to be verified-
> that the limits are set via $EXTMAX and $EXTMIN; hence an imported GRASS
> generated DXF file may result in an apparently empty drawing).
> 
> Since I have only dxf_r12 at hand, this means updating from DXF10 to DXF12
> (at the present state, this doesn't mean a lot : just advertising ACAD version
> and changing what mentionned above).

It probably would be interesting to keep compatibility
with both versions of the format, maybe an options could switch
from one format to another.

> There is more work to do but I don't have the time yet. Some couple of things
> disturbe me a little and I need to know if changing something there is 
> acceptable or not :
> 
> - a header file is a "zero object file" (i.e. it is here for the compiler
> but doesn't result in any actual code/storage in the binary). Creating a real 
> dxf_<version>.h header and a separate dxf.c library is it acceptable if I
> do not rewrite intensively the code (because this will cause the
> classical problem with renaming in CVS causing more work on
> administrating the repository than had been actually put on the
> rewrite)? Or should this be postponed till
> a major rewrite is completed (I'm for the latter).

Both strategies are fine I think.
Doing the cleanup first also has its merits.

> - could the "dead" code, after verifying that the live one is
> up-to-(that)date be thrown away, decreasing the size of the
> tarballs and the size of the code willing developers will be
> facing (I mean both the backup repertory and the defined OLD
> sections)?

Yes, definately.
CVS and old tarballs will preserve the history,
but there is no real use for old non-active code.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20030915/6f9f711f/attachment.bin