Hello,
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).
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).
- 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)?
TIA.
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
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.
On Mon, Sep 15, 2003 at 11:22:10AM +0200, Bernhard Reiter wrote:
On Sun, Aug 24, 2003 at 06:23:14PM +0200, Thierry Laronde wrote:
> I want to update a litle `v.out.dxf', [..]
>
> 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.
Yes, at least a switch between R14 (I've finally found some doc) and
R11/R12 (older DXF import module should deal with it without much
ado).
I have decided to rewrite it entirely (and I think too v.in.dxf)
but this will be done for 5.7. The quick patches I could give for
now are not addressing the more important needs, so I don't think
it's usefull.
Cheers,
--
Thierry Laronde (Alceste) <tlaronde@polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C