[PythonCAD] Next step with DWG/DXF readers

Eric Wilhelm ewilhelm at sbcglobal.net
Mon Sep 8 19:17:11 EDT 2003


> The following was supposedly scribed by
> Art Haas
> on Monday 08 September 2003 04:42 pm:

>What is written above is just a starting point. I'm thinking that each
>entity should be returned as a dictionary, with each key being the DXF
>code for the component of that entity, or maybe the key being a
>descriptive string.
>

Sounds good to have the key be the dxf code, but I suggest building the codes 
into your library as constants (DWGLINE, etc), so that they can be referenced 
by your code and those of others (I'm hoping to build a Perl wrapper on you 
python library.)

>While trying to write this I'm hoping to make things useful so that
>people not using PythonCAD could still get these DXF/DWG readers and
>maybe use them for projects of their own. I can see some clever person
>writing a {DWG/DXF}->SVG converter, or converters to other cad formats.
>
>Ideas welcomed. Perhaps people using the OpenDWG libraries can chime in
>with some suggestions.

I've been using the OpenDWG libraries in my Perl module, and what you have 
seems to be the same approach to the interface.  Since their libraries aren't 
open source, I can't say much about the internal design, but I can take some 
not-so-blind stabs at suggestions for an approach:

Would the class be a fully-loaded data structure, or more like flat-storage of 
the file loaded into memory (and maybe broken into accessible chunks?)

If you intend the library to be used by others and in multiple languages 
(maybe only possible via Perl using Inline, but you could at least embed the 
Python into C), It would be better to have a two-stage library.  The first 
stage would be loading the file into 3-4 large chunks (or something of the 
sort) and the second would be bringing the data into the main program.  This 
may also allow you some code re-use in supporting multiple versions and 
formats via your library.

As a sketchy example, say you can find a way to simply load the header, class 
data, and entity data into somewhat flat memory in a way that makes all files 
(dxf, dwg, r14, r15, etc) look the same and then have slightly higher-level 
functions that give you access to that data (still one level below the 
cadfile.getHeaderData() function in your fictional code).  Now you just need 
a handful of functions to load the data into your favorite pythoncad data 
structure and I would only need a handful of wrapper code to get it into my 
favorite Perl data structure.

The strategy that I am trying to lay out is that:
	1.  You have the very low-level functions which parse the file and need to be 
customized to the format or release number.  Hopefully, these could be as 
short and simple as possible to allow you to easily add support for other 
entities and releases.  They would need to simply slurp the file into a few 
memory locations and into a shape that would be predictably accessible 
regardless of the file version / type.  

	2.  This predictable, flat memory can be quickly seeked by mid-level 
functions which don't necessarily have any knowledge of the overall database 
information or the destination data structure (worker bees.)  These functions 
would also be the ones which would be most useful via other languages 
(hopefully returning the simplest value/structure possible to allow easy 
translation via typemaps.)  If you can avoid tying this level of functions to 
a data structure, I think you will get the most flexible and robust library.)

	3.  Utilize the level 2 functions via a few high-level functions customized 
to PythonCAD (which gives you relatively little to maintain should you change 
your mind about its internal design (and the same benefit to others using the 
library.))

For writing files, think 3,2,1  where the data hopefully looks the same at 
level 1 whether it is coming or going.

My thoughts here are mainly to minimize the memory use and the amount of CPU 
time spent in the library.  I would hope that it is possible to minimize the 
amount of code involved at levels 1 and 3 so that you end up with as much as 
possible in the middle.

Have you looked at the Dime dxf library?  If I get a chance, I'll dig around 
in it and see what I can learn from that design.

--Eric

-- 
"These crispix get soggy so quickly."
                                        -- Tina Connolly




More information about the PythonCAD mailing list