User: Fefcas
m |
(Some annotations) |
||
| Line 1: | Line 1: | ||
| − | I'm Felipe Castro, a brazilian electrical engineer, and I | + | 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. | + | 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 | |
| − | + | ||
| + | == 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). | ||
| + | |||
| + | === Types >= 500 === | ||
| + | |||
| + | Objects with variable types (greater then 499) are taken as "unknown" and discarded, because it seems to me there's no handling on classes information for now. | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | === 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! | ||
Revision as of 19:45, 18 August 2013
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).
Types >= 500
Objects with variable types (greater then 499) are taken as "unknown" and discarded, because it seems to me there's no handling on classes information for now.
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.
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!
