Re: [Inkscape-user] PDF Support in Inkscape
----- Forwarded message from Bryce Harrington <bryce@...961...> -----
Date: Thu, 1 Dec 2005 18:24:51 -0800 From: Bryce Harrington <bryce@...961...> To: inkscape-user@lists.sourceforge.net Subject: Re: [Inkscape-user] PDF Support in Inkscape
Hi all,
Great feedback, thanks! And I got a possible solution to this problem that we could implement right now.
I took the opportunity here at the desktop architect's meeting to grab Carl Worth and present the problem to him, to get a direct from the horse's mouth on Cairo's PDF. I mentioned that we'd heard that Cairo's PDF export wasn't good, and asked for the skinny on that.
Here's the gist. Cairo's original mission was for screen and print perfect PDF, so what you see on the screen is what you get on the printer. Originally this was done by just creating a bitmap snapshot and embedding it in the PDF. This *looked* great, but of course is a heavyhanded solution.
Later, someone created a new PDF backend for Cairo, but when they got ready to release 1.0 they saw that it was woefully inadequate, so Cairo 1.0 wasn't able to meet its PDF export capabilities. However, Carl says that actually has been their number one area of focus for the next release. This release is scheduled for Dec 15. He recommends we withhold making conclusions about Cairo's PDF until that release.
Also, I asked about some sort of pluggable cairo-based svg-to-pdf converter, and this immediately clicked! He'd written a svg2pdf tool based on (an old) librsvg that does this. This is in the Cairo tree, and my guess is that this is something we could wrap up with an extension and immediately use. Perhaps the inkscape developers who are conversant with Cairo stuff could briefly mind meld with those who do extensions, and we can have Cairo-based PDF export in a matter of days.
However, there are some caveats. In theory, this should work on Windows, but Carl's never tested it. So some of our Windows (and OSX) Inkscapers might want to put some time into this, too. I know PDF export is probably *most* important for users on non-Linux platforms so this testing is absolutely critical for y'all.
Second, Carl says he's not providing any support for the libsvg module that this tool depends on, and in fact it's missing some features - filters, markers, transparency, etc. that we're definitely going to need. Thus, I think if we are going to invest time and/or money anywhere, this is the spot to do it. I'm not sure exactly what form that'd take - would we migrate code from inkscape into libsvg? Or the reverse? Would we collaborate with the librsvg people? Would we take over maintainership of libsvg? What do you guys think? Are we as a project interested in handling maintainership of libsvg?
Regarding Google Summer of Code, I heard that they're also planning a Winter Summer of Code and/or a follow up next summer, but haven't heard confirmation. Also, even if they do, there's no guarantee Inkscape would again be accepted as a project... Also, I think the work may be more than one college kid could handle. ;-) So, I think we need to not count on Google for this one; if we do get in again, I think we'd want to divvy out the work in smaller chunks anyway, so even best case it wouldn't give us a total solution.
Someone asked about the check from this last time... Yep, it just arrived via FedEx on Tuesday. :-) Early on we'd thought it might be good to put this towards some sort of sponsorship, so certainly adding it to the pool for a PDF solution is a possibility, if there's a strong enough concensus to use it for that.
Btw, Dan Kegel is taking really good, thorough notes on the meeting; Kees and I were sitting next to him and admiring his good note taking. :-) http://kegel.com/osdl/da05.html
Also it's kinda cool, Kees and I have had several people come up and say "Thank you so much for Inkscape!" One person said the thing they liked the most was how prolific, friendly, and strong our community was. :-)
A couple other notes of relevance to Inkscape... There's something called RUDI that is getting a lot of discussion as a solution to better desktop integration - sounds pretty cool. The C++ ABI breakage has gotten a lot of discussion; Kegel says the gcc devs have committed to stabilizing their ABI so these problems may diminish. There's a strong feeling that there should be a stable package of GNOME/etc. libs for Windows, so each ISV/project doesn't have to statically link and ship their own copies. Carl and Mike Shaffer of Mozilla were discussing a lot about Cairo performance; sounds like there's much work going on in that area. John Waugh of Ubuntu told me about something called 'Dogtail' that sounds like it's a powerful way to do testing, and suggested we use that for Inkscape.
An idea occurred to me - some of the exercises we're doing here with pens and cards seem like they'd work *much* better on top of Inkboard. I think it would be useful to record an inkboard session and then create 50+ simulated sessions all talking to the same document, and fix whatever breaks. Inkscape could totally rule as a conference collaboration tool.
Bryce
On Thu, Dec 01, 2005 at 12:32:01AM -0700, Michael Moore wrote:
I've been noticing a LOT of requests for PDF/PS support in Inkscape. Either export or import or both.
Over the past year or so, I've been fishing around for a volunteer to implement this. But unfortunately I'm coming up dry. Ain't no one I can find with an itch to implement this, not on a volunteer basis anyway.
Can you all tell me what you think?
----- End forwarded message -----
I really, really hope that the line about GCC breaking the C++ ABI again in 4.2 is wrong. How can anybody ever take them credibly if they break their promises not once, not twice, but three times?
It looks increasingly likely that a stable C++ ABI will never happen. Combined with the lack of proper ELF scoping at the symbol level, this makes using C++ in any form on Linux, even like how Inkscape does it, fundamentally unreliable.
On Fri, 02 Dec 2005 19:29:22 +0000, Mike Hearn wrote:
this makes using C++ in any form on Linux, even like how Inkscape does it, fundamentally unreliable.
To be more specific, it will always result in un-debuggable/unsolvable crashes in certain situations unless somebody forks the dynamic linker and/or the ELF specification which I don't anticipate happening anytime soon.
On Fri, Dec 02, 2005 at 07:29:22PM +0000, Mike Hearn wrote:
I really, really hope that the line about GCC breaking the C++ ABI again in 4.2 is wrong. How can anybody ever take them credibly if they break their promises not once, not twice, but three times?
It looks increasingly likely that a stable C++ ABI will never happen. Combined with the lack of proper ELF scoping at the symbol level, this makes using C++ in any form on Linux, even like how Inkscape does it, fundamentally unreliable.
This came up in the Desktop Architects' Meeting. Dan Kegel insisted that the gcc folks have made a firm promise not to break the C++ ABI any more. He sounded pretty confident about this, and he seems to be a the sort of guy you can take at his word. I guess we'll see, but this gave me some confidence about it.
Btw, there was also a LOT of talk about other library ABI stabilization (e.g., Gtk) and some mentions of developing better discipline at not breaking them.
Oh, and also Autopackage came up several times. Mike, you should join the desktop architect's list (at lists.osdl.org) and outline some of your plans. Also, I am noticing the Flik people are pushing to have their technology adopted, so I suspect some fair evaluation of Autopackage vs. Flik may be well received there.
Bryce
On Sat, 2005-12-03 at 14:25 -0800, Bryce Harrington wrote:
On Fri, Dec 02, 2005 at 07:29:22PM +0000, Mike Hearn wrote:
I really, really hope that the line about GCC breaking the C++ ABI again in 4.2 is wrong. How can anybody ever take them credibly if they break their promises not once, not twice, but three times?
It looks increasingly likely that a stable C++ ABI will never happen. Combined with the lack of proper ELF scoping at the symbol level, this makes using C++ in any form on Linux, even like how Inkscape does it, fundamentally unreliable.
This came up in the Desktop Architects' Meeting. Dan Kegel insisted that the gcc folks have made a firm promise not to break the C++ ABI any more. He sounded pretty confident about this, and he seems to be a the sort of guy you can take at his word. I guess we'll see, but this gave me some confidence about it.
If Dan Kegel said so, I'd also be inclined to believe it. He's also done a lot of work with GCC. Perhaps that is also because I want to believe that the GCC folks wouldn't screw us again by changing the ABI :) The GNOME folks have committed to ABI stability, I guess this might be a limitation in getting any of the -mm packages in mainline GNOME.
--Ted
participants (4)
-
Bryce Harrington -
Corey Burger -
Mike Hearn -
Ted Gould