DWG Support by Rallaz

Thanks to cox on IRC I've found[1] that Rallaz is working on it[2]. Let me know if I can be of any help with that.


[1] - http://riesvantwisk.com/cms/home/irc-logs/librecad-irc-log/2013/March/7.html
[2] - https://github.com/Rallaz/LibreCAD/tree/dwgsupp

I suppose help is needed here, since development time for Rallaz is badly needed and never enough.

Nicu Tofan wrote

Thanks to cox on IRC I've found[1] that Rallaz is working on it[2]. Let me know if I can be of any help with that.


[1] - http://riesvantwisk.com/cms/home/irc-logs/librecad-irc-log/2013/March/7.html
[2] - https://github.com/Rallaz/LibreCAD/tree/dwgsupp

I also tried reverse engineeering of DWG. It is a binary file.
I opened it with hex editor and tried to understand.

Oh, I'm sure it can't be that bad. There must be some previous work that we can rely on.
http://en.wikipedia.org/wiki/.dwg#History_of_the_DWG_format
http://opendesign.com/files/guestdownloads/OpenDesign_Specification_for_.dwg_files.pdf
http://www.iwriteiam.nl/DWG12.html

And that's just from the first two pages of google results.

I started a new dwg library because:

1. license issue, incompatibility licenses with LC and libredwg, to solve are needed to rewrite all LC code, a good idea but very slow and would still be the following issues.

2. libredwg development is quite stopped, I was send a easy to solve bug report with the solution two year ago and today is not implemented and last commits are 13 months ago.
http://git.savannah.gnu.org/cgit/libredwg.git/

3. code very hard to maintain, in my opinion macros are overused doing the code very difficult to read and c++ link is disabled

4. many bugs. If you parses with examples/load_dwg the file R-2001-1.DWG (a dwg v2000 from cben.net) more than half of objects are out of bounds.
This is, most entities are located in position greater than file size.

4.1 Parsing a file with examples/load_dwg the result are diferent in 32 & 64 bits architecture.

5. I do not remember now :-)

Because dxf and dwg kept the same but written differently, I have tried has added code to read dwg files on libdxfrw and is feasible and solve all the above points.

Problems to solve for complete:
1. I need time
2. I need more time...
3. I need... help!!!

If anyone wants to help send me an email, requisites:

Time, of course, get a copy of "OpenDesign_Specification_for_.dwg_files.pdf" and read
https://github.com/Rallaz/LibreCAD/blob/dwgsupp/libraries/libdxfrw/src/dwgreader.h
https://github.com/Rallaz/LibreCAD/blob/dwgsupp/libraries/libdxfrw/src/dwgreader.h
DRW_Entity::parseDwg(...) DRW_Entity::parseDwgEntHandle(...) and DRW_Line::parseDwg(...) in
https://github.com/Rallaz/LibreCAD/blob/dwgsupp/libraries/libdxfrw/src/drw_entities.cpp

Block support are almost ready, but in my recently dead computer.

Next code to be written:
DRW_Text::parseDwg, DRW_Insert::parseDwg, DRW_LWPolyline::parseDwg, etc.
and start v2004 support: class dwgReader18

will continue
Rallaz

Hello Rallaz,

I am working on LibreDWG as GSoC project this year. This post regarding LibreDWG caught my attention.
Regarding point 3, I wanted to know why you considered there is an over usage of macros?
Actually I was creating functions to extract entities and for the 49 entities as in LibreDWG I had to create 49 functions because each function had a struct as return and return type was different based on entity. This caused very much repetition. My mentor "Rodrigo" one of the core developers of LibreDWG has guided me to again use macros to avoid repetition.
I seek your review and guidance on this.

Regarding your 4th point, I changed the load_dwg program according to my requirements and I tested it with example.dwg provided with LibreDWG on both 32 and 64 bits and got the same results.

--
Thanks
GaganJyot