User: Fefcas
I'm Felipe Castro, a brazilian electrical engineer, and I worked somehow with CAD drawings, stuck with the AutoDesk one-and-only-one solution.
My interest here was to develop a dwg read-only library, so that free CAD programs can import them and translate the data to new free formats. In august 2013 I renewed my interest in this and try to contribute in Group:LibreDWG.
Contact: fefcas at g mail
Contents
LibreDWG ideas
Main DWG struct
Thinking about the differences between an ENTITIY and an "OBJECT" (according to DXF specs) I wonder if it's not apropriate to use these relations:
- An object can be two kind of things:
- A graphical object is an ENTITY (obj->as.entity is ok)
- A non-graphical object is a NONGRAPH (obj->as.object is kind of weird!)
Then the common data between these both would be in the main OBJECT struct:
- type
- handle
- extended data
And NONGRAPH objects would have further:
- Object specific data
- Strings (optional)
- Parent handle
- Reactor handles
- Xdict handle (optional)
- Object specific handles
While ENTITY objects would have these:
- Graphic image (optional)
- Graphic parameters and flags
- Object specific data
- Object specific handles
(1) The extended data is modeled as pertaining to ENTITY and NONGRAPH separately for now. But it could be put one level up, in the OBJECT struct, removing duplication of code when decoding (or encoding) the DWG bit-chain.
(2) The same could be done with the object specific handles.
(3) Changing code like "obj->as.object" to "obj->as.nongraph" could be more elegant.
Objects scanning
The object map bit-stream seems to be difficult to be acquired, one have to pay attention to it. I guess there are errors in the code there. Maybe the best approach would be scanning the objects directly, using the last instance of objects eventually found with same handle (as ODA suggests).
I have tested it and now I know: it is buggy. I didn't succeed to scan correctly objects, some times the handle offsets get disturbed and out of reasonable ranges. So, ODA suggestion to scan directly in the object area is something to take seriously.
Extended data
The code for encoding and decoding are not equivalent. Anyway, they seem to be wrong, according to last ODA specification. I don't remember well, I think the ODA spec was confusing about this when I used it, so a review is necessary here.
Testing
Checking reasonable data ranges for each property of read objects, like a sanity check. It would work online and could avoid many seg-faults. It would be enabled by a debug switch in the package configuration step.
Bindings
What about that thing of making the binding stuff optional?
R13 and R14
These are too old, I would simply not waste time mangling with them. New AutoCAD software does not bother with R13 anylong.
Go away, buggy R13!
Writting (un)feature
I discourage any attempt to encode a DWG file, mainly because it is kind a promotion for that dirty thing. Read-only is my first and last goal.
