RE: [Inkscape-devel] Re: vectorsection vs native PDF?
These are a few reasons why, from the outside, I think it makes sense for Inkscape to adopt UberConverter (UC) and not to 'hard-wire' each new filter, such as PDF export, directly into Inkscape.
* If you write ONE filter to talk to uber-converter then you get ALL file types it supports. * Each new filter type that's added to UberConverter, Inkscape will be able to use with NO additional work * Each new filter type that UC supports benefits at least two open source projects, and possibly more. So immediately it avoids re-inventing the wheel and duplicating effort (surely one of the core principles of FOSS) * Developers can write new import / export filters without having to know anything about the internal code of Inkscape or Xara. It's thus, hopefully, considerably easier to write new filters for Inkscape and Xara.
In a nutshell UC works by having one master 'uber-format' that's a superset, as much as possible, of all common vector standards. This is the hub-format. You write one filter to convert to and from that format. UC then has lots of separate independent plug-in filters to convert to and from this hub format. So now if you add say, a DXF converter into the hub, all others types can be converted to and from DXF. The goal is to have, as much as possible, a lossless conversion between types and to retain important meta information such as group structure.
No other platform has an agreed open standard for vector conversion (commercial considerations make it difficult to imagine), but the benefit to the FOSS platform of having one solution for all products wanting vector conversion seems to be very considerable.
And finally, we (Xara and Inkscape) have spoken about ways to cooperate, to avoid competing, and it seems this is a classic example where with a little planning we can do just that: cooperate, not compete. We all have limited developer resources and so immediately the benefits of our two projects pooling to solve the same problem once strikes me as a huge gain. And if a third project, say Scribus, started to use UC, then for each filter, or even each little minor improvement, three major projects get the immediate benefit. A 300% return on your developer investment.
We both require PDF export. Recently there's been discussion about ODG support and EMF/WMF. These are important vector standard file formats. It would obviously benefit both our projects to have EPS support, CorelDRAW CDR and CMX support, Adobe Illustrator - I could go on. Let's solve the problem once.
Now having said that it's early days for UC. It's a mostly a plan, not a fully functioning reality. But right now we're putting a lot of effort into integrating UC into XaraLX, and we hope within a few weeks to have this working and demonstrating the first UC filter (Xar <-> SVG). And yes this means if you guys integrate this you get the ability to read and write our .xar files.
So I think Eric's project deserves Inkscape's support. It even seems a good candidate for SoC support since it's an independent project that directly benefits multiple other projects.
Charles
-----Original Message----- From: inkscape-devel-admin@lists.sourceforge.net [mailto:inkscape-devel-admin@lists.sourceforge.net] On Behalf Of Eric Wilhelm Sent: 26 April 2006 22:59 To: inkscape-devel@lists.sourceforge.net Cc: bulia byak Subject: [Inkscape-devel] Re: vectorsection vs native PDF?
# from bulia byak # on Friday 14 April 2006 05:53 pm:
- Implement
http://wiki.inkscape.org/wiki/index.php/Required_PDF_Support (I know
of UberConverter, but PDF is the most important interchange
format so
we should better support it natively)
bulia, can you explain why this needs to be native? Short of animation and the exact placement of things like transforms in the DOM (if pdf would even allow that) the Chromista hub should express enough of the SVG structure to round-trip PDF conversions as well as anything native.
If it gets implemented natively in inkscape, I would just use that as a hub attached to chromista to get things like xar -> pdf, but going through svg is going to be lossy from that perspective.
Thanks, Eric -- Peer's Law: The solution to the problem changes the problem.
http://scratchcomputing.com
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057& dat=121642 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I agree with everything Charles said, and I was not trying to say we need internal PDF support _instead of_ UC, but rather _in addition_ to it. Here are a few very practical reasons why:
- My expericence shows that even in the best commercial products, vector import/export is ridiculously inadequate. Quirks and errors are the norm, not exception. Therefore it's always good to have an alternative route.
- PDF is not just "a" vector format. It's the closest we have to the most common denominator. Its support is critical for interoperability.
- UC requires not only Perl, but lots of Perl modules. For example, even on my Linux machine I still cannot run it because CPAN errors out when trying to install the needed stuff. So for UC to be usable, especially on Windows, we need to carry all this stuff packaged with Inkscape. I'm not saying it's impossible or even undesirable, but this requires quite some effort from packagers (see e.g the "extensions on Windows" saga, still not finished).
- Bob will confirm, having recently worked on ODG export, that having access to the internals of Inkscape is a big help for an export format coder. Again, I don't want to say that we must force everyone to learn Inkscape in order to write support for some format, and this is where UC has a rightful place. But, again, PDF is special and deserves all help we can give it.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
- Bob will confirm, having recently worked on ODG export, that having
access to the internals of Inkscape is a big help for an export format coder.
Perhaps we should look at writing output directly to VectorSection hubs.
Aaron Spike
# from Aaron and Sarah Spike # on Thursday 27 April 2006 08:34 am:
bulia byak wrote:
- Bob will confirm, having recently worked on ODG export, that
having
access to the internals of Inkscape is a big help for an export format coder.
Perhaps we should look at writing output directly to VectorSection hubs.
Now you're talking! Actually, I considered using the inkscape guts for svg2crs/crs2svg, but didn't see a very clear path there. I think there was some discussion about making a library of it last summer, but I think the decision was that it isn't going to happen any time soon.
--Eric
# from bulia byak # on Thursday 27 April 2006 08:22 am:
I agree with everything Charles said, and I was not trying to say we need internal PDF support _instead of_ UC, but rather _in addition_ to it. Here are a few very practical reasons why:
As I said, I don't plan to stand in the way. If inkscape beats vx to pdf, it just becomes another hop to get there. Big dependency for an svg2pdf converter, but ram, disk, and network are cheaper than coding hours, so it's a fairly pragmatic shortcut. This is of course looking at it from the perspective of a system that wouldn't otherwise have inkscape installed (say, a CAD workstation.)
- My expericence shows that even in the best commercial products,
vector import/export is ridiculously inadequate. Quirks and errors are the norm, not exception. Therefore it's always good to have an alternative route.
- PDF is not just "a" vector format. It's the closest we have to the
most common denominator. Its support is critical for interoperability.
I would like to know of any hard technical reasons why this cannot work via VX. I really do want Chromista to be a superset of svg,xar,ps and pdf, so if something is glaringly missing, I would like to hear it.
- UC requires not only Perl, but lots of Perl modules. For example,
even on my Linux machine I still cannot run it because CPAN errors out when trying to install the needed stuff. So for UC to be usable, especially on Windows, we need to carry all this stuff packaged with
Please send me the error? OS/dist? perl --version ? I would be thrilled to help you fix it and maybe figure out how to avoid this on other systems.
Perl is really very cross-platform. CPAN has been around for over 10 years now and while CPAN.pm has some (internal) warts, it "Just Works" 99% of the time.
I had hoped that the copy/paste install instructions would do the trick. I've only got a limited number of machines to smoke test on. As for windows, it is certainly possible to create a binary package with a frozen perl version and everything else.
--Eric
On Thu, Apr 27, 2006 at 09:30:54AM -0700, Eric Wilhelm wrote:
- UC requires not only Perl, but lots of Perl modules. For example,
even on my Linux machine I still cannot run it because CPAN errors out when trying to install the needed stuff. So for UC to be usable, especially on Windows, we need to carry all this stuff packaged with
Please send me the error? OS/dist? perl --version ? I would be thrilled to help you fix it and maybe figure out how to avoid this on other systems.
Perl is really very cross-platform. CPAN has been around for over 10 years now and while CPAN.pm has some (internal) warts, it "Just Works" 99% of the time.
I'll point out that we had many similar sorts of issues with the python extensions. Folks had the motivation to get those smoothed out in order to use Inkscape extensions, and so it's working reasonably well now.
Many of the issues sound to be the normal issues that come with any new code; once there are enough people using it, things will get smoothed out.
Also, be aware that with Perl there are a lot of other kinds of ways to package modules. CPAN is generally considered the most convenient, but it's also possible to create and distribute "Bundles", or even "install" the modules into the package tree before tarballing and install them as part of the inkscape installation process.
Anyway, like Eric mentioned, Perl's been around on Windows for a long time, and the installation/packaging/portability techniques are well established.
I had hoped that the copy/paste install instructions would do the trick. I've only got a limited number of machines to smoke test on. As for windows, it is certainly possible to create a binary package with a frozen perl version and everything else.
Hmm, frozen binary packages sounds like overkill in this case. Do you rely on any C Perl modules?
Bryce
# from Bryce Harrington # on Thursday 27 April 2006 10:20 am:
Hmm, frozen binary packages sounds like overkill in this case.
Yeah, but a dead dragon is still dead. Doesn't matter how you slay it.
Do you rely on any C Perl modules?
The XML modules can be C for better speed. The XAR code may ultimately end up with some C in it.
My point is mainly that it is much easier to just ship a frozen binary if it reduces the installation complexity. Given the choice between a long download and anything involving a shell, most windows users will let the modem do the hard work.
--Eric
On Thu, Apr 27, 2006 at 10:44:39AM -0700, Eric Wilhelm wrote:
# from Bryce Harrington # on Thursday 27 April 2006 10:20 am:
Hmm, frozen binary packages sounds like overkill in this case.
Yeah, but a dead dragon is still dead. Doesn't matter how you slay it.
Sure, but I think the difficulty in this case may be higher - or at least, when I've tried it myself I got stuck on various issues. But that was Linux, not Windows. Anyway, if you've done it before and have the process down, and are confident it can be done easily, then yeah, it could be the best approach.
Do you rely on any C Perl modules?
The XML modules can be C for better speed. The XAR code may ultimately end up with some C in it.
My point is mainly that it is much easier to just ship a frozen binary if it reduces the installation complexity. Given the choice between a long download and anything involving a shell, most windows users will let the modem do the hard work.
Yeah, well I guess the good news is that there's a few options. Shipping as binary would be a nice advancement; it'd eliminate whole classes of potential incompatibility bugs, and make the converters work even on Windows machines where Perl isn't installed. So that's worth trying first; if it doesn't work, there's other possible solutions (with different sets of trade-offs).
Bryce
I would like to know of any hard technical reasons why this cannot work via VX. I really do want Chromista to be a superset of svg,xar,ps and pdf, so if something is glaringly missing, I would like to hear it.
Postscript (ps) is a Turing complete programming langauge, not sure you have a superset of that. :)
participants (6)
-
Aaron and Sarah Spike -
Alan Horkan -
Bryce Harrington -
bulia byak -
Charles Moir -
Eric Wilhelm