[PythonCAD] Next step with DWG/DXF readers

Somerlot, Chris CSomerlot at Brwncald.com
Tue Sep 9 07:48:18 EDT 2003


I agree that making the keys having names instead of DXF codes will make
things easier. I was wondering though how to store entities (which all have
the same codes)? As objects or another dictionary? 

> -----Original Message-----
> From: Eric Wilhelm [mailto:ewilhelm at sbcglobal.net] 
> Sent: Monday, September 08, 2003 7:17 PM
> To: pythoncad at python.org
> Subject: Re: [PythonCAD] Next step with DWG/DXF readers
> 
> 
> > 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
> 
> 
> _______________________________________________
> PythonCAD mailing list
> PythonCAD at python.org http://mail.python.org/mailman/listinfo/pythoncad
> 



More information about the PythonCAD mailing list