Gradually replacing UniConvertor + refactoring
Hi,
Speaking of refactoring, I think it's time we consider replacing some of our UniConvertor-based importers. The one I particularly have in mind is CDR.
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. 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).
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.
The very same API was added to libvisio.
So what I'm wondering about is whether we can abstract part of the importing preview dialog and rebuild existing importers around it: redo both PDF/PS/EPS (probably little work), use libcdr instead of UC, add Visio importer (libvisio). If we ever go for Assimp for importing 3D projections of 3D files, that would come in handy too.
It would probably also make sense adding a possibility to import pages as either layers or new documents (the way GIMP does it for e,g, PDF).
What do you think?
P.S. As for libcdr and libvisio, both are well maintained project (as they are part of LibreOffice). Currently we are working on support for gradients and text in CDR (both missing in UniConvertor). If anyone's interested, it's best to fetch code from Git, as it's moving forward very fast.
$ git clone git://anongit.freedesktop.org/libreoffice/libcdr
Alexandre Prokoudine http://libregraphicsworld.org
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.
On Fri, Feb 24, 2012 at 3:02 AM, Igor Novikov wrote:
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.
Fixing support for groups and layers it is nothing special. We've been making such changes on a daily basis. You've got to provide a more essential reason to stick to UC such a being able to maintain the project :)
libcdr/relab teams have done a good job porting UniConvertor code for LibreOffice
Wrong :) We haven't touched UniConvertor code. libcdr is written from scratch and inherits project's structure from libvisio. Could you please start checking facts before making bold statements?
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.
Yes, I believe you could suppose that :)
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.
If it doesn't exist in a public SVN, then it doesn't exist at all :) Personally, I'm not interested in wonderful plans. I'd like some real code, thank you.
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.
Fine with me.
Alexandre Prokoudine http://libregraphicsworld.org
On Fri, Feb 24, 2012 at 1:23 AM, Alexandre Prokoudine < alexandre.prokoudine@...400...> wrote:
On Fri, Feb 24, 2012 at 3:02 AM, Igor Novikov wrote:
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.
Fixing support for groups and layers it is nothing special. We've been making such changes on a daily basis. You've got to provide a more essential reason to stick to UC such a being able to maintain the project :)
There is a good rule in programming to replace components on better one but not inferior to the capabilities of. The sample above demonstrates that libcdr is not feature-wise on par with UniConvertor 1.1.5
Concerning libcdr maintaining it would be great to fix libcdr and libwpg compatibility because libwpg trunk changes break libcdr build.
libcdr/relab teams have done a good job porting UniConvertor code for LibreOffice
Wrong :) We haven't touched UniConvertor code. libcdr is written from scratch and inherits project's structure from libvisio. Could you please start checking facts before making bold statements?
I wrote "porting" but not "copy-pasting". I think it is not a simple issue to use Python code in C++ library. But libcdr was created using oletoy which contains code portions from CDR Explorer/UC.
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.
Yes, I believe you could suppose that :)
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.
If it doesn't exist in a public SVN, then it doesn't exist at all :) Personally, I'm not interested in wonderful plans. I'd like some real code, thank you.
UniConvertor 2.0 is under sponsored development. Public SVN is updated time to time in agreement with the customer paying full time coding. If you have have alternative propose how to funding this work I would be glad to hear your suggestions. Finally the code will be published under GPL v3. This is something like Ghostscript development & business model.
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.
Fine with me.
So let's compare results in Vienna :)
participants (2)
-
Alexandre Prokoudine -
Igor Novikov