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.