Support for Corel DRAW files in free software gets another chance
LibreOffice project started working on a new C++ library to take care of your legacy Corel DRAW files. Calligra Suite team is following closely.
Let's face it: in nearly five years UniConvertor hasn't gotten much further than reading pages, paths, fills and strokes from Corel DRAW files. Whatever reasons the sK1 team has, we haven't seen a lot of progress in a long time there.
Last year truly yours re-lab team did some more reverse-engineering of CDR files again, while moving the CDR parser to OLE Toy — an in-house tool that we earlier created for peeking inside various binary files.
The new information we discovered wasn't put to any real use which was somewhat discouraging. However in late November Fridrich Strba of LibreOffice fame came to aid and wrote some initial code for the a library to read CDR files.
Active work on libcdr started only last week, yet the first version of the library was released yesterday with a very basic support for CDR files.
What's in the library
Much like libvisio, the new library provides a parser and a basic converter to SVG that saves SVG images embedded to XHTML documents. If it finds multiple pages (which Corel DRAW supports), it will save them one after another in the same XHTML document.
Currently the library reads only v7-v13 files and converts basic shapes such as paths, rectangles, ellipses, “pies” and elliptical arcs along with some color fills. Polygons are a tricky part, but we are working on deciphering them. Strokes are a work in progress as well, but basic support is there already.
Some bugs such as reading page size and rectangle orientation were fixed in Git after the release of libcdr 0.0.1. So here is an advice: if you are willing to follow development of libcdr, pull the source code from Git.
The hard part
First of all, let's get it straight from ground up: there will be certain limits to what you will be able to transfer. E.g. neither OpenDocument nor SVG have rectangles with arbitrary rounded corners.
So what cdr2xhtml currently does is creating a Bezier path out of such a rectangle.
For just displaying legacy clipart this should be sufficient.
Another question is, of course, what's going to happen to CMYK and spot color values. OpenDocument has a notion of CMYK color values, but you can only find it in UI for fills of objects. So Fridrich will probably have to implement a CMYK to RGB converter in the library. Currently it is an open question.
As for SVG, it supports CMYK only via the icc-color workaround which is actually quite OK, because Corel DRAW seems to do a similar thing (it even embeds color profiles to CDR files). And upcoming SVG2 is going to have uncalibrated device colors so you'll be able to just use raw CMYK values.
In other words, it looks like libcdr should just read whatever it can and let end-user software decide which parts of API to use and how to treat various elements.
The plan is that Fridrich will do some more PR for the project at FOSDEM this weekend and is going to keep writing code regardless. Meanwhile re-lab team will keep assisting with reverse-engineering.
How to fetch, build and use
The procedure is pretty much like the one for libvisio. For details please have a look at the end of the Visio/LibreOffice story where it's explained in details.
Essentially, you just fetch the code from Git:
$ git clone git://anongit.freedesktop.org/libreoffice/libcdr
$ ./autogen.sh && ./configure && make && sudo make install
And use the converter:
$ cdr2xhtml file.cdr > file.xhtml
Then use a text editor of your choice to cut embedded SVG documents to standalone files.
As usual, expect updates.
But hey! Calligra Suite?
Yes, Friedrich Kossebau, a contributor to Calligra Suite, is working on his very own CDR importer for Karbon. He implemented a RIFF parser for Qt and wrote an importer for CDR files on top of it.
As you can see, importing paths works right now. Libkoralle, the library for parsing RIFF data, is publicly available too. Three projects for just extracting useful data from one file format is probably a bit too much, but let's see how things work out in the end.