[cad-linux] Re: An open CAD file format

  • From: Bakul Shah <bakul@xxxxxxxxxxxxx>
  • To: cad-linux@xxxxxxxxxxxxx
  • Date: Sun, 07 Sep 2003 00:59:09 -0700

At least until the development of an open CAD program gets to
a self-sustaining stage I'd use s-expressions to represent
data.  Here is a somewhat restricted definition:

  An s-expr is a list of atoms or s-exprs where the first
  element of the list defines the meaning of the whole
  s-expr.  An atom is a number, string or symbol.  An s-expr
  is written by enclosing its elements in parentheses.

S-exprs are reasonably human readable and very easy to parse
-- under 300 lines of C/C++ code will parse it all.  A single
sexpr_read() will let you slurp in a multigigabyte design
file (limited only by virtual memory)!

Since this is a simple structural representation, one can
easily map it to a bunch of different formats (for example,
from the same s-exprs I have generated nice block diagrams,
C/C++ data structures, a list of offsets, routines for
packing/unpacking them for I/O etc.).

It is also a fairly neutral format that will keep your
options open should you decide to move to a different format
in future.  You can also convert from other fromat such DWG
into s-expr as well without any loss of information.

Another useful feature of s-exprs is that you can *add*
attributes to existing objects -- it is a naturally
extensible format.  You can also remove or ignore attributes
when writing functions that operate on them.

A common format such as s-exprs can buy you a lot of reuse.
For example, you can write a tree traversal function that
extracts only the geometry information and it should work for
any compound object.  Generic functions for various tree
surgery or transformation can be extremely useful in all
sorts of places.  One friend wrote a simple schematic editor
that does rendering, keyboard/mouse input, 2d transforms,
draw lines and text, rubberbanding, grouping of objects,
hierarchical drawings, adding of arbitrary attributes,
arbitrary undo/redo etc.  All of this in under 1000 lines of
Scheme code thanks to code reuse.

A low level common format such as s-expr is a minimum
requirement but you'd also need to worry about and agree on
higher level concepts.  At some level these concepts and
objects will end up being very application specific....

If anyone wants to pursue this further, you can have my
s-expr parser.

-- bakul

Other related posts: