Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Re: Open Human Readable Computer Aided Design file format

by Rhandom (Curate)
on Sep 07, 2004 at 20:12 UTC ( #389197=note: print w/replies, xml ) Need Help??

in reply to Open Human Readable Computer Aided Design file format

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)];
  • Comment on Re: Open Human Readable Computer Aided Design file format

Replies are listed 'Best First'.
Re^2: Open Human Readable Computer Aided Design file format
by SciDude (Friar) on Sep 07, 2004 at 23:40 UTC

    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.

        The beauty of using YAML is that it works well with simple shell tools like grep and also diff's well because a change of one property involves a change of one line. XML is too often stored without linebreaks, not to mention what happens when you add linebreaks and then diff that.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://389197]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (7)
As of 2018-05-28 08:56 GMT
Find Nodes?
    Voting Booth?