Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Open Human Readable Computer Aided Design file format

by SciDude (Friar)
on Sep 05, 2004 at 06:03 UTC ( #388575=CUFP: print w/ replies, xml ) Need Help??

Bruno Postle has proposed an interesting CAD file format, complete with proof of concept application written in perl.


  1. If it can be a separate file, then that's what it should be.
    • Fast efficient saving
    • Fast efficient reading
    • Infinite undo
    • Changes are easily encapsulated and portable
    • Full version tagging and release management
    • Embedded resources are kept external
    • Fine-grained permissions system
    • Platform-independent data
    • Object-oriented data

The beauty of this concept is the leverage of existing tools (modern filesystems, versioning, perl/tk, etc.) to provide an elegant example of what is now possible but rarely implemented.

With CVS, multiple authors can work on a single CAD project complete with real time display of all changes as they happen.

Each element of the drawing (an object perhaps; line, circle, etc.) can be described in a simple and human readable text file:

Content-Type: application/drawing; class=line/plain Version: 1.0 Units: millimetres 0: 10 0: 20 0: 0 1: 10 1: 40 1: 0 License: Copyright: Jane Doe <>

Groups of these files make an application which can later be used as a reference, providing object oriented approach to CAD design.

Making the hard things possible...

The author makes these points clear in about "400 lines of perl code." I downloaded the proof of concept application, installed the few modules necessary and it worked perfectly on my Fedora FC2 box. The concepts demonstrated in perl may not provide for the needs of a commercial CAD application and the author states (in various POD comments) that perl is not the solution for long term CAD implementations.

What is profoundly important are the concepts demonstrated. Faced with thousands of text files, perl was the natural solution for parsing and display of this information. With a bit more work, I am certain this proof of concept could surprise more than I with the possibilities of perl/tk and GUI applications to visual data display.

The first dog barks... all other dogs bark at the first dog.

Comment on Open Human Readable Computer Aided Design file format
Download Code
Replies are listed 'Best First'.
Re: Open Human Readable Computer Aided Design file format
by acomjean (Sexton) on Sep 07, 2004 at 14:21 UTC
    This is a good idea. Having worked with converted autocad files (which needed extensive AutoLisp scripts to fix), and open standard for CAD files would be good.

    May SVG (Scaleable Vector Graphics) specification

    could be used as a usefull base or somehow incorporated since they have similar elements?

Re: Open Human Readable Computer Aided Design file format
by Rhandom (Curate) on Sep 07, 2004 at 20:12 UTC
    Sorry to post two responses - I thought I'd give counter points to the specifics above - and again this isn't the best forum to discuss these.

    • Human readable. I like human readability. DXF is fairly human readable (sort of). In the proposed system, once you have found a line it is easier to change the X coordinate. However, it is probably only a little bit easier to find a line in the proposed system than it is in a DXF. If you have a database filesystem, search would help you find it even more quickly.
    • If it can be a separate file, then that's what it should be. One should never make a blanket statement. ;) There should be a limit to granularity. Exploring those limits is an exercise to the implementor. Putting each line entity or each point entity into a separate file may be pushing the limits a bit (I know ReiserFS would love it though).
    • Fast efficient saving - No arguments here
    • Fast efficient reading - No arguments here either
    • Infinite undo. - Well - undo to what level - this only applies if each modification, no matter how small, uses a CVS commit. With this the CVS storage files would become huge over time and would be fairly slow on a remote CVS repository. Without this you get undo with steps that consist of revision saves of the entire document.
    • Changes are easily encapsulated and portable - Love this one also. Great idea. CVS is perfect for this - but is probably pretty good for DXF as well.
    • Full version tagging and release management - Plain text DXF or drawingXML would offer the same features.
    • Embedded resources are kept external - XREF's in drawings already are - same with raster image data.
    • Fine-grained permissions system - Already have this with external references - The proposed system gives you granularity to the line level (which is probably extreme) - Any inserted block that you would want permissions on may already be an XREF anyway and could have permissions control.
    • Platform-independent data - Any plaintext version or database backend could be this way.
    • Object-oriented data - Existing CAD systems already are - to the extent that you use the object oriented nature of blocks.

    I am not writing this to discourage the use of the proposed system - it is a very well thought out and useful system and I find it intriguing and kind of cool. But I am suggesting that the features it offers can already be found in many of the existing CAD file formats. I would consider this "just another CAD format," or maybe "just a better-than-most CAD format." It is a good one, but any CAD program will operate independent of the file format. Features of the format are just gravy.

    my @a=qw(random brilliant braindead); print $a[rand(@a)];

      CAD on Linux

      Anticipation of the benefits of perl6 prompts me to speculate on the future of CAD on linux.

      I agree with you that this is a "better-than-most CAD format" but disagree on the "just another" part.

      With some nurturing, this project that now discusses the format of open source CAD objects may actually become the next competitor to now closed-source and highly commercial software in a similar fashion to the GIMP and Mozilla (Firefox.) Considerable interest is growing for CAD on Linux and I predict the outcome to be impressive.

      Open Discussion

      Bruno has stated that the discussion has resolved to use YAML for the internal file format. He is now planning the extension of Draft to include revisions now being discussed at the cad-linux-dev list. In classic open source style, he asks openly for any assistance interested persons may provide. You can view the most recent discussion here.

      The first dog barks... all other dogs bark at the first dog.
        I've been using YAML for storing CAD data for a while now. I use it to store simulation and design information about electrical designs.

        Mostly YAML works but I have seen it get fooled by some of the data that I have tried to store.

        I use YAML to serialize large perl data structures into files. I will probably change from using YAML to something more reliable, at least for complex data structures. XML is the leading candidate.

        There are some very interesting ideas that would be useful for CAD in Higher Order Perl.

        I don't agree that perl 5 is unsuitable for writing CAD tools. At least one company sells a very large perl program that is a full-featured CAD tool.

        Since such a large percentage of CAD work is really data munging, it tempting to just write the whole thing in Perl.

        I have run into a fundamental problem with perl and CAD, though. Perl ruins the accuracy of floating point numbers at about 16 digits when numbers get stringified. Many things can trigger stringification, so it is difficult to prevent it from happening.

        It should work perfectly the first time! - toma
        Maybe if they just include a hook to the Eclipse shell, as an (optional) layer above the fs, they can get the versioning/collaboration "for free". IMHO, that's the only very interesting part of this problem. The rest is just the classic (yet still never quite settled) question of how best to freeze/thaw objects.

        I for one am disappointed they're using YAML. It's an ugly, non-intuitive (to my non-Pythonized eyes), and obsequiously-different format. But if they do it right, the freeze/thaw layer will be pluggable, so I could use XML, or Lisp, or whatever, as I saw fit.

Re: Open Human Readable Computer Aided Design file format
by Rhandom (Curate) on Sep 07, 2004 at 16:42 UTC
    I also checked this out some time ago. It is a great idea - but is probably only one of several solutions (and I'm sure this isn't the forum to discuss them - although it is probably better to think about them in advance). For example, it is also possible to envision a database backend where the entities are store in tables. With proper additions, any of the revision tracking is available (although branching would be difficult). I had been working on a CAD distribution a year ago that had a DB connection (sqlite in this case) as an optional backend, but have had other projects that have kept me from recent development and releases.

    In a database vs CVS vs someother format discussion there are a few issues that are useful to think about.
    • CVS is already very functional
    • Databases are already very functional
    • Various CAD formats are obviously very functional
    • CVS is open, revision tracking is easy
    • Database interaction is open, revision tracking is possible
    • Various CAD formats are usually proprietary, revision tracking is not as easy (if even possible)
    • CVS storage in this case requires one fair sized file for each entity, there is a bit of CVS overhead for checking in and maintaining drawings with thousands of lines (eventually becoming painfully slow)
    • Database storage has one line per entity, with properly indexed rows, thousands of lines vs 1 line are nearly the same access time. Storage size is limited by the database engine.
    • Various CAD formats have various benefits - some binary formats may be small, some text formats may be difficult to process, some XML formats may be huge - there are a host of trade offs.
    • CVS storage is typically easy to access from anywhere (although checkout of huge files is a pain).
    • Database storage is typically easy from anywhere (although copying files is a pain).
    • Various CAD files are typically easy to access from anywhere (maintaining concurrency between documents and updating revisions everywhere is a pain).

    So - which is the best solution? I would say, create interfaces that support them all. As for which you should use? Be wary - they all have pitfalls.

    As for the comment "perl is not the solution for long term CAD implementations." I would revise that to say Perl 5 is not the solution, Perl 6 will be a different story.

    my @a=qw(random brilliant braindead); print $a[rand(@a)];

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: CUFP [id://388575]
Approved by FoxtrotUniform
Front-paged by grinder
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (5)
As of 2015-09-02 06:15 GMT
Find Nodes?
    Voting Booth?

    My preferred temperature scale is:

    Results (63 votes), past polls