LibreDWG revived, starts getting regular releases
In an unimaginable turn of events, LibreDWG, the free/libre library for opening proprietary CAD files in the DWG file format, is becoming a stellar example of a FOSS project.
Where we left off
Back in 2012, when we last covered the project, LibreDWG was in a rough state. After FSF declined the request of the library’s developers (who forked it from LibDWG) to downgrade the license from GPLv3+ to GPLv2+ and thus make it compatible to LibreCAD and FreeCAD, it all went south.
The original team abandoned it, a few GSoC students tried to get this project to work again, but they too eventually shifted their interest elsewhere (one became a regular LibreCAD contributor).
Eventually, LibreCAD started their own libdxfrw library with DWG reading support (now also used at the very least by SolveSpace). FreeCAD went for proprietary Teigha, and Blender still has no solution for opening DWG files, let alone exporting those.
So until fairly recently, there were pretty much no developers, not much progress, and not even a single public release. At some point, Felipe Castro, developer of the original LibDWG library, even forked it back from LibreDWG to add support for more entities, as well as for R2004, R2010, and R2013 files, and make a few releases, then admitted the game was over.
What’s changed
While we might have to wait for end-user software other than GRASS, Archimedes, and PythonCAD to start using LibreDWG (or take matters into our own hands, all limitations of GPLv3+ considered), the project’s own pace has dramatically increased with the arrival of Reini Urban in late 2017.
Reini cleaned up the code base, added support for many new entities and half a dozen of convertors from DWG to other file formats such as DXF, BMP, PS, and SVG. The library can now read most R13-R2018 DWG files and write R2000 DWG files.
Two weeks ago, he made the second public release of the library (v0.6) featuring bugfixes, API changes, GNU Parallel support, basic support for more types of objects, and the parsing of ACIS version 2 (3D data).
Reini kindly agreed answering a few questions from LGW.
The interview
To an outsider, LibreDWG could look a bit like a lost cause, while libdxfrw might be considered a better candidate for spending one’s time. That is, before you came. And yet you picked it up and started improving it and got it to a releasable state. Why?
Because there is still no acceptable free solution out there, which is terribly needed. libdxfrw is good at supporting all versions and DXF, but not more. You cannot write DWG, there is not much support for all the new entities and classes. E.g. SolveSpace needs both parametric constraints and BIM — the two most important technologies in modern CAD. Only Teigha offers these, but Theiga is non-free, and I’m annoyed by that. Everybody should. Their spec is also full of small annoying bugs. We really need to collaborate to get rid of those.
Yes, but LibreDWG wasn’t much different in terms of entities support from libdxfrw when you started? Or am I under a wrong impression?
No, I’ve added support for much more objects and entities that are in libdxfrw, and will add more. I’m working on some reverse engineering solver, examples/unknown, for the possible combinations of data fields with some modern prolog/solver system picat.
People don’t usually work on a library unless they need it for another, higher-level project. Do you have one?
No, not all. I took it, because I’m good at this low-level stuff and had time available. I also liked the structure of the library, I like good code. I was also the first to work with Frans Faase to decode the early DWG formats and created many useful tools with it.
Do you have any use for CAD in your daily work or maybe hobbies?
Not anymore. That was 20 years ago. Nowadays I’m mostly writing compilers and languages for completely other fields.
Okay! Now that you mention BIM, do you think a dwg2ifc converter (at least IFC2x3) would be feasible within LibreDWG?
I haven’t looked at that yet, sorry. But adding support for more output modules is easy, for input modules not so.
IFC support would be important for BIM support, I guess. I was more looking into OpenStreetMap and GIS lately.
How much better is the DWG reading support than the DWG writing support?
Reading is supported for all versions, writing so far only for r2000. There’s much more work to do for writing newer sections, compression, CRC, and Reed-Solomon.
But more important than write support for newer versions is support for more entities and classes. Especially MATERIAL and TABLE for BIM, parametric constraints for advanced modeling, and the ACIS 2 format for 3D data. I’m making great progress with examples/unknown to decode those unknowns.
AutoCAD can easily read r2000 DWGs with these new entities, so write support is good enough for a while.
Wait, my understanding from reading the reverse-engineered spec was that 3D ACIS data was encrypted.
ACIS 1 yes. ACIS version 2, i.e. Autodesk’s variant of ACIS 7.1 named ShapeManager is stored differently, in the unencrypted binary SAB format. I added decoding to ACIS version 2, the binary SAB format, for the 0.6 release with the help of the new examples/unknown tool. Maybe a converter from binary to ASCII SAT version 2 later will be added, but this can be also some other library. The SAB format comes with full precision, ASCII only with half, and precision is a big problem in 3D data, esp. thin hulls.
Currently, the project has bus factor one. If you were to point out specific areas to work on for interested contributors, what would those be?
Well, I’m not a friend of the bus factor analogy at all. In fact the best run projects either have a bus factor of 0 or 1. As soon as the bus factor increases >5, the quality of the project decreases dramatically, as seen with Python, Perl, Ruby, C++, GNOME, … Only Java, Swift, JavaScript and C# are run properly, but in a commercial environment. The best projects are usually run by 1-2 people max.
I got great contributions by users who came up with broken DWG’s, problems in the library. Also real world use cases from GIS users showed that I had to optimize data structures. A change from linear search to a hash table improved read-time from minutes to 7 seconds. Also omitting free() got 2 minutes destruction time down to 2 seconds when used in a binary. As library one unfortunately cannot leak memory, but as binary you need to, as long as the libc malloc() performs so badly.
LibreDWG is a very good malloc stress test, with tons of fragmentation. It’s much worse than a stop-the-world garbage collection on a very slow GC. I even got code fixes from contributors in several areas, but it’s a tricky library, so I don’t expect much. Best is coming up with broken DWG’s.
But even better would be a change of mind about licensing, as the GPLv3 is really the best license around currently, an improvement over the APGL. SolveSpace has an iOS app, which apparently prohibits the use of the GPLv3 libredwg. LibreCAD and FreeCAD are free to switch now, but they got the OpenDWG Teigha library already with a trick, and Teigha is still better than LibreDWG.
Best would be a cooperation with the Russians working on Teigha. I’ve found and fixed so many bugs in their spec already, and LibreDWG doesn’t harm their business model at all. And I love working with Russians.