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 :)