[code] ruby-dxf-reader
-
Purpose
- To convert .dxf files into data which a Ruby script can use more easily.
- To factor-out the code for reading a .dxf file in order to provide a foundation for future dxf support in Ruby and SketchUp.
Summary
- Easy access to HEADER variables.
- Iterate BLOCKS and ENTITIES using Ruby iterators.
dxf2ruby reads an ASCII .dxf file and converts it to a data structure consisting of built-in Ruby objects (Hash, Array, Fixnum, Float, and String.) The top-level structure is a Ruby Hash consisting of 3 sections:
{"HEADER"=>{...}, "BLOCKS"=>[...], "ENTITIES"=>[...]}
The HEADER Section is a Ruby Hash which offers easy access to any of the .dxf's header variables.
Individual acad entities (graphical or otherwise) are represented as Ruby Hash objects, i.e a LINE entity:
{0=>"LINE", 5=>"25", 100=>["AcDbEntity", "AcDbLine"], 8=>"0", 6=>"CONTINUOUS", 62=>7, 10=>-4.672884, 20=>-0.816414, 30=>0.0, 11=>-4.672884, 21=>-0.27178, 31=>0.0}
The BLOCKS section is an Array of acad entities. the BLOCK and ENDBLK objects are preserved and it is up to the user to interpret how to manage the blocks and their entities.
The ENTITES section is an Array of acad drawing entities.
Quick Start
require 'dxf2ruby' dxf = Dxf2Ruby.parse("file.dxf") acad_version = dxf['HEADER']['$ACADVER'] dxf['ENTITIES'].each { |entity| draw(entity) } def draw(entity) case entity[0] when "POINT" draw_point(entity) when "LINE" draw_line(entity) end end # def draw_point(entity) x = entity[10] y = entity[20] z = entity[30] # ... Sketchup.active_model.entities.add_cpoint([x, y, z]) end
It is up to the user to interpret the returned objects - for example, no attempt is made by the code to interpret nested entities such as BLOCK..ENDBLK.
Dxf2RUby may also be used on a command line to view a dxf file in a more human-readable form. SketchUp is not required for this code. (This uses the ruby pretty_print gem.
$ gem install pp
)` $ dxf2ruby file.dxf | more`
-
This code now lives at ruby-dxf-reader on Bitbucket.
There are 2 branches. Branch 1.0 is a simple version which parses a .dxf into a Ruby Hash of Hashes and Arrays. This is the file posted in the previous post.
Branch 2 (in progress) does the same job - parsing .dxf files - but uses a hierarchy of classes. These classes map to DXF objects and entities and provide convenience methods for accessing group codes. The hierarchy currently looks like this:
-
-
Very cool Jim. I'll probably be digging into this script more later this summer. Excellent work!
-
FYI.. I checked Rubyforge and Rubygems to see if anyone had previously created a DXF or DWG Ruby class/module, but got no hits.
I was surprised that noone has done this before !
-
It'd be nice of it was possible to generate some documentation from the code. RDoc or Yard for instance. (I prefer Yard)
Is that something you'd also accept contributions for? -
Which reference to the DXF format do you use?
-
@thomthom said:
Which reference to the DXF format do you use?
I've been reading the latest and the oldest I could find. It appears the latest versions of the dxf file format are backwards compatible with the earliest as far as parsing the files. New entity types have been added in later versions, new codes have been used, but the algorithm for reading the file and transforming the entities into useful objects should work for all versions of dxf.
It remains to be seen if the various versions of the file format will require different methods for drawing the entities. So far in testing, the version appears not to be an issue.
@thomthom said:
It'd be nice of it was possible to generate some documentation from the code. RDoc or Yard for instance. (I prefer Yard)
Is that something you'd also accept contributions for?Absolutely. I was looking at rdoc and yard and based on syntax and features, yard is the one I was likely to go with.
@dan rathbun said:
I was surprised that noone has done this before !
Same here. There are one or two readers written in python, but nothing for Ruby.
-
Yard supports the RDoc syntax - but adds some more explicit structure to it. Been using it for TT_Lib2 and some other project now. I've found it very useful to generate a lookup resource I can use.
-
Another thing that might help collaboration is if variables got some more descriptive names other than a single character. Would make it easier to deduce the flow of the code without tracking it all the way to its root.
-
c, v = code and value throughout the code. They are the group code and value pair which are the "atoms" on which a dxf file is composed.
Dxf objects are collections of (code,value) pairs. However, some values may be a single item while others may be a list of items (implemented as an Ruby Array.)
The code also determines the type of the value; i.e. Integer, Float, or String.
In general, I agree that using more descriptive names would help understanding.
-
Ok good. Just trying to catch up to it's flow.
-
Jim, what is the licencing like on ruby-dxf-reader? In particular I'm wondering if it could be included in the code base for an open source project http://openstudio.nrel.gov/ or if it could be used in a measure (our equivalent of a plugin) on the Building Component Library https://bcl.nrel.gov/. We already support gbXML as an import option, but I'd like to support DXF as well so almost any modeling tool can be used as a starting point.
David
-
Hi David,
I put it up on GitHub.
-
Advertisement