From guy_j_edwards at HotPOP.com Mon Sep 1 01:46:17 2003 From: guy_j_edwards at HotPOP.com (Guy Edwards) Date: Tue Sep 2 09:12:09 2003 Subject: [PythonCAD] New test drawings up In-Reply-To: <20030831174431.GB609@artsapartment.org> References: <20030831140348.GC28018@artsapartment.org> <1062338783.2584.25.camel@linstation> <20030831174431.GB609@artsapartment.org> Message-ID: <1062376020.2623.36.camel@linstation> 10 new DWGs are up, they cause errors with your new script. http://lx-viewer.sourceforge.net/dwg/dwg.php Big improvement though. Error rate previously was 100/940 = 10.6% error @ Sat 30th Aug. Error rate is now 36/2218 = 1.62% error @ Sun 31st Aug Please can you put a license header comment on your file? Let me know when you're done with those, Guy On Sun, 2003-08-31 at 18:44, Art Haas wrote: > ... with the version of the script attached to this mail. Thanks greatly > for making them available. Lots of fixes in dimensions, spline, ellipse, > and other entities in the DWG files. > > Art -- Guy Edwards From guy_j_edwards at HotPOP.com Mon Sep 1 23:45:04 2003 From: guy_j_edwards at HotPOP.com (Guy Edwards) Date: Tue Sep 2 09:12:10 2003 Subject: [PythonCAD] pydwg 0.33% err Message-ID: <1062455385.2585.50.camel@linstation> Ok, I tested against 14756 files, 48 gave errors = ~0.33% error rate. There are 10 new drawings up on the website that I think you're probably already aware of. These are 10 of the 48 that caused errors, std err and std out is there with them as before. http://lx-viewer.sourceforge.net/dwg/dwg.php Once you've nailed those I'll test again, and if it's fine, convert all the drawings to R12, R13 etc and try again for each version. I had a quick look at the PythonCAD mailing list archives and noticed there'd been some replies so I thought it only polite to subscribe. Guy ------------------------------------------------ Report for DWG.py testing ------------------------- Compiling list of files that created errors.......... Complete file listing has been placed in /home/hairball/report.txt Number of enteries: 14756 /home/hairball/report.txt List of error producing files has been placed in /home/hairball/errors.log Number of enteries: 48 /home/hairball/errors.log errors were generated 6529.66user 378.88system 2:01:18elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (8537842major+29774975minor)pagefaults 0swaps (AMD 1400, 256mb ) -- Guy Edwards From ahaas at airmail.net Tue Sep 2 13:32:51 2003 From: ahaas at airmail.net (Art Haas) Date: Tue Sep 2 13:33:05 2003 Subject: [PythonCAD] DWG Reader update Message-ID: <20030902173251.GA31053@artsapartment.org> Hi. The drawings on the lx-viewer site have been great for flushing out bugs. The pointed out a bug reading the extended entity data - a patch for which I've included in this mail. Other drawings which I have been sent are failing when reading the second header section. This is disturbing because the drawings are following the layout described in the OpenDWG spec. I'll be working on this stuff today. The patch below fixes a trivial byte count typo and makes most of the current lx-viewer drawings work. There is still one or two other errors two fix. Art Index: Generic/dwg.py =================================================================== --- Generic/dwg.py (revision 645) +++ Generic/dwg.py (working copy) @@ -3850,7 +3850,7 @@ for _i in xrange(8): _bitpos, _char = get_raw_char(_data, _bitpos) print "char: %#02x" % _char - _count = _count + 1 + _count = _count + 8 elif (0xa <= _cb <= 0xd): print "three doubles" _bitpos, _d = get_raw_double(_data, _bitpos) -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Tue Sep 2 15:07:44 2003 From: ahaas at airmail.net (Art Haas) Date: Tue Sep 2 15:07:53 2003 Subject: [PythonCAD] DWG Format searching Message-ID: <20030902190744.GE31053@artsapartment.org> Hi. The DWG file readers that I"ve written are for version R12, R13, and R14. I have a file 'formatSpec13-15.rtf' from the OpenDWG people that includes info about the R15 format, which is the AutoCAD 2000 format I believe. I don't have a program that can convert the rtf file into something more readable, so I'm going to ask a favor from someone and see if they can convert the file into something like plain text or HTML pages. Either is much more readable than rtf. Also, I'm looking for info on older versions of the DWG format. The docs I found on the R12 format say that this format is basically the same as that in older Autocad releases - can anyone confirm this? I don't have any files older than the R12 files I was mailed. I'd also like to match up the Autocad release with the file format. Can people correct and fill in the following table: Release/Version: Autocad?:??? Autocad9:??? Autocad10:??? Autocad11:??? Autocad12:R12 Autocad13:R13 Autocad14:R14 ... Autocad2000:R15 (?) ... Autocad2004:??? Have I missed releases, or made up versions that never shipped? How about releases prior to Autocad9? Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From guy_j_edwards at HotPOP.com Tue Sep 2 21:00:32 2003 From: guy_j_edwards at HotPOP.com (Guy Edwards) Date: Tue Sep 2 16:00:35 2003 Subject: [PythonCAD] DWG Format searching In-Reply-To: <20030902190744.GE31053@artsapartment.org> References: <20030902190744.GE31053@artsapartment.org> Message-ID: <1062532536.2586.41.camel@linstation> On Tue, 2003-09-02 at 20:07, Art Haas wrote: [snip] > Either is much more readable than rtf. I can convert it if no-one else has already. > Also, I'm looking for info on older versions of the DWG format. The docs > I found on the R12 format say that this format is basically the same as > that in older Autocad releases - can anyone confirm this? I don't have > any files older than the R12 files I was mailed. I can convert files to v2.5, 2.6, 9, 10, 11 and you can have a go. > I'd also like to match up the Autocad release with the file format. Can > people correct and fill in the following table: [snip] > Autocad2000:R15 (?) R15 format is the same as 2000i and 2002 as well I thought. [snip] > Have I missed releases, or made up versions that never shipped? How > about releases prior to Autocad9? there are v2.5 and v2.6 files as mentioned above which were prior to v9. Guy -- Guy Edwards From ewilhelm at sbcglobal.net Tue Sep 2 16:25:49 2003 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Tue Sep 2 16:25:33 2003 Subject: [PythonCAD] DWG Format searching In-Reply-To: <20030902190744.GE31053@artsapartment.org> References: <20030902190744.GE31053@artsapartment.org> Message-ID: <200309021525.49139.ewilhelm@sbcglobal.net> > The following was supposedly scribed by > Art Haas > on Tuesday 02 September 2003 02:07 pm: > How >about releases prior to Autocad9? I've got an old AutoSketch around somewhere. I think it was using dwg already, but I'd have to find it and maybe dust off a 5.25 floppy drive to find out. If I get a chance, I'll give it a shot. --Eric From ahaas at airmail.net Thu Sep 4 15:54:41 2003 From: ahaas at airmail.net (Art Haas) Date: Thu Sep 4 15:54:48 2003 Subject: [PythonCAD] Test #3 Message-ID: <20030904195441.GA767@artsapartment.org> Hi. It looks like the 'python.org' mailserver is getting stuck - this is a test to see if this message goes through ... -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Thu Sep 4 16:40:18 2003 From: ahaas at airmail.net (Art Haas) Date: Thu Sep 4 16:40:25 2003 Subject: [PythonCAD] Subversion upgrade, public repo access, and R15 DWG reader Message-ID: <20030904204018.GC767@artsapartment.org> Hi. I've updated my Subversion binary on my computer, and this update required a dump/reload of the repo. I haven't do a resync to the remote repository, but once I do I'll have to update the binary on the remote machine. This message is therefore a "heads up" to those of you using Subversion to access the repo that you'll probably need to upgrade to the latest release, which seems to be 0.28.2. Also, the site that hosts the PythonCAD web pages and public subversion repository is moving. The guy that hosts the site is switching to a newer, faster machine that has a better internet connection. After the new machine is set up I'm going to go help get the Apache and Subversion software installed, so access to the repo may be out for a short while. On another note, I've started working on a reader for R15 format drawings. This format is similar to the R13/R14 format, but there are naturally enough differences to make things hard. I expect it will take a day or two before I release this reader - it will be similar to the R13/R14 reader in its operation until most of the bugs are worked out. This reader is the last one that I have some documentation about the file format. The Autocad 2004 format specs haven't been released by the OpenDWG people, and judging by the comments on their site, the new format is very complex. I hope this mail goes through as mail through 'python.org' has been very unpredictable lately. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Thu Sep 4 16:42:55 2003 From: ahaas at airmail.net (Art Haas) Date: Thu Sep 4 16:43:10 2003 Subject: [PythonCAD] pydwg 0.33% err In-Reply-To: <1062455385.2585.50.camel@linstation> References: <1062455385.2585.50.camel@linstation> Message-ID: <20030904204255.GD767@artsapartment.org> On Mon, Sep 01, 2003 at 11:29:45PM +0100, Guy Edwards wrote: > Ok, I tested against 14756 files, 48 gave errors = ~0.33% error rate. > > There are 10 new drawings up on the website that I think you're probably > already aware of. These are 10 of the 48 that caused errors, std err and > std out is there with them as before. > > http://lx-viewer.sourceforge.net/dwg/dwg.php > Hi. My latest 'dwg.py' works on 9 of the 10 drawings, but the 'HEX_SLOT_NUT' file fails. I think that file may be corrupt due to the way the 'dwg.py' script fails and my other DWG reading program fails on it as well. Can this file be loaded into Autocad? Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From CSomerlot at Brwncald.com Thu Sep 4 14:57:51 2003 From: CSomerlot at Brwncald.com (Somerlot, Chris) Date: Thu Sep 4 16:58:26 2003 Subject: [PythonCAD] DXF reader Message-ID: <1287132A98EE9F44B25C1D5B838F82FC4E1BB9@bcmah01.bc.brwncald.com> I made a similar reader for the dxf format earlier this summer. Its basically a conversion of some VB code that autodesk releases with their DXF documentation. I had to stop development on it because one I could never get pythonCAD to read files in windows due to a zlib library imcompatibility and two a complete hardware meltdown. I got to the point where I could successfully read the dxf, but I never got as far as writing that out to a pythonCAD file. Its about 45 lines. If anyone would like to do something with the code I can send it to them. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythoncad/attachments/20030904/73c08603/attachment.htm From guy_j_edwards at HotPOP.com Thu Sep 4 22:38:18 2003 From: guy_j_edwards at HotPOP.com (Guy Edwards) Date: Thu Sep 4 17:38:27 2003 Subject: [PythonCAD] pydwg 0.33% err In-Reply-To: <20030904204255.GD767@artsapartment.org> References: <1062455385.2585.50.camel@linstation> <20030904204255.GD767@artsapartment.org> Message-ID: <1062711320.2584.88.camel@linstation> On Thu, 2003-09-04 at 21:42, Art Haas wrote: [snip] > > http://lx-viewer.sourceforge.net/dwg/dwg.php > > Hi. > > My latest 'dwg.py' works on 9 of the 10 drawings, but the 'HEX_SLOT_NUT' > file fails. I think that file may be corrupt due to the way the 'dwg.py' > script fails and my other DWG reading program fails on it as well. Can > this file be loaded into Autocad? Interesting. - goes away - downloads individual file by hand - tests with dwg.py Yes, it works fine now, that test file was corrupt, :-( apologies. Can you email me your latest? I suspect you'll have 100% success now. What do you want tested next? R13? Will the same file do it? Cheers Guy > Art -- Guy Edwards From ahaas at airmail.net Thu Sep 4 18:31:17 2003 From: ahaas at airmail.net (Art Haas) Date: Thu Sep 4 18:31:52 2003 Subject: [PythonCAD] R15 reader ready for testing Message-ID: <20030904223117.GA1772@artsapartment.org> Hi. I've finished enough of this reader that I'd like to get people to test it. It works just like the earlier readers in that all it does is print stuff out. I have 2 R15 files and it reads them both without erroring out, so that is the extent of the testing. $ python dwg15.py /path/to/the/r15/drawing.dwg [ ... lots of output ... ] $ Let me know if you can try this out. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Wed Sep 3 09:08:42 2003 From: ahaas at airmail.net (Art Haas) Date: Thu Sep 4 22:19:43 2003 Subject: [PythonCAD] New test drawings up In-Reply-To: <1062376020.2623.36.camel@linstation> References: <20030831174431.GB609@artsapartment.org> <1062376020.2623.36.camel@linstation> Message-ID: <20030903130842.GB12483@artsapartment.org> On Mon, Sep 01, 2003 at 01:27:00AM +0100, Guy Edwards wrote: > 10 new DWGs are up, they cause errors with your new script. > http://lx-viewer.sourceforge.net/dwg/dwg.php > > Big improvement though. > > Error rate previously was 100/940 = 10.6% error @ Sat 30th Aug. > Error rate is now 36/2218 = 1.62% error @ Sun 31st Aug > > Please can you put a license header comment on your file? > Hi. My latest version of dwg.py works with 9 of those drawings, but the '0D5625-T_HEX_SLOT_NUT.dwg' file fails. I think that drawing may be corrupted as it fails (wildly!) in by my script and another DWG reading program I downloaded. Can that file be loaded into Autocad? Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Wed Sep 3 16:18:40 2003 From: ahaas at airmail.net (Art Haas) Date: Fri Sep 5 00:22:04 2003 Subject: [PythonCAD] Subversion upgrade Message-ID: <20030903201840.GA15717@artsapartment.org> Hi. I've updated my Subversion binary on my computer, and this update required a dump/reload of the repo. I haven't do a resync to the remote repository, but once I do I'll have to update the binary on the remote machine. This message is therefore a "heads up" to those of you using Subversion to access the repo that you'll probably need to upgrade to the latest release, which seems to be 0.28.2. On another note, I've started working on a reader for R15 format drawings. This format is similar to the R13/R14 format, but there are naturally enough differences to make things hard. I expect it will take a day or two before I release this reader - it will be similar to the R13/R14 reader in its operation until most of the bugs are worked out. This reader is the last one that I have some documentation about the file format. The Autocad 2004 format specs haven't been released by the OpenDWG people, and judging by the comments on their site, the new format is very complex. I hope this mail goes through as mail through 'python.org' has been very unpredictable lately ... Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Fri Sep 5 16:48:54 2003 From: ahaas at airmail.net (Art Haas) Date: Fri Sep 5 16:49:53 2003 Subject: [PythonCAD] DXF reader In-Reply-To: <1287132A98EE9F44B25C1D5B838F82FC4E1BB9@bcmah01.bc.brwncald.com> References: <1287132A98EE9F44B25C1D5B838F82FC4E1BB9@bcmah01.bc.brwncald.com> Message-ID: <20030905204854.GB11462@artsapartment.org> On Thu, Sep 04, 2003 at 01:57:51PM -0700, Somerlot, Chris wrote: > I made a similar reader for the dxf format earlier this summer. Its > basically a conversion of some VB code that autodesk releases with their DXF > documentation. I had to stop development on it because one I could never get > pythonCAD to read files in windows due to a zlib library imcompatibility and > two a complete hardware meltdown. I got to the point where I could > successfully read the dxf, but I never got as far as writing that out to a > pythonCAD file. Its about 45 lines. > > If anyone would like to do something with the code I can send it to them. > Hi. I'd like to see the code. I'm thinking of starting on a DXF translator next. I'd like to see what you wrote ... Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Sat Sep 6 09:57:10 2003 From: ahaas at airmail.net (Art Haas) Date: Sat Sep 6 09:57:24 2003 Subject: [PythonCAD] No testers for R15 reader yet Message-ID: <20030906135710.GA18899@artsapartment.org> Hi. I'm a bit surprised no one has mailed me for the R15 reader code yet. Is this version of the file format considered uncommon? I thought it was the version for Autocad 2000 and Autocad 2002, and those version have been available for quite some time. Are these versions less popular than the previous releases using the R13/R14 format? Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From guy_j_edwards at HotPOP.com Sat Sep 6 15:10:32 2003 From: guy_j_edwards at HotPOP.com (Guy Edwards) Date: Sat Sep 6 10:10:34 2003 Subject: [PythonCAD] No testers for R15 reader yet In-Reply-To: <20030906135710.GA18899@artsapartment.org> References: <20030906135710.GA18899@artsapartment.org> Message-ID: <1062857407.2767.72.camel@linstation> On Sat, 2003-09-06 at 14:57, Art Haas wrote: > I'm a bit surprised no one has mailed me for the R15 reader code yet. Sorry, had other things to do......... Send it to me and I'll test it. > this version of the file format considered uncommon? I thought it was > the version for Autocad 2000 and Autocad 2002, and those version have > been available for quite some time. Are these versions less popular than > the previous releases using the R13/R14 format? No, they should be quite common. The CAD places I was at kept pretty up to date. Autodesk used a discounted upgrade type approach. At my old company we would get sent letters saying when the deadline for upgrading to the new version was, otherwise we'd have to pay full price. You could save money if you were happy to drag your heals for a few versions but if you did that there was the risk that clients would send / ask for drawings in the newer format or maybe use a feature not present in older versions (e.g. redline markup on drawings). Guy -- Guy Edwards From pfrostie at yahoo.com Sat Sep 6 11:16:34 2003 From: pfrostie at yahoo.com (phrostie) Date: Sat Sep 6 10:15:32 2003 Subject: [PythonCAD] No testers for R15 reader yet In-Reply-To: <1062857407.2767.72.camel@linstation> References: <20030906135710.GA18899@artsapartment.org> <1062857407.2767.72.camel@linstation> Message-ID: <1062854020_63857@smtp4.ispsnet.net> i don't have autocad 15. 12 was my last, but still have friends in that world. how complex of drawings to you need? specific features? i can always ask. :-) On Saturday 06 September 2003 10:10, Guy Edwards wrote: > On Sat, 2003-09-06 at 14:57, Art Haas wrote: > > I'm a bit surprised no one has mailed me for the R15 reader code yet. > > Sorry, had other things to do......... > > Send it to me and I'll test it. > > > this version of the file format considered uncommon? I thought it was > > the version for Autocad 2000 and Autocad 2002, and those version have > > been available for quite some time. Are these versions less popular than > > the previous releases using the R13/R14 format? > > No, they should be quite common. The CAD places I was at kept pretty up > to date. > > Autodesk used a discounted upgrade type approach. At my old company we > would get sent letters saying when the deadline for upgrading to the new > version was, otherwise we'd have to pay full price. > > You could save money if you were happy to drag your heals for a few > versions but if you did that there was the risk that clients would send > / ask for drawings in the newer format or maybe use a feature not > present in older versions (e.g. redline markup on drawings). > > Guy -- Oh i've slipped the surly bonds of DOS and danced the skies on Linux silvered wings. http://pfrostie.freeservers.com/cad-tastrafy/ http://www.freelists.org/webpage/cad-linux From ahaas at airmail.net Sat Sep 6 10:26:33 2003 From: ahaas at airmail.net (Art Haas) Date: Sat Sep 6 10:26:42 2003 Subject: [PythonCAD] No testers for R15 reader yet In-Reply-To: <1062854020_63857@smtp4.ispsnet.net> References: <20030906135710.GA18899@artsapartment.org> <1062857407.2767.72.camel@linstation> <1062854020_63857@smtp4.ispsnet.net> Message-ID: <20030906142633.GC18899@artsapartment.org> On Sat, Sep 06, 2003 at 10:16:34AM -0400, phrostie wrote: > i don't have autocad 15. 12 was my last, but still have friends in that > world. how complex of drawings to you need? > specific features? > > i can always ask. > :-) Hi. I have two R15 files myself, and these drawings have lines, circles, arcs, text, and some other basic entities. I'd like to have a few more drawings with more entities _and_ have small file sizes - it is quicker to check a 50K drawing than a 500K drawing obviously. I'd like to have some drawings with various dimensions, ellipses, vertex, splines and other "exotic" entities. I would like a drawing with a tolerance entity in it as I think the OpenDWG spec may have an error in one of the fields in this object, or the spec uses an unfortunate variable name for the entity. The spec says there is a text string as one of the components of this object but uses a number reading function to get the data - I think that should be a text reading function. I don't think any of the drawings I have use a tolerance object. -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Sun Sep 7 13:43:53 2003 From: ahaas at airmail.net (Art Haas) Date: Sun Sep 7 13:43:59 2003 Subject: [PythonCAD] DXF Reader ready for testing Message-ID: <20030907174353.GA32395@artsapartment.org> Hi. I've cooked up a DXF reader that is similar in spirit to the DWG file readers of the last week. This script does nothing other than print out the contents of the DXF file. I've run it on the DXF files I have and it prints out their contents without generating an error, so it's a good candidate for testing. The DXF files I have are R12, R13, R14, and R15 formats. $ python /path/to/the/dxf/file/for/testing.dxf [ ... lots of output ... ] Please mail me if you can test this script. The script file is only 8.5 K in size - tiny compared to the DWG readers. Dealing with the text-based nature of these DXF files is much, much simpler than the binary DWG files. Yes, there are binary DXF files as well, but I'm going to stick with text DXF files for the time being. This file will get larger as future iterations do more than just print data out, obviously, but Python's ease at handling text and the design of the DXF format makes writing a DXF reader rather easy. Thanks in advance for testing this. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From jante_nord at yahoo.co.uk Mon Sep 8 13:55:39 2003 From: jante_nord at yahoo.co.uk (=?iso-8859-1?q?Johan?=) Date: Mon Sep 8 07:55:42 2003 Subject: [PythonCAD] DXF Reader ready for testing In-Reply-To: <20030907174353.GA32395@artsapartment.org> Message-ID: <20030908115539.61815.qmail@web42006.mail.yahoo.com> I am amazed by the speed of development of all theese .dwg and .dxf readers from Art. Is it hard to convert theese readers to drawing loaders for pythoncad ? Do you feel that .dwg and .dxf export would be much harder than import ? --- Art Haas wrote: > Hi. > > I've cooked up a DXF reader that is similar in > spirit to the DWG file > readers of the last week. This script does nothing > other than print out > the contents of the DXF file. I've run it on the DXF > files I have and it > prints out their contents without generating an > error, so it's a good > candidate for testing. The DXF files I have are R12, > R13, R14, and R15 > formats. > > $ python /path/to/the/dxf/file/for/testing.dxf > [ ... lots of output ... ] > > Please mail me if you can test this script. The > script file is only 8.5 > K in size - tiny compared to the DWG readers. > Dealing with the > text-based nature of these DXF files is much, much > simpler than the > binary DWG files. Yes, there are binary DXF files as > well, but I'm going > to stick with text DXF files for the time being. > This file will get > larger as future iterations do more than just print > data out, obviously, > but Python's ease at handling text and the design of > the DXF format > makes writing a DXF reader rather easy. > > Thanks in advance for testing this. > > Art > -- > Man once surrendering his reason, has no remaining > guard against absurdities > the most monstrous, and like a ship without rudder, > is the sport of every wind. > > -Thomas Jefferson to James Smith, 1822 > > _______________________________________________ > PythonCAD mailing list > PythonCAD@python.org > http://mail.python.org/mailman/listinfo/pythoncad ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk From ahaas at airmail.net Mon Sep 8 17:42:45 2003 From: ahaas at airmail.net (Art Haas) Date: Mon Sep 8 17:42:54 2003 Subject: [PythonCAD] Next step with DWG/DXF readers Message-ID: <20030908214245.GC17838@artsapartment.org> Hi. As it looks like the basic reading functionality is working well, it is time to look at actually doing something useful with the data in these files besided printing it out. I'm looking for some ideas regarding the ways that presenting the data in the files should be done. There is still more to learn about the file data, but I'd like to start working on at least a first version of an interface for getting the data. My initial idea is roughly to make a DWG/DXF class and then provide a few methods for retrieving the data. Here's some fictional Python code to show what I'm considering... $ python >>> import dwg >>> cadfile = dwg.Dwg("/path/to/the/dwg/file.dwg") >>> hdata = cadfile.getHeaderData() [ ... hdata is a dict with all the header variables ... ] >>> cdata = cadfile.getClassData() [ ... cdata is a dict or list with the class data ... ] >>> for entity in cadfile.entityCount(): ... ent = cadfile.getEntity() [ ... sequentially retrieve entities ... ] 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. 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. Art P.S. - On a completely unrelated topic, I'm looking for a little modem expertise. I have a dialup connection with a 56K modem, and things have been working just fine until roughly 4 days ago. The modem setup had not been touched in months and survived many Linux kernel and glibc upgrades. For about the last few days though, the modem connections speed has pluged - my 56K modem is now essentially a 14.4K modem. A call to my ISP informed me that they haven't been changing hardware and that things on their end are apparently working smoothly. My phone connection is my normal telephone line, and when I'm on the phone the connection seems decent enough. Things went blammo here after we had several days of rain. Once during the rain I was online then abruptly disconnected after what I'm guessing was a lightning strike somewhere. It seems like after that my connection speed has been cut down almost to one-third of its previous speed. My computer is on a surge protector and is fine, and the modem does still works, though something is certainly amiss. Any ideas from out there with regards to testing the modem and especially testing the phone line connection? Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ewilhelm at sbcglobal.net Mon Sep 8 19:17:11 2003 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Mon Sep 8 19:16:49 2003 Subject: [PythonCAD] Next step with DWG/DXF readers In-Reply-To: <20030908214245.GC17838@artsapartment.org> References: <20030908214245.GC17838@artsapartment.org> Message-ID: <200309081817.11032.ewilhelm@sbcglobal.net> > 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 From CSomerlot at Brwncald.com Tue Sep 9 07:48:18 2003 From: CSomerlot at Brwncald.com (Somerlot, Chris) Date: Tue Sep 9 09:49:04 2003 Subject: [PythonCAD] Next step with DWG/DXF readers Message-ID: <1287132A98EE9F44B25C1D5B838F82FC4E1BC7@bcmah01.bc.brwncald.com> 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@sbcglobal.net] > Sent: Monday, September 08, 2003 7:17 PM > To: pythoncad@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@python.org http://mail.python.org/mailman/listinfo/pythoncad > From ahaas at airmail.net Tue Sep 9 16:21:58 2003 From: ahaas at airmail.net (Art Haas) Date: Tue Sep 9 16:22:11 2003 Subject: [PythonCAD] [OT] Modem problems resolved Message-ID: <20030909202158.GB727@artsapartment.org> Hi. Thanks for the suggestions regarding the modem. A trip to a used computer parts store and $15 has solved it, and actually my connection speed has improved. Woo-hoo - 5.5K/s! My phone line is smoking! As the problem was in the old modem, I'm very surprised it worked at all after whatever caused it to get sick didn't just finish the job. Live and learn. I'll be away from receiving e-mail for a few days but I'll be working on my DWG interface stuff. Hopefully early next week the first version can go out for some comments. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Wed Sep 10 11:10:28 2003 From: ahaas at airmail.net (Art Haas) Date: Wed Sep 10 11:10:21 2003 Subject: [PythonCAD] Web site DNS changes Message-ID: <20030910151028.GE22097@artsapartment.org> Hi. In an earlier mail I related how the web site was being moved to another machine. Today I went and changed the DNS info regarding the site, so things may be a little flaky for a day or two if you try and visit. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From pfrostie at yahoo.com Sun Sep 14 11:54:33 2003 From: pfrostie at yahoo.com (phrostie) Date: Sun Sep 14 11:54:20 2003 Subject: [PythonCAD] formats and more Message-ID: <1063554827_1732@smtp5> there has been a lot of discussion about formats lately. in the process of updating my cad page i came across this. http://astronomy.swin.edu.au/~pbourke/geomformats/ forgive me for not remembering it sooner. i hope it can still be of help. oh, BTW, check out the rest of his stuff. http://astronomy.swin.edu.au/~pbourke/index.html enjoy -- Oh i've slipped the surly bonds of DOS and danced the skies on Linux silvered wings. http://pfrostie.freeservers.com/cad-tastrafy/ http://www.freelists.org/webpage/cad-linux From xjozo at antek.cz Tue Sep 16 09:00:25 2003 From: xjozo at antek.cz (Jozef Smizansky) Date: Tue Sep 16 09:00:09 2003 Subject: [PythonCAD] Download dwg.py Message-ID: <3F672589.25375.1F06969C@localhost> Hello, I am going to write a conversion program between DWG and DXF file formats. Is it possible to download from somewhere the dwg.py module(written by Art Haas i guess)? If so, what are the rules of including some parts of its code to my program? Or can I just look at it and take some inspiration? Thank you very much Jozef Smizansky From ahaas at airmail.net Fri Sep 19 16:00:03 2003 From: ahaas at airmail.net (Art Haas) Date: Fri Sep 19 16:01:09 2003 Subject: [PythonCAD] DWG reader update Message-ID: <20030919200003.GF19750@artsapartment.org> Hi. Last week I wrote that I hoped to have a first take of a real DWG reader available. Sadly that will not be the case as I wasn't as productive as hoped. Next week I'll be out for a day or two again, but maybe something will appear at the end of the week. I've had some feedback testing results with the R15 reader and have corrected various errors that were present in the code. There is still at least one problem reading the second header section of the file - some of the R15 files I have are read without difficulty, but others fail. Unforunately the OpenDWG spec is not helpful here as the files don't match the layout given in the spec - this was true for the R13/R14 reader as well. I've also added in a copyright notice with a GPL line indicating that these files are covered under the GPL. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ewilhelm at sbcglobal.net Wed Sep 24 15:53:14 2003 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Wed Sep 24 15:53:08 2003 Subject: [PythonCAD] Fwd: new Perl module CAD::Drawing Message-ID: <200309241453.14088.ewilhelm@sbcglobal.net> I'm posting this to several mailing lists to gather interest from developers (I'd love to have your help), Perl users (testing appreciated) and cad users which might want to become Perl users (more Perl users always welcome.) Reply or ignore as desired:) For those not familiar with Perl, realize that this is simply a module (library) which acts as a back-end for your Perl scripts: -----start code----- #!/usr/bin/perl use CAD::Drawing; # makes the functions available $drw = CAD::Drawing->new; # creates a "blessed" reference $drw->load("filename.dwg"); $drw->addline( [ [ $x0, $y0], [$x1, $y1] ], $layer, $color, $linetype); # selection methods allow you to grab things by layer, type, and property: @redcircles = $drw->getAddrByColor("some layer", "circles", "red"); # with manipulation methods for groups and single bits: $drw->GroupRotate( 35 . "d", $xc, $yc, {"addrlist" => [@redcircles]}); # this will rotate all of the red circles about $xc,$yc # at an angle of 35 degrees (radians by default (thus the "d")) $childpid = $drw->save("newfile.dwg", {"dofork" => 1}); # that lets it fork and child exit on completed save $drw->save("newfile.dxf"); # this won't fork (e.g. won't continue to ps until done saving the dxf.) $drw->save("thumbnail.png", {"width" => 200, "height" => 150} ); $drw->save("print_this.ps", {"show border" => 1, "noclone" => 1}); # the noclone option is just for memory savings # (you wouldn't normally do this unless it were the last save operation) -----end code----- There is a lot going on in this small chunk of code and this module is still fairly young, but is getting really powerful. Notice the single point of interface to any supported file format. The save functions have some automatic assumptions built into them (such as scale-to-fit for finite formats like images and postscript) but the design is such that there are options to over-ride these defaults (or at least some place where support for the options could be written into the code.) I've tried to keep the mnemonic load down by allowing english names or color numbers, and other such niceties (with preliminary support for translation between Image::Magick and acad color space (and eventually Image::Magick english color names.)) I'm hoping that it will be interface stable really soon (need to change some of the list-based function calls to hash-reference based to support a wider range of options (or something (maybe apply the options via a second-step to the same object (which would eliminate some of the drawn-out options hashes that could result.)))) Not to mention the nested parentheses and brackets and such. I'd appreciate comments from potential users and developers. See below for newsgroup post reference and places where help would be useful. I'll be working on getting this to a released state (hopefully fairly soon.) Items not mentioned in the newsgroup post that I would also like to pursue: 1. getting gpl-compatible dwg support via Art's dwg.py (as a wrapper or rewrite) 2. (briefly touched on) Dime library dxf/dwf support. Anybody worked with this before? 3. (briefly touched on) Inline.pm version of the OpenDWG library wrapper. 4. iges, step, and brep support via openCascade? 5. use of this module as the basis for a test-bed and proof-of-concept for linking associative and parametric data into single-entity-based databases (filesystem (e.g. xspace and Draft) or sql (soon underway with PostgreSQL and simple point&line exchange with Catia (via excel and vba?))) If you would like to help with the development, testing, or distribution, contact me off-list, on-list, via the newsgroup or whatever. I could really use some makefile help and some suggestions on how to get the whole thing packaged into a readily installable form. I'd also love to have help with supporting other formats and improving the dwg/dxf access (the entire toolset has evolved from an originally-non-object-oriented module built from a swig wrapper of the opendwg toolkit and could use some re-vamping.) I've managed to hack my way through the C code, but I'm not very experienced at that, so C/perlguts help would be really great. --Eric Posted today on comp.lang.perl.modules Message-ID: ---------- Forwarded Message: ---------- I've constructed a fairly extensive object oriented 2D geometry manipulation module which is currently capable of reading and writing dwg and dxf formats via the OpenDWG consortium's toolkit. It also currently supports saving to postscript or Image::Magick raster formats without any additional effort besides $drw->save("file.jpg", \%options); or $drw->save("file.ps", \%options); Manipulation methods include move, copy, rotate, scale (and soon mirror.) It is approaching interface stability, and has support for most 2D elements (point, line, polygon, circle, arc, text, and images.) Layers and colors are well supported, but linetypes are hard:( Some entities are only partially supported, some things are missing such as text formatting details and images (which are read-only.) Points and lines are usable as 3D elements, but not well supported by the manipulations (though I have been careful to not lose the z-coordinate when it is present.) The entire toolset consists of several files, which are all currently declared as "package Drawing", with the exception of the DWG wrapper (package DWG.) I plan to re-arrange all of the package names to CAD::Drawing in a tree such as this: CAD |-- Drawing | |-- Calculate.pm | |-- Defined.pm | |-- Dime.pm | |-- Finite.pm | |-- Manipulate.pm | `-- OpenDWG.pm `-- Drawing.pm where: Defined.pm contains exports, but is intended only for back-end use Dime.pm does not exist yet (but would give GNU compatible access to dxf files) OpenDWG.pm would have to be an optional xs module due to the consortium's licensing (free to use, not to distribute) files under Drawing/ would have "package Drawing" declarations From draw at docndraft.com Thu Sep 25 16:23:02 2003 From: draw at docndraft.com (Dave Coventry) Date: Thu Sep 25 17:37:13 2003 Subject: [PythonCAD] TextBlock bug Message-ID: <1064521380.558.5.camel@Laptop> Hi Art, I've tried to get going in Pythoncad, but I'm getting the error mentioned by someone in the Pythoncad archives, namely the MRO error in the TextBlock class. Are you on the verge of fixing this or do I need to downgrade back to Python 2.2? Many thanks, Dave Coventry From ewilhelm at sbcglobal.net Thu Sep 25 23:20:08 2003 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Thu Sep 25 23:19:59 2003 Subject: [PythonCAD] dxf and dwg text escapes and autocad Message-ID: <200309252220.08584.ewilhelm@sbcglobal.net> working on calculating text lengths (for placement, dimensions and other fun stuff.) Having not built my own gui (and being stuck in a production environment of windows machines and autocad draftsmen), I've got to make it compatible with acad's methods of displaying the text. The % character is quite an interesting escape beast. If it stands alone, it is taken as literal, but two in a row create an escape (which can then be followed by a "%" to create a "%" ?!) >From the looks of it: %% -> "" (null) %%% -> "%" %%37 -> "%" %%037 -> "%" %%a -> "a" %%3 -> "\003" (ascii 3) Who cooked this up in what dark corner of dos? An even worse bit is that autocad will save the file as containing the string %%037 (or whatever) rather than saving the actual ascii (unlike shell or perl programming where entering an escaped character causes the result to be saved, the result in autocad only happens onscreen (and on paper.)) My current take is to convert all read files to real ascii and all saved files to acad's silliness. It looks like the incoming could be handled via s/%%(\d+)/pack("C", $1)/e, but this will of course skip the other "valid" representations (giving a bad string to the program and output, as well as throwing-off the length calculations.) I can see writing a more careful and robust algorithm, but I'm afraid it will get caught in a tight loop and take up too much time checking every possibility. That is just on input. Now apparently output has to be handled character-by-character. I'm now wrestling with how to design the length calculation algorithm and whether to accommodate autocad's escape funkiness or just write it off as primitive and refusing to work so hard to deal with it. Any suggestions or experiences would be greatly appreciated. Thanks, Eric -- "Everything goes wrong all at once." --Quantized Revision of Murphy's Law From ewilhelm at sbcglobal.net Thu Sep 25 23:37:03 2003 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Thu Sep 25 23:36:52 2003 Subject: [PythonCAD] dxf and dwg text escapes and autocad In-Reply-To: <200309252220.08584.ewilhelm@sbcglobal.net> References: <200309252220.08584.ewilhelm@sbcglobal.net> Message-ID: <200309252237.03258.ewilhelm@sbcglobal.net> > The following was supposedly scribed by > Eric Wilhelm > on Thursday 25 September 2003 10:20 pm: >From the looks of it: > >%% -> "" (null) >%%% -> "%" >%%37 -> "%" >%%037 -> "%" >%%a -> "a" >%%3 -> "\003" (ascii 3) > >Who cooked this up in what dark corner of dos? It gets thicker yet: \U+00B1 and friends will make unicode symbols (and yes they are stored as "\U+00B1" in the file!) and even worse: while %%a gives an "a", %%d gives "?" Why put so much into parsing when it could have just been an interface policy? ? --Eric From ahaas at airmail.net Fri Sep 26 08:29:09 2003 From: ahaas at airmail.net (Art Haas) Date: Fri Sep 26 08:29:42 2003 Subject: [PythonCAD] TextBlock bug In-Reply-To: <1064521380.558.5.camel@Laptop> References: <1064521380.558.5.camel@Laptop> Message-ID: <20030926122909.GA25232@artsapartment.org> On Thu, Sep 25, 2003 at 10:23:02PM +0200, Dave Coventry wrote: > Hi Art, > > I've tried to get going in Pythoncad, but I'm getting the error > mentioned by someone in the Pythoncad archives, namely the MRO error in > the TextBlock class. > Hi. I'm mailing this patch to the list so it will be archived. I replied directly in an earlier mail. Also I'll be upgrading to Python 2.3.1 shortly from my current CVS built Python 2.2.3+ release. For the time being there are no plans to require Python 2.3 as the minimum Python release for running PythonCAD. Index: Generic/text.py =================================================================== --- Generic/text.py (revision 621) +++ Generic/text.py (revision 635) @@ -526,7 +526,7 @@ # objects in an image. # -class TextBlock(object, TextFormat): +class TextBlock(TextFormat): """A class for storing text in an image The TextBlock class is derived from the TextFormat class, so it -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822