On Thu, Feb 23, 2012 at 4:48 PM, Alexandre Prokoudine < alexandre.prokoudine@...400...> wrote:
Thus far support for some file formats via UC was a low-hanging fruit. However the project isn't progressing (http://bit.ly/pRwyJV) in a way that would provide us an increasingly good support for some of them, especially CDR. Yet users keep complaining (and rightfully so).
Last year we (re-lab) started working with LibreOffice team. The first project we did together was reading binary Visio files which resulted in libvisio (http://bit.ly/rh0TGd) that's now available to everyone with release of LibreOffice 3.5 a week ago.
Then we started working on CDR (again), and now there is libcdr available (http://bit.ly/zJFr7l). With release of v0.0.3 the library is now feature-wise on par with UniConvertor and even surpasses it in terms of supported objects, properties and a certain part of API that is of interest for us.
Ok. Let's compare translation result on well-known file. May be you remember sK1 Project presentation on LGM2007 . We have used terra.cdr file to demonstrate CDR parser abilities:
http://sk1project.org/files/terra.cdr
The file is a complex CDR file, not a special testing sample. Latest libcdr snapshot gives following output in Inkscape:
http://sk1project.org/files/terra-libcdr.png
Whereas UniConvertor 1.1.5 produces slightly better result:
http://sk1project.org/files/terra-uc.png
As you can see on libcdr output some objects are absent, some artifacts are observed and there is no correct color management. Also libcdr skips all structural elements: groups, layers etc. So import result is not so perfect and requires a lot of manual fixing. Therefore saying "feature-wise on par with UniConvertor" is just slightly exaggerated. Even comparing latest libcdr with 1.5 years old UniConvertor release. Moreover terra.cdr is not a most complex file. This drawing contains almost curves only.
libcdr/relab teams have done a good job porting UniConvertor code for LibreOffice and even some minor features have been improved (like rounded rectangles). But this is a simplest translation level.
To achieve more advanced features we have started deep sK1 Project refactoring. As I see in source code the libcdr reproduces similar architecture like in UniConvertor 1.x importer. So I could suppose the same development issues for next iterations of libcdr which we are resolving now.
I'm talking about API that allows building previews of pages and importing just the pages that the user needs (something like what we have in the PDF/PS importer).
Cairo rendering have been implemented for UniConvertor 2.0 So import preview is a resolved feature for all supported format including CMX/CCX/CDRX which are main Corel clipart formats.
Pages used to be one of the selling points for Corel DRAW, since Adobe Illustrator got its artboards only in CS4. So no wonder that there's quite a lot of legacy CDR files around that have multiple pages. And we cannot sensibly read those.
Multipage import issue is not a problem for UniConvertor 1.1.5 and in 2.0 version we are going to improve multipage importing API providing different ways for end users:
- tiling pages on single page - paging import - splitting pages on different files
Summing up all the issues I would propose to compare actual libcdr and UniConvertor 2.0 on LGM2012 and after that to choice the best result for Inkscape end users. Btw now we are working for export into CDR format and it seems this feature will be useful for SVG application in prepress.