libredwg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[libredwg] Re: OpenDWG Replacement - LibreDWG


From: Felipe Sanches
Subject: [libredwg] Re: OpenDWG Replacement - LibreDWG
Date: Wed, 16 Dec 2009 05:17:58 -0200 (BRT)

hello, Till,

I am very happy to hear you enjoyed our work and also that you are offering us some help!

well... the first steps are to get a copy of our current code at git:
git clone git://git.savannah.gnu.org/libredwg.git

and subscribe to our official mailing list:
http://lists.gnu.org/mailman/listinfo/libredwg

At the moment we have practically 100% read support and we are working towards the same goal for write support.
The code has been recently refactored to use lots of C macros since the parsing of the dwg data structures is a very tedious and repetitive task. We have created a file called src/dwg.spec which contains a description of the datastructures defined in the ODA specificacion. These structs are defined mainly using macros. The files src/decode.c and src/encode.c both include this spec file but prior to including it the macros are defined. Let me show you an example:

ODA spec, page 69:

CIRCLE(18)
    Common Entity Data
    Center                              3BD    10
    Radius                               BD    40
    Thickness                          BT    39
    Extrusion                            BE   210
    Common Entity Handle Data
    CRC                                    X    ---

LibreDWG, current git master, src/dwg.spec, lines 661-669:

/*(18)*/
DWG_ENTITY(CIRCLE);

  FIELD_3BD(center);
  FIELD(radius, BD);
  FIELD(thickness, BT);
  FIELD_BE(extrusion);

  COMMON_ENTITY_HANDLE_DATA;


src/decode.c, lines 39-44:

#define FIELD(name,type)\
  _obj->name = bit_read_##type(dat);\
  if (loglevel>=2)\
    {\
        fprintf(stderr, #name ": " FORMAT_##type "\n", _obj->name);\
    }

src/encode.c, lines 39-44:

#define FIELD(name,type)\
  bit_write_##type(dat, _obj->name);\
  if (loglevel>=2)\
    {\
        fprintf(stderr, #name ": " FORMAT_##type "\n", _obj->name);\
    }

This is not exaustive, but can give you a general notion of what is our current strategy.


1) One important thing to notice is that this process is not possible in certain parts of the spec, so we have created 2 macros that are used to declare encoder-specific and decoder-specific routines. At the moment we need to review all of this code looking for places where we need to add write-specific routines. For an example of that kind of thing, please look at the description of /*(7)*/ DWG_ENTITY(INSERT); beginning at line 293 of src/dwg.spec. Finishing this review is one of our current efforts.

2) Another effort is in getting other people to actually use our library. One of the issues have been the typical licensing of free CAD software nowadays. Our library is licensed under GPLv3 or later and we neighter can nor want to change it.
We have figured out that GRASS is a software that uses the proprietary dwg library from ODA and their license is GPLv2 or later, which allows them to use LibreDWG in their code, but then their next release would have to be licensed under GPLv3 or later :-) Rodrigo "pitanga" (the other current LibreDWG developer - it is just me and him currently) is interested in implementing a patch to GRASS to remove ODA dependency and add libreDWG support.  

3) Another effort is the creation of Python bindings for the library. If you have knowledge of that it would be great! Other languages are welcome also, but python is strategic since there are at least 2 free CAD softwares that are implemented in python and could benefit from it.

4) we also need help on parsing the headers of the files. Currently we only support R_13, R_14 and R_2000 header parsing. The other versions have some issues such as usage of Reed-Solomon coding (which we still dont understand well) on R_2007 headers and an unknown decompressing algorithm referenced at page 30 (OdDwgR21Compressor:decompress()). We need to put some effort in properly implementing these headers and we also need to make them suitable for both read and write routines.

5) And, finally, we also need to test everything to see if it is really working :-) Currently we have a dwg to svg converter written as an example of how to use the lib and it works in some relatively simple 2D cases. But we need some more exaustive testing (preferably some automated test suite).

Feel free to select some of the 5 tasks above to help us, or to suggest some other task you think could be important for the project. Keep us informed about what you are working on so that we avoid unnecessary duplication of work. If you code something, please send us a patch.

Happy Hacking!
Felipe "juca" Sanches

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]