From ahaas at airmail.net Fri Jul 2 10:49:05 2004 From: ahaas at airmail.net (Art Haas) Date: Fri Jul 2 10:49:11 2004 Subject: [PythonCAD] New stuff in repo Message-ID: <20040702144905.GB2573@artsapartment.org> Hi. I've sent a number of changes to the public repository this morning. The changes are designed to expose any stray references of the various entities in a drawing, as well as new methods to ensure that the various objects are reclaimable by the garbage collector. With this code in place I've found various memory reference leaks, and having found these leaks fixed them. There are also various fixes at the repo. What I want to work on this month is printing. My approach now is to generate postscript code, so I've been reading up on that language. I'm not planning to try and add other printing languages at the moment, as getting some preliminary printing functionality in PythonCAD is the immediate goal. 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 Fri Jul 2 14:17:05 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Fri Jul 2 14:15:32 2004 Subject: [PythonCAD] printing In-Reply-To: <20040702144905.GB2573@artsapartment.org> References: <20040702144905.GB2573@artsapartment.org> Message-ID: <200407021317.05947.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Art Haas # on Friday 02 July 2004 09:49 am: >What I want to work on this month is printing. My approach now is >to generate postscript code, so I've been reading up on that language. >I'm not planning to try and add other printing languages at the >moment, as getting some preliminary printing functionality in PythonCAD >is the immediate goal. My $0.02 toward this: I think generating postscript code is a great way to go. If you want to later interface with printers, you can just save the print.ps to a tempfile and use a system call to print it. Definitely don't bother with pcl. hpgl can be done via conversion as well. Any plans to support multiple layouts? Multiple views in one layout? How about this idea. If any pythoncad file could be converted to a postscript (preferably via command line (e.g. free batch plotting:)), then your layouts could just be drawings with instantiations of the model view (such as xrefs or blocks.) I'm not particularly fond of autocad's multi-layout-tabs and its habit of storing all of your layouts in the same file with your model. Since pythoncad is 2D, it is essentially pure paperspace. So, rather than constructing a whole new interface for paperspace, just add some paper-centric functionality to pythoncad and have your drafting space be your paper space. Then, you save layouts just like other files. Give them a second extension if you like, just to indicate that they are ready for batch plotting. --Eric From ahaas at airmail.net Fri Jul 2 16:21:43 2004 From: ahaas at airmail.net (Art Haas) Date: Fri Jul 2 16:21:54 2004 Subject: [PythonCAD] printing In-Reply-To: <200407021317.05947.ewilhelm@sbcglobal.net> References: <20040702144905.GB2573@artsapartment.org> <200407021317.05947.ewilhelm@sbcglobal.net> Message-ID: <20040702202143.GE2573@artsapartment.org> On Fri, Jul 02, 2004 at 01:17:05PM -0500, Eric Wilhelm wrote: > # The following was supposedly scribed by > # Art Haas > # on Friday 02 July 2004 09:49 am: > > >What I want to work on this month is printing. My approach now is > >to generate postscript code, so I've been reading up on that language. > >I'm not planning to try and add other printing languages at the > >moment, as getting some preliminary printing functionality in PythonCAD > >is the immediate goal. > > My $0.02 toward this: > > I think generating postscript code is a great way to go. If you want > to later interface with printers, you can just save the print.ps to a > tempfile and use a system call to print it. Definitely don't bother > with pcl. hpgl can be done via conversion as well. > > Any plans to support multiple layouts? Multiple views in one layout? I'm not sure what you mean here with 'multiple layouts'. Does this mean that the printed file contains various views of some objects? > > How about this idea. If any pythoncad file could be converted to a > postscript (preferably via command line (e.g. free batch plotting:)), > then your layouts could just be drawings with instantiations of the > model view (such as xrefs or blocks.) As the files are saved in XML, there is probably some way to do this with XSLT. I'll revert to textbook mode here and say that the code to do this is left as an example for the reader to create. Having a command line batch plotting utility would be nice. I'd like to have command line tools for converting to/from other file formats as well. > I'm not particularly fond of autocad's multi-layout-tabs and its habit of > storing all of your layouts in the same file with your model. Since > pythoncad is 2D, it is essentially pure paperspace. So, rather than > constructing a whole new interface for paperspace, just add some > paper-centric functionality to pythoncad and have your drafting space be your > paper space. Then, you save layouts just like other files. Give them a > second extension if you like, just to indicate that they are ready for batch > plotting. My lack of AutoCAD experience is exposed as I don't know just what that program is doing. The peper-space stuff sounds familiar due to writing the DXF/DWG reading code. 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 Fri Jul 2 16:51:02 2004 From: CSomerlot at Brwncald.com (Somerlot, Chris) Date: Fri Jul 2 16:52:36 2004 Subject: FW: [PythonCAD] printing Message-ID: > > > > Any plans to support multiple layouts? Multiple views in > one layout? > > I'm not sure what you mean here with 'multiple layouts'. Does > this mean that the printed file contains various views of > some objects? > When I do multiple layouts, it is one view of the drawing with a layout for 11x17, D-size sheet, E-size, etc. In Autocad (2004 and up) each layout is a separate tab. > > > > How about this idea. If any pythoncad file could be converted to a > > postscript (preferably via command line (e.g. free batch > plotting:)), > > then your layouts could just be drawings with instantiations of the > > model view (such as xrefs or blocks.) > > As the files are saved in XML, there is probably some way to > do this with XSLT. I'll revert to textbook mode here and say > that the code to do this is left as an example for the reader > to create. Thinking about this, embedding one pythoncad drawing in another via a link would be similar to inserting a raster image, so why not just have one embedding function and the user gets to pick from a jpeg aerial photo or another pythoncad drawing? You would only need the ability to scale and clip to a window, and it should be embedded on its own layer to be able to turn it on and off. And then all of a sudden pythoncad is a GIS too :) > > > I'm not particularly fond of autocad's multi-layout-tabs > and its habit > > of > > storing all of your layouts in the same file with your > model. I totally agree. What really sucks is when the symbols you drew for a E-size sheet come out tiny and illegible on an 8.5x11. From CSomerlot at Brwncald.com Fri Jul 2 16:56:32 2004 From: CSomerlot at Brwncald.com (Somerlot, Chris) Date: Fri Jul 2 16:58:06 2004 Subject: FW: [PythonCAD] New stuff in repo Message-ID: Are you including SVG as a printing language? I was only considering it as a means of publishing drawings to the web. I'm starting to think that exporting as flash, like openoffice does, would be more supported though. Any thoughts on this? > > What I want to work on this month is printing. My approach > now is to generate postscript code, so I've been reading up > on that language. I'm not planning to try and add other > printing languages at the moment, as getting some preliminary > printing functionality in PythonCAD is the immediate goal. > > 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 > From inigoserna at terra.es Fri Jul 2 17:07:14 2004 From: inigoserna at terra.es (=?iso-8859-1?Q?I=F1igo?= Serna) Date: Fri Jul 2 17:08:17 2004 Subject: FW: [PythonCAD] New stuff in repo In-Reply-To: References: Message-ID: <20040702210714.GA27238@inigo.katxi.org> Do you know Cairo? It has python bindings too, written by the very James Henstridge It's the future, but probably too young by now. http://cairographics.org/ http://cairographics.org/GtkCairo http://cairographics.org/pycairo I?igo On Fri, Jul 02, 2004 at 04:56:32PM -0400, Somerlot, Chris wrote: > Are you including SVG as a printing language? I was only considering it > as a means of publishing drawings to the web. I'm starting to think that > exporting as flash, like openoffice does, would be more supported > though. Any thoughts on this? > > > > > What I want to work on this month is printing. My approach > > now is to generate postscript code, so I've been reading up > > on that language. I'm not planning to try and add other > > printing languages at the moment, as getting some preliminary > > printing functionality in PythonCAD is the immediate goal. > > > > Art -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mail.python.org/pipermail/pythoncad/attachments/20040702/fefc869c/attachment.bin From ahaas at airmail.net Fri Jul 2 18:08:17 2004 From: ahaas at airmail.net (Art Haas) Date: Fri Jul 2 18:10:55 2004 Subject: FW: [PythonCAD] New stuff in repo In-Reply-To: References: Message-ID: <20040702220817.GF2573@artsapartment.org> On Fri, Jul 02, 2004 at 04:56:32PM -0400, Somerlot, Chris wrote: > Are you including SVG as a printing language? I was only considering it > as a means of publishing drawings to the web. I'm starting to think that > exporting as flash, like openoffice does, would be more supported > though. Any thoughts on this? I was thinking about SVG being an export format, closer to what you mention for web viewing. As for exporting to Flash, I'm not keen on that unless all the Flash code is freely available, and I don't think that is the case now. Is that not the case? -- 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 Jul 2 18:10:49 2004 From: ahaas at airmail.net (Art Haas) Date: Fri Jul 2 18:10:57 2004 Subject: FW: [PythonCAD] New stuff in repo In-Reply-To: <20040702210714.GA27238@inigo.katxi.org> References: <20040702210714.GA27238@inigo.katxi.org> Message-ID: <20040702221049.GG2573@artsapartment.org> On Fri, Jul 02, 2004 at 11:07:14PM +0200, I?igo Serna wrote: > Do you know Cairo? It has python bindings too, written by the very > James Henstridge > > It's the future, but probably too young by now. > > http://cairographics.org/ > http://cairographics.org/GtkCairo > http://cairographics.org/pycairo I've heard of this when reading about various GTK stuff, but haven't looked at it. There is still much to learn about PyGTK, and I'd like to improve that code before tackling the Cairo stuff. -- 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 Fri Jul 2 18:22:15 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Fri Jul 2 18:20:40 2004 Subject: FW: [PythonCAD] svg export and more In-Reply-To: References: Message-ID: <200407021722.15457.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Somerlot, Chris # on Friday 02 July 2004 03:56 pm: >Are you including SVG as a printing language? I was only considering it >as a means of publishing drawings to the web. I'm starting to think that >exporting as flash, like openoffice does, would be more supported >though. Any thoughts on this? If you haven't seen this, maybe take a look: http://ericwilhelm.homeip.net/uber-converter/ For discussion, see the recent archives from the cad-linux-dev mailing list. If you want to irc about it, get on #cadfs of irc.freenode.net There is not anything actually in existence yet, (that's why I need programmers to get interested in it.) Well, the CAD::Drawing perl module is in existence and the IO::* infrastructure more or less acts as a model for the hub-spoke file conversion concept. Given a pythoncad reader backend and an svg writer backend, you could get to svg very easily. The benefit of this scheme is that you write one pythoncad converter, one svg converter, one postscript converter, one dxf converter. Given those four spokes, you get the following combinations: dxf<->ps dxf<->svg dxf<->pycad pycad<->svg svg->ps pycad->ps Art: consider this last one as your "printing". --Eric -- "Cleanliness is next to impossible." --Unknown From ewilhelm at sbcglobal.net Tue Jul 6 22:54:08 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Tue Jul 6 22:52:25 2004 Subject: FW: [PythonCAD] svg export and more In-Reply-To: References: Message-ID: <200407061554.08357.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Somerlot, Chris # on Tuesday 06 July 2004 01:04 pm: >I looked at it and I buy into the idea. But it sounds like the central >hub data structure still needs to be worked out? If it is I would be >happy to work on the svg reader and writer backends, and maybe flash. First note that with the hub model, a node can be a hub as easily as it can be a node, so if we get it wrong the first time, we just move that hub into 'node' status and keep moving forward (e.g. that hub becomes deprecated, but doesn't render huge piles of code useless.) Yes, to make the central hub an on-disk data structure, there is some work left to be done. My current line of thought is that the central hub would be in a YAML format where each entity lives in its own file. As one possible example, we could have a database where everything is divided into a directory based on the type of object (rather than have an object-type property stored in every file.) $tree db db `-- objects |-- meshes | `-- spheres | `-- 19.yaml `-- planar |-- circles | `-- 1.yaml `-- lines `-- 2.yaml $cat db/objects/planar/lines/2.yaml --- #YAML:1.0 ID: 2 pts: - - 5.3326 - -7.09 - - 9.887 - 0.876 This idea is still rather rough. Also, as a first step, I'm planning to create a backend for my CAD::Drawing Perl module which implements saves in YAML (as shown above and maybe also as a single file.) If you can code in Perl, you may want to check-out the CAD::Drawing module, since it already implements an in-memory data structure. There are some warts on it (namely that ACI colors are used as the color value and some other dwg-specific issues.) However, these have been staring me in the face for some time, so I'd be happy to remove them if I can find the time and motivation. Given CAD::Drawing::IO::SVG and CAD::Drawing::IO::PythonCAD modules, we'd be already there (there is already a CAD::Drawing::IO::PostScript.) You can get them on CPAN (in installable tarball) or grab the bleeding-edge versions from my svn server: http://ericwilhelm.homeip.net/svn/CAD-Drawing/trunk/code/ If you can't or don't want to code in Perl, we'd better get started with that on-disk model so you have something to shoot for. There are YAML libraries available for Perl, Python, and I think C and C++, so I think it is a good format to shoot for. Again, note that the hub-is-a-node concept allows me to connect all of the CAD::Drawing modules to the on-disk format just by writing a CAD::Drawing::IO::SplitYAML module. Get in touch with me on-list, off-list, on cad-linux-dev or on #cadfs on irc.freenode.net. (Art would have to say if on-list is off-limits.) --Eric -- The opinions expressed in this e-mail were randomly generated by the computer and do not necessarily reflect the views of its owner. --Management From ahaas at airmail.net Fri Jul 9 16:05:11 2004 From: ahaas at airmail.net (Art Haas) Date: Fri Jul 9 16:05:17 2004 Subject: FW: [PythonCAD] svg export and more In-Reply-To: <200407061554.08357.ewilhelm@sbcglobal.net> References: <200407061554.08357.ewilhelm@sbcglobal.net> Message-ID: <20040709140511.GF21238@artsapartment.org> On Tue, Jul 06, 2004 at 03:54:08PM -0500, Eric Wilhelm wrote: > # The following was supposedly scribed by > # Somerlot, Chris > # on Tuesday 06 July 2004 01:04 pm: > > Get in touch with me on-list, off-list, on cad-linux-dev or on #cadfs on > irc.freenode.net. (Art would have to say if on-list is off-limits.) Feel free to discuss this on the list. I tried replying to the list about this earlier, but my reply didn't show up :-/ -- 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 gmail.com Fri Jul 9 18:44:38 2004 From: csomerlot at gmail.com (Chris Somerlot) Date: Fri Jul 9 18:44:41 2004 Subject: FW: [PythonCAD] svg export and more In-Reply-To: <200407061554.08357.ewilhelm@sbcglobal.net> References: <200407061554.08357.ewilhelm@sbcglobal.net> Message-ID: <9a8f0670407090944149065b1@mail.gmail.com> > If you can't or don't want to code in Perl, we'd better get started with that > on-disk model so you have something to shoot for. I'm afriad I can't > There are YAML libraries > available for Perl, Python, and I think C and C++, so I think it is a good > format to shoot for. Would this be the Syck library? Art, in terms of flash being open, openswf.org has published the format, and I'll work from that. From ewilhelm at sbcglobal.net Fri Jul 9 19:21:34 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Fri Jul 9 19:19:48 2004 Subject: FW: [PythonCAD] svg export and more In-Reply-To: <9a8f0670407090944149065b1@mail.gmail.com> References: <200407061554.08357.ewilhelm@sbcglobal.net> <9a8f0670407090944149065b1@mail.gmail.com> Message-ID: <200407091221.34695.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Chris Somerlot # on Friday 09 July 2004 11:44 am: >I'm afriad I can't > >> There are YAML libraries >> available for Perl, Python, and I think C and C++, so I think it is a good >> format to shoot for. ? > >Would this be the Syck library? Yes, I believe that's correct. Are you working in C or C++? Okay, let's get started with an on-disk spec. Take a look at Syck and see what you can do with YAML. If that will work well enough, then the only spec that really needs to be worked out is the data structure of each entity (e.g. circle, point, line, polyline...) If you can get on the #cadfs channel of irc.freenode.net, that would be the best place to discuss it. Once we've got a spec started, I'll try to track it with a new backend to CAD::Drawing, which will allow dwg/dxf import/export and postscript export from the on-disk format. I'd also like to end-up with a pythoncad connector to this system, but I'm pretty busy. Any volunteers? --Eric -- "Chess is a foolish expedient for making idle people believe they are doing something very clever when they are only wasting their time." --George Bernard Shaw From ahaas at airmail.net Fri Jul 9 19:51:59 2004 From: ahaas at airmail.net (Art Haas) Date: Fri Jul 9 19:52:07 2004 Subject: FW: [PythonCAD] svg export and more In-Reply-To: <9a8f0670407090944149065b1@mail.gmail.com> References: <200407061554.08357.ewilhelm@sbcglobal.net> <9a8f0670407090944149065b1@mail.gmail.com> Message-ID: <20040709175159.GK21238@artsapartment.org> On Fri, Jul 09, 2004 at 12:44:38PM -0400, Chris Somerlot wrote: > > Art, in terms of flash being open, openswf.org has published the > format, and I'll work from that. > I was not aware that an open description of the Flash format existed. Learn something new every day ... -- 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 Sat Jul 10 07:05:05 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Sat Jul 10 07:03:19 2004 Subject: [PythonCAD] printing In-Reply-To: <20040702202143.GE2573@artsapartment.org> References: <20040702144905.GB2573@artsapartment.org> <200407021317.05947.ewilhelm@sbcglobal.net> <20040702202143.GE2573@artsapartment.org> Message-ID: <200407100005.05818.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Art Haas # on Friday 02 July 2004 03:21 pm: >> I'm not particularly fond of autocad's multi-layout-tabs and its habit of >> storing all of your layouts in the same file with your model. ?Since >> pythoncad is 2D, it is essentially pure paperspace. ?So, rather than >> constructing a whole new interface for paperspace, just add some >> paper-centric functionality to pythoncad and have your drafting space be >> your paper space. ?Then, you save layouts just like other files. ?Give >> them a second extension if you like, just to indicate that they are ready >> for batch plotting. > >My lack of AutoCAD experience is exposed as I don't know just what that >program is doing. The peper-space stuff sounds familiar due to writing >the DXF/DWG reading code. Well, AutoCAD uses a 'model space' and 'paper space' concept. That is, the model is a drawing at real-world dimensions and the layout is on a sheet of paper (with real paper-size dimensions.) The way it (and others including catia and pro-e (can anyone say about microstation?)) handles displaying the model in paper space is that you create 'viewports'. So, if you had a 3D model, you could create a layout with 4 viewports (and you can clip these viewports, rotate the view, set the scale for each one, etc,etc) If you only have a 2D drawing this can still be useful to show e.g. details or even just to re-arrange the drawing layout without changing the model-view content/positioning. Freezing layers can also be done on a per-viewport basis. My suggestion here is that rather than trying to replicate the paperspace functions and creating a viewport entity (which only exists in paperspace) that you simply make block or xref-like entities which behave like viewports. I think there is a lot of discontinuity (for the programmer and the user) with AutoCAD's model of paper-space. Particularly when you are dealing with a 2D-only cad application. With 3D modelers like Catia and Pro-E it is quite different (here, paperspace is a necessary thing and drafted representations of models are different than the models.) So, consider this: I draw three views of my project in pythoncad, and save this as project.xml.gz. In this file, I've got multiple layers defined (I'll creatively call them 1 and 2.) Now, I create a new pythoncad drawing (maybe starting from a template for 24x36 paper) and I instantiate project.xml.gz twice (positioning two of my three views with layer 1 active) and then add my title-block and etc. I'll save this as sheet1.xml.gz and go on to create another 24x36 layout with view 2 & 3 and layer 2 active. This, I'll save as sheet2.xml.gz. For all practical purposes, sheet1.xml.gz and sheet2.xml.gz are now equivalent to (layouts) printouts of my drawing (with everything as it should be, layers, scales, and etc.) Maybe I print them now, or maybe I go back into project.xml.gz and make some changes. Regardless, when I'm ready to print, I should not have to revisit my layouts (since I maybe created 5 or 6 of them to print on various sizes of paper.) Given this scheme, here's how we batch plot: (where pycad2ps just draws in postscript format exactly what pythoncad would display on-screen) for i in 1 2 ;do pycad2ps -c sheet$i.xml.gz |lp -P24x36plotter ;done Printing from inside of pythoncad should essentially perform the same operation, which means that print and export are equivalent except that 'print' means 'send a postscript export format to this printer'. --Eric -- "Texas is the place where there are the most cows and the least milk and the most rivers and the least water in them, and where you can look the farthest and see the least." --H. L. Mencken From pfrostie at yahoo.com Sat Jul 10 13:37:37 2004 From: pfrostie at yahoo.com (phrostie) Date: Sat Jul 10 14:21:26 2004 Subject: [PythonCAD] printing In-Reply-To: <200407100005.05818.ewilhelm@sbcglobal.net> References: <20040702144905.GB2573@artsapartment.org> <20040702202143.GE2573@artsapartment.org> <200407100005.05818.ewilhelm@sbcglobal.net> Message-ID: <200407100737.37822.pfrostie@yahoo.com> With later releases of Catia V4 and now with Catia V5 the older paperspace view ports have been droped for what was called AUX2 in V4. this has more seperation between the 3D and the 2D environment. the 3D model is rendered to create seperate 2D geometry that exists in a floating viewport that can be moved around in the drawing area. > Well, AutoCAD uses a 'model space' and 'paper space' concept. That is, > the model is a drawing at real-world dimensions and the layout is on a > sheet of paper (with real paper-size dimensions.) > > The way it (and others including catia and pro-e (can anyone say about > microstation?)) handles displaying the model in paper space is that you > create 'viewports'. So, if you had a 3D model, you could create a layout > with 4 viewports (and you can clip these viewports, rotate the view, set > the scale for each one, etc,etc) If you only have a 2D drawing this can > still be useful to show e.g. details or even just to re-arrange the drawing > layout without changing the model-view content/positioning. Freezing > layers can also be done on a per-viewport basis. > > My suggestion here is that rather than trying to replicate the paperspace > functions and creating a viewport entity (which only exists in paperspace) > that you simply make block or xref-like entities which behave like > viewports. > > I think there is a lot of discontinuity (for the programmer and the user) > with AutoCAD's model of paper-space. Particularly when you are dealing > with a 2D-only cad application. With 3D modelers like Catia and Pro-E it > is quite different (here, paperspace is a necessary thing and drafted > representations of models are different than the models.) > > So, consider this: I draw three views of my project in pythoncad, and save > this as project.xml.gz. In this file, I've got multiple layers defined > (I'll creatively call them 1 and 2.) Now, I create a new pythoncad > drawing (maybe starting from a template for 24x36 paper) and I instantiate > project.xml.gz twice (positioning two of my three views with layer 1 > active) and then add my title-block and etc. I'll save this as > sheet1.xml.gz and go on to create another 24x36 layout with view 2 & 3 and > layer 2 active. This, I'll save as sheet2.xml.gz. > > For all practical purposes, sheet1.xml.gz and sheet2.xml.gz are now > equivalent to (layouts) printouts of my drawing (with everything as it > should be, layers, scales, and etc.) Maybe I print them now, or maybe I go > back into project.xml.gz and make some changes. Regardless, when I'm ready > to print, I should not have to revisit my layouts (since I maybe created 5 > or 6 of them to print on various sizes of paper.) > > Given this scheme, here's how we batch plot: > > (where pycad2ps just draws in postscript format exactly what pythoncad > would display on-screen) > > for i in 1 2 ;do pycad2ps -c sheet$i.xml.gz |lp -P24x36plotter ;done > > Printing from inside of pythoncad should essentially perform the same > operation, which means that print and export are equivalent except that > 'print' means 'send a postscript export format to this printer'. > > --Eric -- 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 http://www.freelists.org/webpage/cad-linux-dev From ewilhelm at sbcglobal.net Mon Jul 12 03:29:07 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Mon Jul 12 03:27:17 2004 Subject: [PythonCAD] subversion.pythoncad.org Message-ID: <200407112029.07357.ewilhelm@sbcglobal.net> Maybe this is temporary? $svn co http://subversion.pythoncad.org:9000/svn/pythoncad/trunk pythoncad svn: PROPFIND request failed on '/svn/pythoncad/trunk' svn: PROPFIND of '/svn/pythoncad/trunk': could not connect to server (http://subversion.pythoncad.org:9000) --Eric From ahaas at airmail.net Mon Jul 12 16:47:36 2004 From: ahaas at airmail.net (Art Haas) Date: Mon Jul 12 16:47:44 2004 Subject: [PythonCAD] subversion.pythoncad.org In-Reply-To: <200407112029.07357.ewilhelm@sbcglobal.net> References: <200407112029.07357.ewilhelm@sbcglobal.net> Message-ID: <20040712144736.GQ21238@artsapartment.org> On Sun, Jul 11, 2004 at 08:29:07PM -0500, Eric Wilhelm wrote: > Maybe this is temporary? > > $svn co http://subversion.pythoncad.org:9000/svn/pythoncad/trunk pythoncad > svn: PROPFIND request failed on '/svn/pythoncad/trunk' > svn: PROPFIND of '/svn/pythoncad/trunk': could not connect to server > (http://subversion.pythoncad.org:9000) Apache was stopped yesterday on that machine. I've restarted it now and can connect. There isn't anything new in the repo lately, btw. My printing code is still _way_ to useless. I have written some beginning PostScript output code though, and can print segments, circles, and arcs, leaders, and polylines. These are all simple to print using PostScript's lineto, moveto, and arc commands. Thanks for the heads-up message. 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 Jul 12 17:42:01 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Mon Jul 12 17:40:18 2004 Subject: [PythonCAD] postscript In-Reply-To: <20040712144736.GQ21238@artsapartment.org> References: <200407112029.07357.ewilhelm@sbcglobal.net> <20040712144736.GQ21238@artsapartment.org> Message-ID: <200407121042.01338.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Art Haas # on Monday 12 July 2004 09:47 am: >I have written some beginning >PostScript output code though, and can print segments, circles, and >arcs, leaders, and polylines. These are all simple to print using >PostScript's lineto, moveto, and arc commands. Isn't there a python module for this? I've been using Postscript::Simple in my perl modules. Also, it seems that I haven't sold you on the converter/hub/export idea yet. (otherwise, you wouldn't be writing postscript code.) Chris and I plan to discuss this tonight at 20:00 EDT on #cadfs of irc.freenode.net. Maybe you can join us? (It could save you lots of coding.) --Eric -- "These crispix get soggy so quickly." -- Tina Connolly From ewilhelm at sbcglobal.net Mon Jul 12 17:52:31 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Mon Jul 12 17:50:37 2004 Subject: [PythonCAD] meeting time In-Reply-To: <200407121042.01338.ewilhelm@sbcglobal.net> References: <200407112029.07357.ewilhelm@sbcglobal.net> <20040712144736.GQ21238@artsapartment.org> <200407121042.01338.ewilhelm@sbcglobal.net> Message-ID: <200407121052.31753.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Eric Wilhelm # on Monday 12 July 2004 10:42 am: >Chris and I plan to discuss this tonight at 20:00 EDT on #cadfs of >irc.freenode.net. Sorry. 20:00 CDT, 21:00 EDT --Eric -- "Unthinking respect for authority is the greatest enemy of truth." --Albert Einstein From ahaas at airmail.net Mon Jul 12 18:10:33 2004 From: ahaas at airmail.net (Art Haas) Date: Mon Jul 12 18:10:44 2004 Subject: [PythonCAD] postscript In-Reply-To: <200407121042.01338.ewilhelm@sbcglobal.net> References: <200407112029.07357.ewilhelm@sbcglobal.net> <20040712144736.GQ21238@artsapartment.org> <200407121042.01338.ewilhelm@sbcglobal.net> Message-ID: <20040712161033.GT21238@artsapartment.org> On Mon, Jul 12, 2004 at 10:42:01AM -0500, Eric Wilhelm wrote: > # The following was supposedly scribed by > # Art Haas > # on Monday 12 July 2004 09:47 am: > > >I have written some beginning > >PostScript output code though, and can print segments, circles, and > >arcs, leaders, and polylines. These are all simple to print using > >PostScript's lineto, moveto, and arc commands. > > Isn't there a python module for this? I've been using Postscript::Simple in > my perl modules. I am unware of any Python modules for writing PostScript. > Also, it seems that I haven't sold you on the converter/hub/export idea yet. > (otherwise, you wouldn't be writing postscript code.) I'd like PythonCAD to create a printable document without relying on any modules or packages outside of the PythonCAD code. Having said that, I suspect that Ghostscript will come into play for people trying to print on non-Postscript printers. Additionally, I want to learn more about PostScript, so writing code in PythonCAD that generates PostScript output looks to be a good learning experience. -- 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 Tue Jul 20 06:21:17 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Tue Jul 20 06:19:56 2004 Subject: [PythonCAD] yaml-based uber-converter db format Message-ID: <200407192321.17804.ewilhelm@sbcglobal.net> Hi Everybody! We've started laying out a YAML-based format to represent a drawing data-structure on-disk as a 'flat' tree. Chris Somerlot is working (in python) on pythoncad and svg connectors. As these begin to take shape, the specifics of what goes in each YAML file will become more clear. For now, look at http://ericwilhelm.homeip.net/uber-converter/db/flat/ (3.yaml and 4.yaml are closer to the final style right now than the others.) I'll be adding a backend to the CAD::Drawing Perl modules to connect to this new format. That will act as a mini-hub between the YAML hub and the rest of the formats supported by CAD::Drawing (postscript, various images, dxf, dwg, and postgresql.) Eventually, I'd like to get the dxf and dwg connectors to be GPL'd. I look forward to using Art's code for this, but that's still not 100% on the reads, and I don't believe writing is started. On the dxf front, there's also the coin3d dime library (lacking text-entity support) and the qcad-lib (lacking (I believe) any 3D support.) For those that haven't been watching OpenDWG, they are now OpenDesign, since they have a dgn-lib. I haven't looked at this, but there's not a lot of need for Microstation compatibility on my horizon. (Are they publishing a dgn spec?) If anyone wants to volunteer to bring STEP into the mix, feel free (ducking.) That's just a brain dump. Questions or comments welcome: choose a list or get on #cadfs on irc.freenode.net. --Eric -- Cult: A small, unpopular religion. Religion: A large, popular cult. -- Unknown From dspeckhard at bcj.com Tue Jul 20 19:24:04 2004 From: dspeckhard at bcj.com (Doug Speckhard) Date: Tue Jul 20 19:24:14 2004 Subject: [PythonCAD] yaml-based uber-converter db format In-Reply-To: <200407192321.17804.ewilhelm@sbcglobal.net> References: <200407192321.17804.ewilhelm@sbcglobal.net> Message-ID: <40FD5534.1050006@bcj.com> Eric Wilhelm wrote: > For those that haven't been watching OpenDWG, they are now OpenDesign, since > they have a dgn-lib. I haven't looked at this, but there's not a lot of need > for Microstation compatibility on my horizon. (Are they publishing a dgn > spec?) Yes, Bentley has posted a spec for the OpenDGN standard, but you have to sign a license/NDA agreement, which is somewhat more restrictive than the OpenDesign.org membership that you have to sign to get the libraries themselves. Also note that unlike the other OpenDesign libraries, the OpenDGN libraries are available for Windows only. The agreement can be downloaded here: http://www.bentley.com/bentleywebsite/tools/opendgn/download.aspx doug From csomerlot at gmail.com Mon Jul 26 14:42:55 2004 From: csomerlot at gmail.com (Chris Somerlot) Date: Mon Jul 26 14:42:59 2004 Subject: [PythonCAD] pythoncad drawing Message-ID: <9a8f06704072605427757ef5a@mail.gmail.com> For debugging file conversion code, I'm wondering if anyone has a pythoncad drawing with every type of entitiy in it they could send to me? From ewilhelm at sbcglobal.net Mon Jul 26 19:50:42 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Mon Jul 26 19:48:53 2004 Subject: [PythonCAD] pythoncad drawing In-Reply-To: <9a8f06704072605427757ef5a@mail.gmail.com> References: <9a8f06704072605427757ef5a@mail.gmail.com> Message-ID: <200407261250.42919.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Chris Somerlot # on Monday 26 July 2004 07:42 am: >For debugging file conversion code, I'm wondering if anyone has a >pythoncad drawing with every type of entitiy in it they could send to >me? I know these aren't pythoncad, but this is what I've been using as a source for my yaml examples: http://ericwilhelm.homeip.net/uber-converter/examples/ If someone wants to redraw them in pythoncad, that would be a good place to start. --Eric From ewilhelm at sbcglobal.net Mon Jul 26 22:46:04 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Mon Jul 26 22:44:14 2004 Subject: [PythonCAD] pythoncad drawing In-Reply-To: <200407261250.42919.ewilhelm@sbcglobal.net> References: <9a8f06704072605427757ef5a@mail.gmail.com> <200407261250.42919.ewilhelm@sbcglobal.net> Message-ID: <200407261546.04218.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Eric Wilhelm # on Monday 26 July 2004 12:50 pm: >I know these aren't pythoncad, but this is what I've been using as a source >for my yaml examples: > >If someone wants to redraw them in pythoncad, that would be a good place to >start. New updates here: http://ericwilhelm.homeip.net/uber-converter/examples/ (including some pythoncad xml files.) I'm also beginning work on the CAD::Drawing::IO::FlatYAML module, which will allow me to convert the example.dwg into our proposed flat/*.yml spec. However, it might be a while, since I've got some color issues to work through. --Eric -- The opinions expressed in this e-mail were randomly generated by the computer and do not necessarily reflect the views of its owner. --Management From ewilhelm at sbcglobal.net Tue Jul 27 01:06:29 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Tue Jul 27 01:04:38 2004 Subject: [PythonCAD] file-open dialog patch (cd) Message-ID: <200407261806.29850.ewilhelm@sbcglobal.net> Art, See attached patch. I didn't like the file->open dialog not changing directories when I entered a directory and hit . Seems like gtk should support this by default, but the reference doesn't read that way. If you like it, maybe _get_filename_and_save should behave similarly. --Eric -- Rule out stupidity, then look for the simplest explanation. --Eric's Cleaver -------------- next part -------------- A non-text attachment was scrubbed... Name: file-open_dirswitch.patch Type: text/x-diff Size: 933 bytes Desc: not available Url : http://mail.python.org/pipermail/pythoncad/attachments/20040726/10f4a57c/file-open_dirswitch.bin From ahaas at airmail.net Tue Jul 27 02:41:19 2004 From: ahaas at airmail.net (Art Haas) Date: Tue Jul 27 02:41:28 2004 Subject: [PythonCAD] file-open dialog patch (cd) In-Reply-To: <200407261806.29850.ewilhelm@sbcglobal.net> References: <200407261806.29850.ewilhelm@sbcglobal.net> Message-ID: <20040727004119.GM3996@artsapartment.org> On Mon, Jul 26, 2004 at 06:06:29PM -0500, Eric Wilhelm wrote: > Art, > > See attached patch. I didn't like the file->open dialog not changing > directories when I entered a directory and hit . > > Seems like gtk should support this by default, but the reference doesn't read > that way. > > If you like it, maybe _get_filename_and_save should behave similarly. I've added this with a slight change to my code. It should show up the next time I send stuff to the public repo. The PostScript code generation has been moving slowly. I've not been very productive over the last two weeks. Grrr ... Thanks for the patch. 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 Tue Jul 27 04:26:48 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Tue Jul 27 04:24:57 2004 Subject: [PythonCAD] schema location / colors Message-ID: <200407262126.48098.ewilhelm@sbcglobal.net> Will this eventually point at an actual .xsd file or something? schemaLocation="http://www.pythoncad.org"> What I really want to know is why colors are assigned id's like so: This seems to be an unnecessary complication in representing the colors (though your notes about transitioning to strictly #00FF00 representations are duly noted.) Why even have a table of colors? I'll try to answer my own question, but first a rant about the failings of AutoCAD. Granted, the hexadecimal representation was not likely very standard when autocad started and 24-bit color was possibly even unheard-of at that time. However, they maintained the ACI (Autocad Color Index) convention through to 2000 (I think it changed near version 2004?) The ACI uses the numbers 0-256 to represent 255 colors and the special 'by layer' (256) and 'by block' (0) colors. My guess is that this convention started partly from the need for optimization and partly from the lack of a predominant convention. Today's hardware is rocket-like compared to the hardware of the 70's, so we can safely discard optimization as a need for indexing colors. However, the #09ABCF hexadecimal convention limits us to some extent because we cannot have the non-color colors (or rather, inherited colors) of 'by block' or 'by layer' or even 'by date' (that last one is just for fun.) But, since we are storing things textually and not allocating three byte-sized registers on a magnetic drum, we can use arbitrarily high ascii characters in these slots and have colors like #BY0001, or simply deliberately disobey the 6-character limit and call it #BYLAYER. The presence of one high character is enough to throw a color_parse() subroutine into mode-2, but a convention of #BYfoo allows us a little bit of delicious optimization (e.g. color[1] == "Y".) So, I propose that the colors be represented directly in the entities' properties as 'extended hexidecimal'. If a color table is needed then, it would belong to a layer (or to the drawing), simply listing the default colors per-layer. A blue circle: A blue layer: I don't have any strong opinion about where the layer's properties are stored, but this seems to be a fitting place. --Eric From ewilhelm at sbcglobal.net Tue Jul 27 07:30:31 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Tue Jul 27 07:28:40 2004 Subject: [PythonCAD] pythoncad drawing In-Reply-To: <200407261546.04218.ewilhelm@sbcglobal.net> References: <9a8f06704072605427757ef5a@mail.gmail.com> <200407261250.42919.ewilhelm@sbcglobal.net> <200407261546.04218.ewilhelm@sbcglobal.net> Message-ID: <200407270030.31433.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Eric Wilhelm # on Monday 26 July 2004 03:46 pm: >New updates here: http://ericwilhelm.homeip.net/uber-converter/examples/ Okay, now you get example.xml, which is a hand-coded pythoncad xml file matching the example.dwg, example.dxf as best I can manage. Some notes here: 1. Text (particularly scaling and rotating) is problematic in every gui toolkit I have ever seen (though I haven't tried coding it in Qt or Wx.) I believe this is why autocad has that ugly stroked font as its default. My guess is that most of the high-end cad programs are using vectorizations of the text for their on-screen representation. How does the Gimp handle this with Gtk? I see an 'angle=' property in the TextLine element, which apparently is not implemented yet (maybe when the rotation transform is available?) Text height apparently must be an integer? This has got to somehow turn into a float. 2. Arc angles (and presumably angle properties which are not yet utilized (e.g. for text)) are stored in degrees. This may or may not become problematic as you convert back and forth from degrees to radians in trigonometric calculations. Aside from that, it is just somewhat irregular to me, so it is possibly a matter of convention-conflict. Can anyone cite examples of other file-formats which support degree angles? What about both degree and radian angles? Is it possible to specify that the angle is in degrees in the .xsd? 3. Points are not allowed to be proper entities in this scheme (maybe a "Mark" entity would be able to have linetype, color, etc.) 4. I find the point-table concept somewhat objectionable. Unless you are aiming for relational drafting, it seems somewhat overkill. 5. I'd like to see a transparent value available for the INACTIVE_LAYER_COLOR value which would leave the inactive layer entities painted in their actual colors, but that may be more of an interface issue. 6. See previous e-mail about colors. --Eric -- "It is a mistake to allow any mechanical object to realize that you are in a hurry." --Ralph's Observation From ewilhelm at sbcglobal.net Tue Jul 27 07:44:06 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Tue Jul 27 07:42:15 2004 Subject: [PythonCAD] layers Message-ID: <200407270044.06467.ewilhelm@sbcglobal.net> Continuing with my review, I'll move on to the interface. I'm being critical, because that's how things get critiqued. Please don't take any of this as scathing, scalding, or flaming. Layers nested under layers seems awkward, and there doesn't appear to be a way to create more than one top-level layer. Maybe your analogy for top-level layers is the same as the one that autocad uses for model/layout tabs. If I could have multiple top-level layers, would I be able to see them simultaneously? Also, the differentiation in color of the active layer could get unsettling at higher drawing densities. If I had just drawn a yellow line on layer '300' and then changed to layer 'concrete' and wanted to snap to that yellow line, it is not yellow anymore. That could get confusing if it is between 10 other lines. Possibly, the inactive layer coloring should be done with some sort of mask using the background color (if the background is black, whites turn grey, etc (object color minus background color?)) But, even at that, there should be a way to toggle it on and off. It is good to be able to highlight the active layer, or individual inactive layers, but I mostly don't care what layer things are on while drawing (there's some mental record-keeping and sometimes it just plain doesn't matter.) That said, turning off layers to find what is what can be a real pain too. --Eric -- "Unthinking respect for authority is the greatest enemy of truth." --Albert Einstein From ewilhelm at sbcglobal.net Tue Jul 27 07:56:17 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Tue Jul 27 07:54:24 2004 Subject: [PythonCAD] selections and stop commands Message-ID: <200407270056.17128.ewilhelm@sbcglobal.net> This is probably a throwback habit from autocad, but I'm finding myself drawing things when I think I should be in a selection mode. It seems that a command is always active, which got me into some kind of point-polyline inescapable chaos earlier when I tried to undo while drawing a polyline (maybe that's only possible on the debian's release 15.) Do this: start drawing a polyline and hit Ctrl+Z. I get some funky redline action here (and the death of my previously drawn items!?) (using the repo code.) Esc seems to work in the repo code, but it completes the operation with the final point at the mouse cursor, and apparently loses focus somewhere (I think I clicked in the text-entry box (oh, no I just typed 'c').) (now that I think of it, this may be the case with the release 15 too.) Closing a polyline does not seem to be an option. Further, the selection model does not allow me to drag the points into position? I'm just poking around right now, so maybe I'm misguided, but this should at least give you some new-user entropy feedback. --Eric -- "There are three terrible ages of childhood -- 1 to 10, 10 to 20, and 20 to 30." --Cleveland Amory From csomerlot at gmail.com Tue Jul 27 15:15:09 2004 From: csomerlot at gmail.com (Chris Somerlot) Date: Tue Jul 27 15:15:13 2004 Subject: [PythonCAD] layers In-Reply-To: <200407270044.06467.ewilhelm@sbcglobal.net> References: <200407270044.06467.ewilhelm@sbcglobal.net> Message-ID: <9a8f06704072706155fbf3381@mail.gmail.com> My 2 cents: > Layers nested under layers seems awkward, and there doesn't appear to be a way > to create more than one top-level layer. Maybe your analogy for top-level > layers is the same as the one that autocad uses for model/layout tabs. If I > could have multiple top-level layers, would I be able to see them > simultaneously? I don't know. Layer management under autocad and microstation has always seemed awkward to me, and I see pythoncad as having improved on the process. I like the advantage to nested layers: one layer contains all the data on say topography, with nested layers for labels and contours. All the nested layers can be turned on or off thru the parent layer. The toplevel layer is present in any drawing, whether it is implicit or explicit. I think in proper cad etiquette nothing is drawn on that layer, and in throw-away drawings its more of a place holder, like the "0" layer in autocad. > > Also, the differentiation in color of the active layer could get unsettling at > higher drawing densities. If I had just drawn a yellow line on layer '300' > and then changed to layer 'concrete' and wanted to snap to that yellow line, > it is not yellow anymore. That could get confusing if it is between 10 other > lines. I'll admit this took some getting used to. But again, this streamlines layer management for me. 90% of the time I'll open up one of my autocad drawings and just start drawing things without paying attention to layers, then go back and change all the layer properties > Possibly, the inactive layer coloring should be done with some sort of mask > using the background color (if the background is black, whites turn grey, etc > (object color minus background color?)) But, even at that, there should be a > way to toggle it on and off. It is good to be able to highlight the active > layer, or individual inactive layers, but I mostly don't care what layer > things are on while drawing (there's some mental record-keeping and sometimes > it just plain doesn't matter.) That said, turning off layers to find what is > what can be a real pain too. Yeah, this would be good. Sometimes I differentiate between layers by setting them to different colors. -Chris- From ahaas at airmail.net Tue Jul 27 16:44:53 2004 From: ahaas at airmail.net (Art Haas) Date: Tue Jul 27 16:45:01 2004 Subject: [PythonCAD] pythoncad drawing In-Reply-To: <200407270030.31433.ewilhelm@sbcglobal.net> References: <9a8f06704072605427757ef5a@mail.gmail.com> <200407261250.42919.ewilhelm@sbcglobal.net> <200407261546.04218.ewilhelm@sbcglobal.net> <200407270030.31433.ewilhelm@sbcglobal.net> Message-ID: <20040727144453.GO3996@artsapartment.org> On Tue, Jul 27, 2004 at 12:30:31AM -0500, Eric Wilhelm wrote: > > 1. Text (particularly scaling and rotating) is problematic in every gui > toolkit I have ever seen (though I haven't tried coding it in Qt or Wx.) I > believe this is why autocad has that ugly stroked font as its default. My > guess is that most of the high-end cad programs are using vectorizations of > the text for their on-screen representation. How does the Gimp handle this > with Gtk? QT has a global transformation matrix which you can modify to handle things like scaling and rotation. GTK doesn't have this, but GNOME apparently does via the libart library (I think). > I see an 'angle=' property in the TextLine element, which apparently is not > implemented yet (maybe when the rotation transform is available?) Yes. I added the 'angle' attribute for the ability to have the text at some angle, but there is no code doing this right now. > Text height apparently must be an integer? This has got to somehow turn into > a float. Text handling in PythonCAD has stayed just one step beyond primitive. When I added it initially I thought that the text size should be defined in points, but that approach is wrong. The text size will need to be defined as a float, and the text size (as points) scaled to fit the value. > > 2. Arc angles (and presumably angle properties which are not yet utilized > (e.g. for text)) are stored in degrees. This may or may not become > problematic as you convert back and forth from degrees to radians in > trigonometric calculations. Aside from that, it is just somewhat irregular > to me, so it is possibly a matter of convention-conflict. Can anyone cite > examples of other file-formats which support degree angles? What about both > degree and radian angles? Is it possible to specify that the angle is in > degrees in the .xsd? I thought specifying the angles in degrees was easier to deal with than keeping them as radians, and I still believe this to be true. There is the extra step of converting them to radians when doing trig operations, but that is a small price to pay. > 3. Points are not allowed to be proper entities in this scheme (maybe a > "Mark" entity would be able to have linetype, color, etc.) I've always viewed points as just infinitely small entities, so assigning them colors or linetypes doesn't make sense. The program could be adjusted to draw points as 1 or 2 pixel boxes on the screen, and if that were done I'd suggest adding an option in the preferences for setting the display color. > 4. I find the point-table concept somewhat objectionable. Unless you are > aiming for relational drafting, it seems somewhat overkill. ??? > 5. I'd like to see a transparent value available for the > INACTIVE_LAYER_COLOR value which would leave the inactive layer > entities painted in their actual colors, but that may be more of > an interface issue. This behavior of changing the entity colors comes from my experience with ME-10. I thought it was a good way of indicating that the entities are not in the current active layer. ME-10 also had a mode where the inactive layer entities were kept in their normal color, and I always found that confusing when I tried to identify which on screen entities I could modify and which ones I couldn't. 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 Tue Jul 27 17:06:03 2004 From: ahaas at airmail.net (Art Haas) Date: Tue Jul 27 17:06:40 2004 Subject: [PythonCAD] schema location / colors In-Reply-To: <200407262126.48098.ewilhelm@sbcglobal.net> References: <200407262126.48098.ewilhelm@sbcglobal.net> Message-ID: <20040727150603.GP3996@artsapartment.org> On Mon, Jul 26, 2004 at 09:26:48PM -0500, Eric Wilhelm wrote: > Will this eventually point at an actual .xsd file or something? > schemaLocation="http://www.pythoncad.org"> Yes. That location was filler until the schema was finished, and I haven't worked on that in quite some time. :-( > What I really want to know is why colors are assigned id's like so: > > > > > > > > > This seems to be an unnecessary complication in representing the colors > (though your notes about transitioning to strictly #00FF00 representations > are duly noted.) I initially thought defining the colors as just R, G, and B values made sense. I then added the 'color=' bit. The idea was that entities would just reference the color id, and by doing so would reduce the file size as the 'cid=X' is smaller than 'color=#XXXXXX'. > Why even have a table of colors? I'll try to answer my own question, but > first a rant about the failings of AutoCAD. > > Granted, the hexadecimal representation was not likely very standard when > autocad started and 24-bit color was possibly even unheard-of at that time. > However, they maintained the ACI (Autocad Color Index) convention through to > 2000 (I think it changed near version 2004?) > > The ACI uses the numbers 0-256 to represent 255 colors and the special 'by > layer' (256) and 'by block' (0) colors. My guess is that this convention > started partly from the need for optimization and partly from the lack of a > predominant convention. Today's hardware is rocket-like compared to the > hardware of the 70's, so we can safely discard optimization as a need for > indexing colors. > > However, the #09ABCF hexadecimal convention limits us to some extent because > we cannot have the non-color colors (or rather, inherited colors) of 'by > block' or 'by layer' or even 'by date' (that last one is just for fun.) But, > since we are storing things textually and not allocating three byte-sized > registers on a magnetic drum, we can use arbitrarily high ascii characters in > these slots and have colors like #BY0001, or simply deliberately disobey the > 6-character limit and call it #BYLAYER. The presence of one high character > is enough to throw a color_parse() subroutine into mode-2, but a convention > of #BYfoo allows us a little bit of delicious optimization (e.g. color[1] == > "Y".) > > So, I propose that the colors be represented directly in the entities' > properties as 'extended hexidecimal'. If a color table is needed then, it > would belong to a layer (or to the drawing), simply listing the default > colors per-layer. > > A blue circle: > style="0"/> > > A blue layer: > > > style="0"/> > > I don't have any strong opinion about where the layer's properties are > stored, but this seems to be a fitting place. As someone not coming from an AutoCAD background, I had no background on how colors were dealt with in that program. I like the '#xxxxxx' format for specifying colors as it's used in lots of software like X Window colors or web page colors. The hexidecimal format is easy to deal with in Python as well. I've not thought of having a layer color before, though how you represent it above makes sense. If such a feature gets added to the program, I'd want to see the entities reference the color in a different manner than by using the "color=" attribute. I don't know just what right now, but I'm not initially keen on the '#BYLAYER' approach. I don't like the idea of having "color=" be something other than a hex formatted color string. As for layer colors, I that ability something that is used frequently in AutoCAD? I don't see much use for it initially ... 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 Tue Jul 27 17:17:30 2004 From: ahaas at airmail.net (Art Haas) Date: Tue Jul 27 17:17:37 2004 Subject: [PythonCAD] layers In-Reply-To: <200407270044.06467.ewilhelm@sbcglobal.net> References: <200407270044.06467.ewilhelm@sbcglobal.net> Message-ID: <20040727151730.GQ3996@artsapartment.org> On Tue, Jul 27, 2004 at 12:44:06AM -0500, Eric Wilhelm wrote: > Continuing with my review, I'll move on to the interface. I'm being > critical, because that's how things get critiqued. Please don't take > any of this as scathing, scalding, or flaming. This is good stuff. Keep it coming. > > Layers nested under layers seems awkward, and there doesn't appear to > be a way to create more than one top-level layer. Maybe your analogy > for top-level layers is the same as the one that autocad uses for > model/layout tabs. If I could have multiple top-level layers, would > I be able to see them simultaneously? A-la Highlander, there can be only one ... top layer. I think of layers in a manner similar to directories on the unix file system, and the top layer is the root directory. You can have as many sublayers as you like, and each sublayer can have sublayers, and so on, but there is just one topmost directory. This approach was how ME-10 worked as well. My AutoCAD experiences from way back when are that a drawing had lots of layers, but that layers could not be nested. Nesting layers may be possible, but I don't recall doing that, nor seeing drawings made by others that did that. > > Also, the differentiation in color of the active layer could get > unsettling at higher drawing densities. If I had just drawn a yellow > line on layer '300' and then changed to layer 'concrete' and wanted to > snap to that yellow line, it is not yellow anymore. That could get > confusing if it is between 10 other lines. That is true. > > Possibly, the inactive layer coloring should be done with some sort of mask > using the background color (if the background is black, whites turn grey, etc > (object color minus background color?)) But, even at that, there should be a > way to toggle it on and off. It is good to be able to highlight the active > layer, or individual inactive layers, but I mostly don't care what layer > things are on while drawing (there's some mental record-keeping and sometimes > it just plain doesn't matter.) That said, turning off layers to find what is > what can be a real pain too. > In another mail I mentioned that the color change when activating or deactivating a layer came from my use of ME-10, and ME-10 had the ability to disable the color change. I always found it very confusing when working in that mode, as I had a hard time telling what entities were in the layer (in ME-10 speak the layer is a "part") I was currently editing and which entities weren't. Adding the ability to switch on or off the use of the INACTIVE_LAYER_COLOR sounds like something that could be done with relatively little coding, so I'll take a look at doing that. If someone sends along a patch to do this I'd look at that also ... :-) 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 Tue Jul 27 17:35:07 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Tue Jul 27 17:33:15 2004 Subject: [PythonCAD] pythoncad drawing In-Reply-To: <20040727144453.GO3996@artsapartment.org> References: <9a8f06704072605427757ef5a@mail.gmail.com> <200407270030.31433.ewilhelm@sbcglobal.net> <20040727144453.GO3996@artsapartment.org> Message-ID: <200407271035.07859.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Art Haas # on Tuesday 27 July 2004 09:44 am: >> 4. ?I find the point-table concept somewhat ?objectionable. ?Unless you >> are aiming for relational drafting, it seems somewhat overkill. > >? >??? If this is associative or relational drafting, then you have a circle with a center point, and a segment which uses that same point plus another point. If you move the circle, the segment moves. If you move the segment, the circle moves. (Actually, you are moving the point, which is being shared between entities.) Is this a behavior you were aiming for? I think it is mainly an issue about importing geometry. Without digging into the code, I can offer this example: http://ericwilhelm.homeip.net/uber-converter/examples/dup_points.xml pythoncad doesn't like loading this hand-modified file. I'm guessing that it (the use of a point table) has something to do with your snap scheme. dwg and dxf files are going to have points stored in each entity, even if they are matching points. Because of round-off error, it seems that you would have an expensive point-comparison task to import a large dwg/dxf into pythoncad. Also, what is the relationship between points on different layers? If there can be duplicated points on separate layers, then you don't have the associativity between objects on different layers. That seems somewhat inconsistent. To be consistent, you would need a global points table instead of per-layer. --Eric -- "Blessed are the young, for they shall inherit the national debt." --Herbert Hoover From ahaas at airmail.net Tue Jul 27 17:53:29 2004 From: ahaas at airmail.net (Art Haas) Date: Tue Jul 27 17:53:36 2004 Subject: [PythonCAD] pythoncad drawing In-Reply-To: <200407271035.07859.ewilhelm@sbcglobal.net> References: <9a8f06704072605427757ef5a@mail.gmail.com> <200407270030.31433.ewilhelm@sbcglobal.net> <20040727144453.GO3996@artsapartment.org> <200407271035.07859.ewilhelm@sbcglobal.net> Message-ID: <20040727155329.GS3996@artsapartment.org> On Tue, Jul 27, 2004 at 10:35:07AM -0500, Eric Wilhelm wrote: > # The following was supposedly scribed by > # Art Haas > # on Tuesday 27 July 2004 09:44 am: > > >> 4. ?I find the point-table concept somewhat ?objectionable. ?Unless you > >> are aiming for relational drafting, it seems somewhat overkill. > > > >? > >??? > > If this is associative or relational drafting, then you have a circle with a > center point, and a segment which uses that same point plus another point. > If you move the circle, the segment moves. If you move the segment, the > circle moves. (Actually, you are moving the point, which is being shared > between entities.) Is this a behavior you were aiming for? No. I just tried doing some simple moves things and only the one entity I click on to move is moved. I made a circle, then drew a segment which used the center point, then when to 'Modify'->'Move'->'Horizontal'. I then made two mouse clicks to define the distance, then I clicked on the circle. It moved, and the segment did not. Doing a move operation on the segment left the circle in place. How are you doing the move? Are you drawing a box around the entities? > > I think it is mainly an issue about importing geometry. > > Without digging into the code, I can offer this example: > http://ericwilhelm.homeip.net/uber-converter/examples/dup_points.xml > > pythoncad doesn't like loading this hand-modified file. I'm guessing that it > (the use of a point table) has something to do with your snap scheme. > dwg and dxf files are going to have points stored in each entity, even if > they are matching points. Because of round-off error, it seems that you > would have an expensive point-comparison task to import a large dwg/dxf into > pythoncad. There will have to be some sort of testing involved when loading in a DWG/DXF file because of the file's way of storing points. I don't believe doing a test to look for an existing point when loading a new entity from one of these files will be that bad though. At least I hope that is the case. > Also, what is the relationship between points on different layers? If there > can be duplicated points on separate layers, then you don't have the > associativity between objects on different layers. That seems somewhat > inconsistent. To be consistent, you would need a global points table instead > of per-layer. Objects that are on different layers have no associativity in regards to sharing points. That is, you can't make an entity with some of its points in one layer, and other points in another. Dimensions are the only entities that can span layers. -- 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 Tue Jul 27 19:13:54 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Tue Jul 27 19:12:02 2004 Subject: [PythonCAD] pythoncad points In-Reply-To: <20040727155329.GS3996@artsapartment.org> References: <9a8f06704072605427757ef5a@mail.gmail.com> <200407271035.07859.ewilhelm@sbcglobal.net> <20040727155329.GS3996@artsapartment.org> Message-ID: <200407271213.54371.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Art Haas # on Tuesday 27 July 2004 10:53 am: >> If this is associative or relational drafting, then you have a circle with >> a center point, and a segment which uses that same point plus another >> point. If you move the circle, the segment moves. ?If you move the >> segment, the circle moves. ?(Actually, you are moving the point, which is >> being shared between entities.) ?Is this a behavior you were aiming for? note, the above is a scenario describing what happens IF this is relational/associative drawing. >No. I just tried doing some simple moves things and only the one entity >I click on to move is moved. I made a circle, then drew a segment which >used the center point, then when to 'Modify'->'Move'->'Horizontal'. I >then made two mouse clicks to define the distance, then I clicked on the >circle. It moved, and the segment did not. Doing a move operation on the >segment left the circle in place. > >How are you doing the move? Are you drawing a box around the entities? You misunderstand. My point is that pythoncad doesn't work that way. That's why I don't understand the reason for storing points in a table and referencing the same point from more than one entity. I can understand storing points in a table, provided that each point is referenced by one and only one entity. But, then it is just an issue of file-format human-readability. See the xml file referenced in my previous message. It loads with an error "Failed to add object: : Segment p1 Point not found in Layer." If I draw a circle, and then a segment which uses the circle's center as one end, saving this drawing results in a point table with two entries. This implies that the entities are associated to the same point (e.g. dependent on each other.) But, if I move the circle or move the segment, saving results in a point table with three entries. This implies that the entities are independent. Unless I can select the point and use it to simultaneously move the circle while moving just that end of the segment, the point association is inconsistent. Are you are planning to support the movement of points in the future? If so, the interface to selecting and moving might be tricky. A related note, I just made a circle, and then did modify->move and selected only the point (this is not possible with line segments.) Pythoncad duplicated and moved the point, but did not move the circle. This also gives me some ugly error messages on closing. Back to the associated points table. If this is a disk-space efficiency thing, I'm afraid it is a false economy. Let's say you draw a pattern of 360 radial lines, each 1 degree apart with a common center point. If the lines each have two point stored at ~60 characters per point, then we have 359 points that wouldn't be stored if we used a shared point for one end of each line (center of the pattern.) That's only 21k saved before compression. There is validity to both approaches, but if you aren't making pythoncad into an associative program, I think associating common points is inconsistent with that design philosophy and capable of opening several corner cases that you wouldn't have if you simply treat each entity as self-contained. I think it comes down to this: Do the entities own the points or the points own the entities? If the points own the entities and are capable of owning more than one entity, the interface would eventually need to support editing points as such and orphaning entities (giving them a new parent point.) --Eric -- "Because understanding simplicity is complicated." --Eric Raymond From ahaas at airmail.net Tue Jul 27 20:17:39 2004 From: ahaas at airmail.net (Art Haas) Date: Tue Jul 27 20:23:39 2004 Subject: [PythonCAD] pythoncad points In-Reply-To: <200407271213.54371.ewilhelm@sbcglobal.net> References: <9a8f06704072605427757ef5a@mail.gmail.com> <200407271035.07859.ewilhelm@sbcglobal.net> <20040727155329.GS3996@artsapartment.org> <200407271213.54371.ewilhelm@sbcglobal.net> Message-ID: <20040727181739.GT3996@artsapartment.org> On Tue, Jul 27, 2004 at 12:13:54PM -0500, Eric Wilhelm wrote: > # The following was supposedly scribed by > # Art Haas > # on Tuesday 27 July 2004 10:53 am: > > >> If this is associative or relational drafting, then you have a circle with > >> a center point, and a segment which uses that same point plus another > >> point. If you move the circle, the segment moves. ?If you move the > >> segment, the circle moves. ?(Actually, you are moving the point, which is > >> being shared between entities.) ?Is this a behavior you were aiming for? > > note, the above is a scenario describing what happens IF this is > relational/associative drawing. > > >No. I just tried doing some simple moves things and only the one entity > >I click on to move is moved. I made a circle, then drew a segment which > >used the center point, then when to 'Modify'->'Move'->'Horizontal'. I > >then made two mouse clicks to define the distance, then I clicked on the > >circle. It moved, and the segment did not. Doing a move operation on the > >segment left the circle in place. > > > >How are you doing the move? Are you drawing a box around the entities? > > You misunderstand. My point is that pythoncad doesn't work that way. That's > why I don't understand the reason for storing points in a table and > referencing the same point from more than one entity. > > I can understand storing points in a table, provided that each point is > referenced by one and only one entity. But, then it is just an issue of > file-format human-readability. > > See the xml file referenced in my previous message. It loads with an error > "Failed to add object: : > Segment p1 Point not found in Layer." > > If I draw a circle, and then a segment which uses the circle's center as one > end, saving this drawing results in a point table with two entries. This > implies that the entities are associated to the same point (e.g. dependent on > each other.) Yes, because they segment endpoint is the same as the circle center. > But, if I move the circle or move the segment, saving results in a point > table with three entries. This implies that the entities are independent. They are now independent because neither of the segment endpoints falls on the circle center. > Unless I can select the point and use it to simultaneously move the circle > while moving just that end of the segment, the point association is > inconsistent. > Are you are planning to support the movement of points in the future? If so, > the interface to selecting and moving might be tricky. I just took a look at the move code in 'Generic/move.py'. The 'move_objects' function is called when a boxed selection is called. It omits the case when a point is included in the boxing, and that looks like the root cause of this discrepancy. Adding a bit of code to this function to retrieve all the entities associated with a point and move them whether or not they were within the boxed region would not be a big deal I believe. > A related note, I just made a circle, and then did modify->move and selected > only the point (this is not possible with line segments.) Pythoncad > duplicated and moved the point, but did not move the circle. This also gives > me some ugly error messages on closing. > > Back to the associated points table. If this is a disk-space efficiency > thing, I'm afraid it is a false economy. Let's say you draw a pattern of 360 > radial lines, each 1 degree apart with a common center point. If the lines > each have two point stored at ~60 characters per point, then we have 359 > points that wouldn't be stored if we used a shared point for one end of each > line (center of the pattern.) That's only 21k saved before compression. I don't think saving 21K is a bad thing. I have a personal beef against file formats that have gotten larger and larger, and even today when disk space is cheap, I want the file to be as small as I can make it. > There is validity to both approaches, but if you aren't making pythoncad into > an associative program, I think associating common points is inconsistent > with that design philosophy and capable of opening several corner cases that > you wouldn't have if you simply treat each entity as self-contained. > > I think it comes down to this: Do the entities own the points or the points > own the entities? If the points own the entities and are capable of owning > more than one entity, the interface would eventually need to support editing > points as such and orphaning entities (giving them a new parent point.) When trying to answer this, I want to say that "entities control points" and I also want to say "points control entities", so I need to sit and figure out when "entities control points" is more true than "points control entities", and visa-versa. -- 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 Tue Jul 27 21:13:52 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Tue Jul 27 21:12:00 2004 Subject: [PythonCAD] pythoncad points In-Reply-To: <20040727181739.GT3996@artsapartment.org> References: <9a8f06704072605427757ef5a@mail.gmail.com> <200407271213.54371.ewilhelm@sbcglobal.net> <20040727181739.GT3996@artsapartment.org> Message-ID: <200407271413.52404.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Art Haas # on Tuesday 27 July 2004 01:17 pm: >> If I draw a circle, and then a segment which uses the circle's center as >> one end, saving this drawing results in a point table with two entries. >> This implies that the entities are associated to the same point (e.g. >> dependent on each other.) > >Yes, because they segment endpoint is the same as the circle center. > >> But, if I move the circle or move the segment, saving results in a point >> table with three entries. This implies that the entities are independent. > >They are now independent because neither of the segment endpoints falls >on the circle center. Okay, so you are saying that they are associated unless they are not ;-) This is a valid theme iff it carries through into the interface. Resolving this will give the coherency that I'm looking for. Right now, it seems that the dependence only really manifests itself in the file-format and data-structures (and thus is capable of also manifesting itself on-screen in the form of bugs.) >I just took a look at the move code in 'Generic/move.py'. The >'move_objects' function is called when a boxed selection is called. It >omits the case when a point is included in the boxing, and that looks >like the root cause of this discrepancy. Adding a bit of code to this >function to retrieve all the entities associated with a point and move >them whether or not they were within the boxed region would not be a big >deal I believe. It would have to go slightly beyond that. I'll see if I can hammer this out below... >> There is validity to both approaches, but if you aren't making pythoncad >> into an associative program, I think associating common points is >> inconsistent with that design philosophy and capable of opening several >> corner cases that you wouldn't have if you simply treat each entity as >> self-contained. >> >> I think it comes down to this: Do the entities own the points or the >> points own the entities? If the points own the entities and are capable >> of owning more than one entity, the interface would eventually need to >> support editing points as such and orphaning entities (giving them a new >> parent point.) > >When trying to answer this, I want to say that "entities control points" >and I also want to say "points control entities", so I need to sit and >figure out when "entities control points" is more true than "points >control entities", and visa-versa. Okay, so pythoncad is to be an informally associative drafting program. That's great. Now to just make it have a coherent data/interface theme. Let me try this analogy: My father is MY father, but he is also my brother's father. We are both HIS children. Let's say my brother and I both live at home. What happens when my father relocates is fairly clear. Without getting overly legal or emotional, what we have to decide is what happens when I emancipate myself and what happens when my father orphan's me. In either case, I become my own guardian. Translating this to the point and circle, I've got to be two entities when I lose my parent (or rather, I will create a parent for myself.) So, in creating a circle where there is no point to snap to, a 'parent' point must be created which controls the center of the circle. The circle has a cp="0" attribute which proclaims that it is owned by the point with id="0". If I create a segment, with one as-yet-unused point and the point "0", the first point of the segment is again a parent which springs into existence. The second point of the segment is an existing parent, which adopts the segment. (now we have two points and two entities (one shared point.)) If I move the circle, it is no longer owned by the original point. Rather, it must find (or create) a new parent point. If I move the line, both of its parent points are possibly left without children. The line will have two different parent points after the move. If I move the point instead of the circle, I am simply moving the point. This causes a deformation of the segment. AutoCAD handles a procedure similar to this with its 'grip-edit' functionality, where you select one or more entities and drag a point. Any of the selected entities which have that point in common are modified. But, this is not autocad, and here the points are associative in-memory and on-screen, so let me try my hand at a list of rules. 1. Creating Entities: A. no existing points: new points are created and used to 'parent' the entity B. existing points: the point parents the entity 2. Moving Entities: A. Shared point: new parent point(s) is(are) created for the moved entity. B. Not shared: new parent point(s) is(are) created, old parent point is deleted. 3. Moving points: A. all entities connected AND selected: move the point, allowing entities to follow B. some entities connected AND selected: move the point, allowing selected entities to follow, create a new parent point at the old location to own the un-selected entities. Note that: 2B implies that points never move when entities are selected, rather the destination points are created anew (and source points are destroyed if unused) 2B combined with 3B implies a special selection method for moving points where points are selected first, and then entities. This could default to select all connected entities, and de-select mode could then be activated. This also implies the need for more feedback as to what is selected (highlighting of points and entities.) A global points table should be used, so that entities can share the points across layers. This is just one possible theme, but (IMO) if you don't have this or something like it, the points are NOT associated (e.g. redundant points are saved in the file, points are not selectable, and coincidence of two points is only coincidental:) --Eric -- Cult: A small, unpopular religion. Religion: A large, popular cult. -- Unknown From ewilhelm at sbcglobal.net Tue Jul 27 23:07:07 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Tue Jul 27 23:05:14 2004 Subject: [PythonCAD] colors In-Reply-To: <20040727150603.GP3996@artsapartment.org> References: <200407262126.48098.ewilhelm@sbcglobal.net> <20040727150603.GP3996@artsapartment.org> Message-ID: <200407271607.07084.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Art Haas # on Tuesday 27 July 2004 10:06 am: > I like the '#xxxxxx' format >for specifying colors I agree. Is this scheme actually used to paint the entities now, or is it a placeholder? >I've not thought of having a layer color before, though how you >represent it above makes sense. If such a feature gets added to the >program, I'd want to see the entities reference the color in a different >manner than by using the "color=" attribute. I don't know just what >right now, but I'm not initially keen on the '#BYLAYER' approach. I >don't like the idea of having "color=" be something other than a hex >formatted color string. Now that I think of it, why bother having the # ? You could use a different symbol as the leader to indicate that it is a directive and not a literal color (maybe "&bylayer".) Consider this. If you have color="3" referring to an indexed color right now, re-using that as color="#FFFF00" is going to mean some kind of compatibility function (for at least some period of time) to enable loading older pythoncad files. (?) If so, that function could easily handle color="bylayer" or some non-integer, non-hex directive. I'm looking at Interface/Gtk/gtkimage.py at around line 170, and it looks like you have to allocate a color before you can paint the item onto the canvas. Let me know if I'm off-track. So, is the xml a reflection of the 'image' data structure? >As for layer colors, I that ability something that is used frequently in >AutoCAD? I don't see much use for it initially ... I've used it a lot. AutoCAD (and presumably microstation) also has support for defining linetypes and lineweights as 'by layer'. This allows you to make a change in one place and have an impact on multiple entities. In viewing, it is not as applicable, but it plays a large role in plotting. In terms of pythoncad's use and support of layer colors, maybe it should have something to do with the active layer / inactive layer colors that I mentioned before. If I disable the 'active-layer-highlighting' (when this becomes possible), what should happen? One possible theme: Layers have colors, and entities can inherit the layers color (and do so by default.) When highlighting is off, the layers are displayed in their colors and entities with color over-rides are displayed in the entity's color. When highlighting is set to 'mask' (a new form of 'on'), the colors of the layers and entities is masked against the 'background mask' color. When highlighting is set to 'solid' (the current form of 'on' ?) , the background layers are displayed with the 'background color' color. --Eric -- I arise in the morning torn between a desire to improve the world and a desire to enjoy the world. This makes it hard to plan the day. --E.B. White From ahaas at airmail.net Wed Jul 28 23:44:50 2004 From: ahaas at airmail.net (Art Haas) Date: Wed Jul 28 23:45:16 2004 Subject: [PythonCAD] Printing update Message-ID: <20040728214450.GA3996@artsapartment.org> Hi. As no new code has shown up in the repo for a while, I think it is good to say a couple of words as to what sort of progress has been made with regards to printing lately. Earlier messages to the list have alluded to my lack of productivity, but the last couple of weeks have not been entierly squandered. I can get segments, circles, arcs, polylines, leaders (and the arrow head), and the basic dimension shapes printed to a page. Text doesn't yet print, but that isn't because I don't know the PostScript commands to put some text on a page. The basic string printing command in PostScript is "show" by the way, and fancier things can be done with "kshow" and "ashow". Whats hindering text printing is the weak text support in PythonCAD itself, so I've started working on some text handling code now. One thing that will change is that the text size will be a float value, and when the code is done, the text should scale correctly when you zoom in or out. Currently, text size is given as an integer, and is always draw at that value (in points), making the text size change relative to the entities in the drawing. This problems will be fixed when the text code receives some much needed work. I'm targeting the next release for some time in August, probably the second half of the month. Basic printing features will be in the release, so at long last PythonCAD will be able to waste paper like most print-enabled software! The paper trusts will be pleased to hear this news ... :-) 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 Thu Jul 29 04:43:26 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Thu Jul 29 04:41:28 2004 Subject: [PythonCAD] colors In-Reply-To: <9a8f067040728185837b41cae@mail.gmail.com> References: <200407262126.48098.ewilhelm@sbcglobal.net> <200407271607.07084.ewilhelm@sbcglobal.net> <9a8f067040728185837b41cae@mail.gmail.com> Message-ID: <200407282143.26930.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Chris Somerlot # on Wednesday 28 July 2004 08:58 pm: >Some sample yaml from the conversion of the example.xml drawing I've updated the index. Let me know when you've got a new set. http://ericwilhelm.homeip.net/uber-converter/examples/ --Eric -- A counterintuitive sansevieria trifasciata was once literalized guiltily. --Product of Artificial Intelligence