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