On 2013-10-16 08:44-0700 Ferrell, Stephen wrote: > It doesn't rely on any external libraries nor does it produce a particular dialect. I've tested it using AutoCAD12 all the way thru AutoCAD 2013 without problems.
How does it do with non-autocad software? According to http://en.wikipedia.org/wiki/AutoCAD_DXF, DXF was designed originally to allow interoperability, but in practice there are some problems. On the other hand, plotting needs may be simple enough that interoperability is not a problem, but it would be good to check that because at least some of your users will want to use software other than autocad to read these results. > The DXF format can handle some very complex objects but since this driver is based off of the HPGL and LJII drivers it doesn't support flood fills or gradients. It will instead attempt to use polyline hatching in place of flood fills and gradients. And you are correct in that everything the DXF driver produces is ultimately a line or a polyline. It is a much better option for me because things would always get lost or mangled in translation when I tried to import EPS, PDF of SVG files into various CAD programs from plplot. It sounds like you have made a good start, but I would advise that you do implement fills and gradients. Also, your device should support unicode-aware fonts because the Hershey fonts you must fall back on now are pretty ugly. So long as you understand how to handle fills, gradients, and/or unicode-aware fonts from the DXF perspective, then the actual interfacing of those capabilities to PLplot is straightforward; you just have to follow the lead given by our best devices (e.g., svg, cairo, and qt) all of which have these desired capabilities. HPGL and LJII are actually not recommended as good prototypes of device drivers because they are not fill, gradient, or unicode text aware. It sounds like your device is basically working now, but neverthesse you should be aware that HPFL and LJII haven't received any recent maintenance because they have long been retired. I believe all of my above remarks hold regardless of whether you are developing this device external to the PLplot project or if you want to share it with PLplot under the terms of the LGPL. I believe Andrew is going to comment further on that second possibility. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
