Hi
I'm using both Inkscape 0.45.1.1 and a snap from this monday in Win32 (but with older snaps was the same).
There is a huge difference when saving in PDF files, other users reported an issue with the size of the files but the biggest difference is the quality, with 0.45.1.1 the PDF file is vectorial (~18kb) and with the snap it's a bitmap (~315kb)! BTW, the source SVG was http://en.wikipedia.org/wiki/Image:YamahaMotorCo.svg
Please note that I tried replacing the new libcairo2.dll with the older file and the result was the same.
Best regards
On 2007-October-17 , at 15:01 , Jaime Martínez-Figueroa wrote:
I'm using both Inkscape 0.45.1.1 and a snap from this monday in Win32 (but with older snaps was the same).
There is a huge difference when saving in PDF files, other users reported an issue with the size of the files but the biggest difference is the quality, with 0.45.1.1 the PDF file is vectorial (~18kb) and with the snap it's a bitmap (~315kb)! BTW, the source SVG was http://en.wikipedia.org/wiki/Image:YamahaMotorCo.svg
Please note that I tried replacing the new libcairo2.dll with the older file and the result was the same.
This is because in 0.45.1 Inkscape used its own internal PDF renderer to save as PDF while the development snapshots use Cairo. Cairo still rasterizes many things when writing its PDFs indeed and handles groups in a strange way. However, from what I've heard, the Cairo guys are working hard on the PDF part so these improvements should end up in Inkscape in the end.
However I agree that having a better functionality in the old release than in the dev builds feels strange. I have had to keep a copy of 0.45.1 at hand to export some of my PDFs which were fine in 0.45.1 but mostly rasterized by Cairo. Why should these two PDF exporters be exclusive? Couldn't we have _both_ in the dev builds? Furthermore, if Cairo does not progress on this side before 0.46, one should probably have to re-enable the internal PDF exporter and it would be good to test it a bit before release IMHO.
Could someone re-enable the old PDF exporter? Pleaaase ;)
JiHO --- http://jo.irisson.free.fr/
Yeah, that's a good way to solve this issue, include the internal PDF exporter and the Cairo PDF exporter too, for the print-monkeys it's not problem to have 2 "PDFs" in the save list (even with an "old" and "new" indicator for the newcomers).
Anyway thanx ^_^
On 10/17/07, jiho <jo.irisson@...400...> wrote:
On 2007-October-17 , at 15:01 , Jaime Martínez-Figueroa wrote:
I'm using both Inkscape 0.45.1.1 and a snap from this monday in Win32 (but with older snaps was the same).
There is a huge difference when saving in PDF files, other users reported an issue with the size of the files but the biggest difference is the quality, with 0.45.1.1 the PDF file is vectorial (~18kb) and with the snap it's a bitmap (~315kb)! BTW, the source SVG was http://en.wikipedia.org/wiki/Image:YamahaMotorCo.svg
Please note that I tried replacing the new libcairo2.dll with the older file and the result was the same.
This is because in 0.45.1 Inkscape used its own internal PDF renderer to save as PDF while the development snapshots use Cairo. Cairo still rasterizes many things when writing its PDFs indeed and handles groups in a strange way. However, from what I've heard, the Cairo guys are working hard on the PDF part so these improvements should end up in Inkscape in the end.
However I agree that having a better functionality in the old release than in the dev builds feels strange. I have had to keep a copy of 0.45.1 at hand to export some of my PDFs which were fine in 0.45.1 but mostly rasterized by Cairo. Why should these two PDF exporters be exclusive? Couldn't we have _both_ in the dev builds? Furthermore, if Cairo does not progress on this side before 0.46, one should probably have to re-enable the internal PDF exporter and it would be good to test it a bit before release IMHO.
Could someone re-enable the old PDF exporter? Pleaaase ;)
JiHO
On 10/17/07, jiho <jo.irisson@...400...> wrote:
However I agree that having a better functionality in the old release than in the dev builds feels strange. I have had to keep a copy of 0.45.1 at hand to export some of my PDFs which were fine in 0.45.1 but mostly rasterized by Cairo. Why should these two PDF exporters be exclusive? Couldn't we have _both_ in the dev builds? Furthermore, if Cairo does not progress on this side before 0.46, one should probably have to re-enable the internal PDF exporter and it would be good to test it a bit before release IMHO.
Definitely, though which exporter to ship with depends on when we release and how much progress cairo will have by then. I suggest we revisit this issue closer to our release, and if latest cairo is still not good enough by then, we'll have to reenable the old one exactly as Mental did for 0.45.
On 2007-October-17 , at 20:17 , bulia byak wrote:
On 10/17/07, jiho <jo.irisson@...400...> wrote:
However I agree that having a better functionality in the old release than in the dev builds feels strange. I have had to keep a copy of 0.45.1 at hand to export some of my PDFs which were fine in 0.45.1 but mostly rasterized by Cairo. Why should these two PDF exporters be exclusive? Couldn't we have _both_ in the dev builds? Furthermore, if Cairo does not progress on this side before 0.46, one should probably have to re-enable the internal PDF exporter and it would be good to test it a bit before release IMHO.
Definitely, though which exporter to ship with depends on when we release and how much progress cairo will have by then. I suggest we revisit this issue closer to our release, and if latest cairo is still not good enough by then, we'll have to reenable the old one exactly as Mental did for 0.45.
How hard would it be to do it now? I don't see any drawback to re- enabling it now apart from the fact that it would require someone's time to do it. If this represents little time, it would be nice to have in the current dev builds.
JiHO --- http://jo.irisson.free.fr/
On Wed, 17 Oct 2007 20:21:13 +0200, jiho wrote:
How hard would it be to do it now? I don't see any drawback to re- enabling it now apart from the fact that it would require someone's time to do it. If this represents little time, it would be nice to have in the current dev builds.
Oh, maybe I misread the thread above.
Is it not regressions in cairo itself that you're worried about but that the cairo-based PDF exporter is not as good as the old one? If so, what's the cairo-based exporter still missing? Anything we can fix in cairo itself?
Thanks,
-Carl
On Wed, 17 Oct 2007 11:35:54 -0700, Carl Worth <cworth@...573...> wrote:
Is it not regressions in cairo itself that you're worried about but that the cairo-based PDF exporter is not as good as the old one?
Correct.
If so, what's the cairo-based exporter still missing? Anything we can fix in cairo itself?
The general problem people are complaining about right now is that it the cairo-based exporter rasterizes a lot of stuff that the old exporter didn't.
I think some of the issues (e.g. proper metasurface-based groups) are fixed in cairo trunk now, but I don't know if they've hit a release yet (and even if they have, there's no guarantee that, on Linux, the users/testers have a recent enough cairo installed to benefit).
I think two things we need to do at this point are:
1. get people reporting PDF problems to include their cairo version in the report (this may be something we should display in the about dialog)
2. find someone to assemble a test suite of cases we expect PDF export not to rasterize[1]
Since Linux distributions are going to lag behind in their cairo versions, we may still have to revert the PDF export for this release cycle no matter what gets fixed at this point. :/
-mental
[1] They'd do well to build on the test suite and feature comparison that I compiled for 0.45; it lives in SVN's doc/PDF\ Feature\ Matrix.*
On Wed, 17 Oct 2007 12:22:30 -0700, MenTaLguY wrote:
On Wed, 17 Oct 2007 11:35:54 -0700, Carl Worth <cworth@...573...> wrote:
Is it not regressions in cairo itself that you're worried about but that the cairo-based PDF exporter is not as good as the old one?
Correct.
OK. Thanks for explaining.
If so, what's the cairo-based exporter still missing? Anything we can fix in cairo itself?
The general problem people are complaining about right now is that it the cairo-based exporter rasterizes a lot of stuff that the old exporter didn't.
I think some of the issues (e.g. proper metasurface-based groups) are fixed in cairo trunk now, but I don't know if they've hit a release yet (and even if they have, there's no guarantee that, on Linux, the users/testers have a recent enough cairo installed to benefit).
Yes, there have been a *lot* of improvements on cairo's trunk. And I'd definitely like to take advantage of inkscape users to get some testing on that. So I'll make a cairo 1.5.2 snapshot either today or tomorrow, (I'll followup to this message to let you know about it), which should help testing.
I think two things we need to do at this point are:
get people reporting PDF problems to include their cairo version in the report (this may be something we should display in the about dialog)
find someone to assemble a test suite of cases we expect PDF export not to rasterize[1]
Both ideas sound great. For what it's worth, cairo-generated PDF output should be including it's version in there already. (There's a bug in that cairo doesn't also let inkscape report its version in the output as well---we should fix that.)
Since Linux distributions are going to lag behind in their cairo versions, we may still have to revert the PDF export for this release cycle no matter what gets fixed at this point. :/
Well, depending on what your testing shows, how about doing cairo-based PDF export if cairo is of a sufficient version, and using the old PDF export if cairo is not new enough.
That seems like a much better plan than having two competing options, or having to rip out code again that some people might be expecting to use already. It does depend on the switch to a "new enough cairo" not introducing any objectionable regressions for your users, of course. So that's where the testing will help, (let's get things fixed so that inkscape can just trust cairo with a version greater than or equal to 1.5.x for some x).
Sound good?
-Carl
On 10/17/07, Carl Worth <cworth@...573...> wrote:
That seems like a much better plan than having two competing options, or having to rip out code again that some people might be expecting to use already. It does depend on the switch to a "new enough cairo" not introducing any objectionable regressions for your users, of course. So that's where the testing will help, (let's get things fixed so that inkscape can just trust cairo with a version greater than or equal to 1.5.x for some x).
Sound good?
Yes, that would be the best approach, if it's possible and if (1) these two exporters will have different signatures in the UI and (2) the exported PDF files will have some labels indicating the exporter that created them. Without that, it will be very difficult to get information on the active exporter from users who submit PDF export bugs.
-Carl
IOn Wed, 17 Oct 2007 12:22:30 -0700 MenTaLguY <mental@...3...> wrote:
On Wed, 17 Oct 2007 11:35:54 -0700, Carl Worth <cworth@...573...> wrote:
[...]
If so, what's the cairo-based exporter still missing? Anything we can fix in cairo itself?
The general problem people are complaining about right now is that it the cairo-based exporter rasterizes a lot of stuff that the old exporter didn't.
I think some of the issues (e.g. proper metasurface-based groups) are fixed in cairo trunk now, but I don't know if they've hit a release yet (and even if they have, there's no guarantee that, on Linux, the users/testers have a recent enough cairo installed to benefit).
I think two things we need to do at this point are:
- get people reporting PDF problems to include their cairo version
in the report (this may be something we should display in the about dialog)
- find someone to assemble a test suite of cases we expect PDF
export not to rasterize[1]
Here's a quick test using your PDF test matrix; I don't have time right now to asssemble a more complete test suite.
Using cairo 1.4.10, which is the latest stable release:
stroke-dasharray: OK fill-opacity (solid): OK stroke-opacity (solid): OK linearGradient (fill): OK linearGradient (stroke): OK radialGradient (fill): OK radialGradient (stroke): OK stop-opacity: OK image: OK fill-opacity (gradient): FAILED (rasterized) stroke-opacity (gradient): OK text: OK flowText: OK opacity (path): FAILED (rasterized) opacity (image): FAILED (rasterized) opacity (fill+stroke): FAILED (rasterized) opacity (group): FAILED (rasterized)
And using cairo git as of 2007-10-18:
stroke-dasharray: OK fill-opacity (solid): OK stroke-opacity (solid): OK linearGradient (fill): OK linearGradient (stroke): OK radialGradient (fill): OK radialGradient (stroke): OK stop-opacity: OK image: OK fill-opacity (gradient): OK stroke-opacity (gradient): OK text: OK flowText: OK opacity (path): OK opacity (image): OK opacity (fill+stroke): OK opacity (group): OK
-- Gustav
On 10/17/07, jiho <jo.irisson@...400...> wrote:
How hard would it be to do it now? I don't see any drawback to re- enabling it now apart from the fact that it would require someone's time to do it. If this represents little time, it would be nice to have in the current dev builds.
The two problems with this are:
- Mental reenabled the cairo exporter soon after 0.45 was out, so it would be a little awkward to ask him to revert it yet another time :)
- this would make it more difficult to quickly test the progress of cairo (unless we manage to have two exporters side by side, which indeed would be the best option).
bulia byak wrote:
- this would make it more difficult to quickly test the progress of
cairo (unless we manage to have two exporters side by side, which indeed would be the best option).
IIRC we had this for quite some time. I believe it was removed at Bulia's request because it prompted too many questions from users. Is my memory correct?
Aaron Spike
On 10/17/07, Aaron Spike <aaron@...749...> wrote:
IIRC we had this for quite some time. I believe it was removed at Bulia's request because it prompted too many questions from users. Is my memory correct?
I rather doubt it. It was long ago, but my memory tells me that I asked Mental to provide both exporters at the same time and he said it's not possible or easy.
On Wed, 17 Oct 2007 16:11:44 -0300, "bulia byak" <buliabyak@...400...> wrote:
I rather doubt it. It was long ago, but my memory tells me that I asked Mental to provide both exporters at the same time and he said it's not possible or easy.
I think you did. It is possible, though -- it just causes problems.
I think we actually had multiple exporters in trunk for a while, but people complained because they didn't understand the difference between the two (and neither was 100% "better" -- each one did some things right that the other didn't). Besides that, it also caused problems with inconsistent behavior due to code that looked for "the" PDF export extension.
-mental
On Wed, 17 Oct 2007 14:04:41 -0500, Aaron Spike <aaron@...749...> wrote:
IIRC we had this for quite some time. I believe it was removed at Bulia's request because it prompted too many questions from users. Is my memory correct?
Something like that. I do remember that people weren't happy about having multiple exporters.
-mental
On 10/17/07, MenTaLguY <mental@...3...> wrote:
On Wed, 17 Oct 2007 14:04:41 -0500, Aaron Spike <aaron@...749...> wrote:
IIRC we had this for quite some time. I believe it was removed at Bulia's request because it prompted too many questions from users. Is my memory correct?
Something like that. I do remember that people weren't happy about having multiple exporters.
Maybe there is a lot of usability stuff with habing 2 ways to do "the same thing". Maybe another alternative is switching between cairo and the old one in the preferences (with Cairo as the default).
And for the record, this problem is with the snaps for Windows, I don't know if this happens with a updated Cairo.
Best regards
On Wed, 17 Oct 2007 15:58:12 -0300, "bulia byak" <buliabyak@...400...> wrote:
- this would make it more difficult to quickly test the progress of
cairo (unless we manage to have two exporters side by side, which indeed would be the best option).
FWIW, I think this might be a reasonable option for trunk, just not a release (assuming we can get the associated extension conflicts sorted out).
-mental
On 2007-October-17 , at 21:33 , MenTaLguY wrote:
On Wed, 17 Oct 2007 15:58:12 -0300, "bulia byak" <buliabyak@...400...> wrote:
- this would make it more difficult to quickly test the progress of
cairo (unless we manage to have two exporters side by side, which indeed would be the best option).
FWIW, I think this might be a reasonable option for trunk, just not a release (assuming we can get the associated extension conflicts sorted out).
I was thinking at trunk only indeed, choosing either Cairo's or Inkscape's PDF exporter for the release depending which one is thought to be the more appropriate. Besides, having the two side by side would provide tangible arguments to make this choice in the end. As for the Cairo issues, I would not be able to make a all-possible- scenarios comparison but my principal concern was with transparency and groups: Cairo rasterizes transparent objects and there are some strange interaction with groups. IIRC it rasterizes all objects in a group containing a transparent object even if the other objects are opaque, above the transparent one. I tried several things right now but it seems Cairo rasterized everything in the drawing as soon as there was a transparent object in it. I thought I had an "old" version of Cairo but 1.4.10 (which I have) appears to be the latest stable one. Hence it is the latest "easily" available on OS X ("easily" meaning without fetching cairo source and compiling it by myself). I would gladly add a Cairo-devel port just for me, so that it integrated well with the rest of the build system on OS X, but the MacPort system can't use git to fetch code, only svn. I tried to figure out a way to get devel snapshots but the only I found were months old (http://cairographics.org/snapshots/? C=M;O=D). Is there any way other than git to get recent development version of Cairo?
JiHO --- http://jo.irisson.free.fr/
On Wed, 17 Oct 2007 23:15:39 +0200, jiho wrote:
and groups: Cairo rasterizes transparent objects and there are some strange interaction with groups. IIRC it rasterizes all objects in a group containing a transparent object even if the other objects are opaque, above the transparent one. I tried several things right now but it seems Cairo rasterized everything in the drawing as soon as there was a transparent object in it.
Yes, that sounds like the state of cairo 1.4.10. It's gotten a *lot* better in the 1.5.x stuff currently in development.
I thought I had an "old" version of Cairo but 1.4.10 (which I have) appears to be the latest stable one. Hence it is the latest "easily" available on OS X ("easily" meaning without fetching cairo source and compiling it by myself). I would gladly add a Cairo-devel port just for me, so that it integrated well with the rest of the build system on OS X, but the MacPort system can't use git to fetch code, only svn.
Time to upgrade MacPort then. :-)
I tried to figure out a way to get devel snapshots but the only I found were months old (http://cairographics.org/snapshots/? C=M;O=D). Is there any way other than git to get recent development version of Cairo?
At this moment, git it is. But like I said in my previous mail, I'll make a cairo 1.5.2 snapshot today or tomorrow, (and post it to the above URL).
-Carl
Adib Taraben wrote:
Carl Worth schrieb:
...
Yes, that sounds like the state of cairo 1.4.10. It's gotten a *lot* better in the 1.5.x stuff currently in development.
what about to statically link to a current cairo library? Is that even possible?
Sure, but then we are stuck with the current state of Cairo at link time forever. It is possible to use LD_LIBRARY_PATH to cause Inkscape to run with a newer version of Cairo installed elsewhere on your system without disrupting installed software. I've used this for comparing output between different versions of Cairo without recompiling Inkscape. It would also be possible to use relaytool (from the Autopackage toolset) to enable and disable certain features in Inkscape at runtime based upon the Cairo version detected on the platform. But that would end up very confusing for users, I believe.
I would almost prefer to encourage users of various distributions to make and maintain unofficial cairo packages (or even a Cairo autopackage). So that users who need better PDF export can help themselves to better quality as Cairo continually matures.
Aaron Spike
On 10/18/07, Carl Worth wrote:
Yes, that sounds like the state of cairo 1.4.10. It's gotten a *lot* better in the 1.5.x stuff currently in development.
I'm not really sure if this is related, but 0.46 is featuring color management, and I'm eager to know if Cairo-based PDF exporter will be good at dealing with all this ICC stuff.
Alexandre
On 2007-October-18 , at 00:09 , Carl Worth wrote:
On Wed, 17 Oct 2007 23:15:39 +0200, jiho wrote:
[...] I thought I had an "old" version of Cairo but 1.4.10 (which I have) appears to be the latest stable one. Hence it is the latest "easily" available on OS X ("easily" meaning without fetching cairo source and compiling it by myself). I would gladly add a Cairo-devel port just for me, so that it integrated well with the rest of the build system on OS X, but the MacPort system can't use git to fetch code, only svn.
Time to upgrade MacPort then. :-)
upgrade so that there is a git method or upgrade the cairo port in MacPorts? Upgrading Cairo would be nice but I think that the MacPorts guys stayed on 1.4.10 because it is the latest release marked as stable on Cairo's site.
I tried to figure out a way to get devel snapshots but the only I found were months old (http://cairographics.org/snapshots/? C=M;O=D). Is there any way other than git to get recent development version of Cairo?
At this moment, git it is. But like I said in my previous mail, I'll make a cairo 1.5.2 snapshot today or tomorrow, (and post it to the above URL).
I noticed that there is no cairo 1.5.2 at this address. Are you still planning to make a git snapshot?
Other than that, I notice there is a web interface to cairo's git repository. In many SVN interfaces there are ways to get a tarball from the latest source (or for just about anything actually) directly from the web interface. Do you think you could set up something similar in cairo's interface? This would be a nice shortcut to get the latest bleeding edge (or a given commit, provide the hash is known) without having a proper git install. I find this functionality of SVN's interfaces very useful and would love to see it in git.
JiHO --- http://jo.irisson.free.fr/
On Sat, 20 Oct 2007 11:53:07 +0200, jiho wrote:
On 2007-October-18 , at 00:09 , Carl Worth wrote:
Time to upgrade MacPort then. :-)
upgrade so that there is a git method
That's what I meant, yes.
or upgrade the cairo port inMacPorts? Upgrading Cairo would be nice but I think that the MacPorts guys stayed on 1.4.10 because it is the latest release marked as stable on Cairo's site.
Yeah, and that's fine. We're working toward a 1.6 release for cairo, but we're not there yet.
I noticed that there is no cairo 1.5.2 at this address. Are you still planning to make a git snapshot?
Sorry about the delay. The 1.5.2 snapshot is here now:
http://cairographics.org/snapshots/cairo-1.5.2.tar.gz
And I'm definitely interested in hearing reports from inkscape users about cairo's PDF output with this snapshot. It should be lots better than cairo 1.4.10. But if you can find any regressions, I *definitely* want to hear about those.
Some notes on what's new in 1.5.2 compared to 1.4.10 can be seen here:
http://cairographics.org/news/cairo-1.5.2/
Other than that, I notice there is a web interface to cairo's git repository.
There are a couple of them actually:
http://cgit.freedesktop.org/cairo/ http://gitweb.freedesktop.org/
I find this functionality of SVN's interfaces very useful and would love to see it in git.
Git itself does have the ability to export a tar file, (the command is "git archive"), but I don't know if either cgit or gitweb expose that functionality, (there's no obvious existing link on either of the above URLs).
-Carl
On Wed, 2007-10-31 at 14:10 -0700, Carl Worth wrote:
Sorry about the delay. The 1.5.2 snapshot is here now:
http://cairographics.org/snapshots/cairo-1.5.2.tar.gz
And I'm definitely interested in hearing reports from inkscape users about cairo's PDF output with this snapshot. It should be lots better than cairo 1.4.10. But if you can find any regressions, I *definitely* want to hear about those.
Output greatly improved over 1.4.8 (didn't save 1.4.10 sample)! Tested using SVG from:
http://tavmjong.free.fr/INKSCAPE/MANUAL/web/svg_tests.xml
A few problems with evince (gradients). Acroread looks good. Patterns, clipping, and masking still appear to be unsupported.
Tav
[I'm copying the cairo list as well, (yes, evil cross-posting). Feel free to include only inkscape or cairo lists in replies if appropriate.]
For the cairo list: This is a response I got on the inkscape-devel list when asking for some testing of "export to PDF" in inkscape with the recent cairo 1.5.2 snapshot.
On Wed, 31 Oct 2007 23:22:18 +0100, Tavmjong Bah wrote:
Output greatly improved over 1.4.8 (didn't save 1.4.10 sample)!
Great!
Tested using SVG from:
Ooh. That looks like a pretty nice test. I'll definitely have to play with that some.
A few problems with evince (gradients).
Yes, this sounds expected as we've found bugs in evince/poppler exposed by the recent improvements to cairo's PDF output. See this bug:
Poppler does not yet handle everything in the cairo test suite https://bugs.freedesktop.org/show_bug.cgi?id=12143
as well as the other bugs it depends on. Specifically, this one is probably the one you're hitting:
Poppler doesn't correctly handle gradients with transparency https://bugs.freedesktop.org/show_bug.cgi?id=12144
Acroread looks good.
That's good. That puts the bugs in poppler's court, not cairo's.
Patterns, clipping, and masking still appear to be unsupported.
And this is where things get interesting. I think cairo-pdf should support all of that. So either something is still in missing in cairo that I'm not aware of, or something could be improved in inkscape with regards to the way it is using cairo, (or some combination of course).
If anyone that could take a closer look and give more details about any of these issues, that would be greatly appreciated.
Thanks for the quick feedback!
-Carl
On 2007-October-31 , at 22:10 , Carl Worth wrote:
On Sat, 20 Oct 2007 11:53:07 +0200, jiho wrote:
On 2007-October-18 , at 00:09 , Carl Worth wrote:
I noticed that there is no cairo 1.5.2 at this address. Are you still planning to make a git snapshot?
Sorry about the delay. The 1.5.2 snapshot is here now:
http://cairographics.org/snapshots/cairo-1.5.2.tar.gz
And I'm definitely interested in hearing reports from inkscape users about cairo's PDF output with this snapshot. It should be lots better than cairo 1.4.10. But if you can find any regressions, I *definitely* want to hear about those.
Some notes on what's new in 1.5.2 compared to 1.4.10 can be seen here:
I (eventually) installed this new Cairo into my MacPorts install, compiled with the pdf backend enabled (--enable-pdf) and tested Inkscape's output on a simple test file of mine. The results are mixed:
- transparency is supported in Adobe Reader but not in Preview (OS X image viewer): the object is simply not displayed. Actually Preview is just a front end to Cocoa's PDFKit which is what all OS X applications dealing with PDFs use. So at this point, Cairo's output is clearly not usable yet. Inkscape's old pdf exporter with transparency looked OK
- blur is not supported (this is not surprising however). the object is not even rasterized, it is just displayed without the blur
- all gradients are well supported
- bitmaps embedded or linked are conserved
- markers and clones are handled perfectly
So the largest issue, by far, is the transparency. Many applications on OS X deal with PDFs and they all use PDFKit. Plus, Preview is a very slick and fast PDF viewer so I guess that most people go with it and don't even install the huge, over-crowed and slow adobe reader. It can't be considered as an alternative then. I am conscious that, since Adobe Reader renders Cairo's PDF correctly, the bug is probably on Apple's side. But I am afraid there is no way they would change this soon and the effort will have to be done on Cairo's side. I hope it will not be too hard to fix.
As a last note it seems like if Cairo's PDF ouput, though of reasonable size, made both Preview and Adobe Reader choke on the file, to the point of hanging several seconds, when zooming far in (>1000%). Other PDF files on my machine do not lead to this kind of behaviour.
Anyway, it really feels like there was progress but just the last few bits were missing. I hope they will be solved by Inkscape release time. It would be extraordinary to have kick-ass PDF support, both at import and export, for this release. Thanks for your effort.
PS: pdf-test-case in svg and pdf at this address http://jo.irisson.free.fr/dropbox/inkscape/
JiHO --- http://jo.irisson.free.fr/
jiho wrote:
On 2007-October-31 , at 22:10 , Carl Worth wrote:
On Sat, 20 Oct 2007 11:53:07 +0200, jiho wrote:
On 2007-October-18 , at 00:09 , Carl Worth wrote: I noticed that there is no cairo 1.5.2 at this address. Are you still planning to make a git snapshot?
Sorry about the delay. The 1.5.2 snapshot is here now:
http://cairographics.org/snapshots/cairo-1.5.2.tar.gz
And I'm definitely interested in hearing reports from inkscape users about cairo's PDF output with this snapshot. It should be lots better than cairo 1.4.10. But if you can find any regressions, I *definitely* want to hear about those.
Some notes on what's new in 1.5.2 compared to 1.4.10 can be seen here:
I (eventually) installed this new Cairo into my MacPorts install, compiled with the pdf backend enabled (--enable-pdf) and tested Inkscape's output on a simple test file of mine. The results are mixed:
- transparency is supported in Adobe Reader but not in Preview (OS X
image viewer): the object is simply not displayed. Actually Preview is just a front end to Cocoa's PDFKit which is what all OS X applications dealing with PDFs use. So at this point, Cairo's output is clearly not usable yet. Inkscape's old pdf exporter with transparency looked OK
I don't have a Mac so can't check this myself however one of the cairo Mac developers, Brian Ewins, had a look and confirmed that the PDF displays correctly in Preview on Leopard but fails to display correctly on Tiger. I am assuming you are using Tiger.
The transparency in the PDF created by the old exporter is created by setting the alpha in the graphics state (/ca and /CA) before filling and stroking the path. The result is that the stroke color is blended with the fill color where they overlap. When zooming in on the stroke it can be seen that the stroke is split into two colors.
The transparency in the cairo PDF exporter is created by drawing the fill and stroke in a group using opaque colors then calling cairo_paint_with_alpha() to draw the group with a constant alpha over the entire group. This results in a uniform stroke color that matches what is seen on screen in Inkscape. In the PDF cairo_paint_with_alpha() is implemented by setting a SMask with a uniform alpha in the graphics state then drawing the group. However it appears that the Tiger version of Preview does not correctly implement SMasks.
You can obtain the old behavior with the cairo pdf exporter by filling and stroking the path with a transparent color instead of using cairo_paint_with_alpha() however this is not going to match the screen display.
- blur is not supported (this is not surprising however). the object
is not even rasterized, it is just displayed without the blur
The cairo API does not support blur so Inkscape will need to draw a rasterized image. Even if cairo did support blur, PDF does not, so either way this needs to be rasterized to obtain correct output.
all gradients are well supported
bitmaps embedded or linked are conserved
markers and clones are handled perfectly
So the largest issue, by far, is the transparency. Many applications on OS X deal with PDFs and they all use PDFKit. Plus, Preview is a very slick and fast PDF viewer so I guess that most people go with it and don't even install the huge, over-crowed and slow adobe reader. It can't be considered as an alternative then. I am conscious that, since Adobe Reader renders Cairo's PDF correctly, the bug is probably on Apple's side. But I am afraid there is no way they would change this soon and the effort will have to be done on Cairo's side. I hope it will not be too hard to fix.
This appears to have been fixed in Leopard. There is no work around that can be implemented in cairo for PDF viewers that do not support SMask other than image fallbacks.
As a last note it seems like if Cairo's PDF ouput, though of reasonable size, made both Preview and Adobe Reader choke on the file, to the point of hanging several seconds, when zooming far in (>1000%). Other PDF files on my machine do not lead to this kind of behaviour.
Brian tells me that he can not reproduce the slow down in Leopard.
Anyway, it really feels like there was progress but just the last few bits were missing. I hope they will be solved by Inkscape release time. It would be extraordinary to have kick-ass PDF support, both at import and export, for this release. Thanks for your effort.
PS: pdf-test-case in svg and pdf at this address http://jo.irisson.free.fr/dropbox/inkscape/
JiHO
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hello,
On 2007-November-22 , at 10:27 , Adrian Johnson wrote:
jiho wrote:
On 2007-October-31 , at 22:10 , Carl Worth wrote:
On Sat, 20 Oct 2007 11:53:07 +0200, jiho wrote:
On 2007-October-18 , at 00:09 , Carl Worth wrote: I noticed that there is no cairo 1.5.2 at this address. Are you still planning to make a git snapshot?
Sorry about the delay. The 1.5.2 snapshot is here now:
http://cairographics.org/snapshots/cairo-1.5.2.tar.gz
And I'm definitely interested in hearing reports from inkscape users about cairo's PDF output with this snapshot. It should be lots better than cairo 1.4.10. But if you can find any regressions, I *definitely* want to hear about those.
Some notes on what's new in 1.5.2 compared to 1.4.10 can be seen here:
I (eventually) installed this new Cairo into my MacPorts install, compiled with the pdf backend enabled (--enable-pdf) and tested Inkscape's output on a simple test file of mine. The results are mixed:
- transparency is supported in Adobe Reader but not in Preview (OS X
image viewer): the object is simply not displayed. Actually Preview is just a front end to Cocoa's PDFKit which is what all OS X applications dealing with PDFs use. So at this point, Cairo's output is clearly not usable yet. Inkscape's old pdf exporter with transparency looked OK
First, thanks for looking into it so deeply.
I don't have a Mac so can't check this myself however one of the cairo Mac developers, Brian Ewins, had a look and confirmed that the PDF displays correctly in Preview on Leopard but fails to display correctly on Tiger. I am assuming you are using Tiger.
You are assuming correctly.
The transparency in the PDF created by the old exporter is created by setting the alpha in the graphics state (/ca and /CA) before filling and stroking the path. The result is that the stroke color is blended with the fill color where they overlap. When zooming in on the stroke it can be seen that the stroke is split into two colors.
The transparency in the cairo PDF exporter is created by drawing the fill and stroke in a group using opaque colors then calling cairo_paint_with_alpha() to draw the group with a constant alpha over the entire group. This results in a uniform stroke color that matches what is seen on screen in Inkscape. In the PDF cairo_paint_with_alpha() is implemented by setting a SMask with a uniform alpha in the graphics state then drawing the group. However it appears that the Tiger version of Preview does not correctly implement SMasks.
You can obtain the old behavior with the cairo pdf exporter by filling and stroking the path with a transparent color instead of using cairo_paint_with_alpha() however this is not going to match the screen display.
Indeed using transparent colors work but using master opacity doesn't. Too bad since Master Opacity is much easier to access in Inkscape's UI. Actually the PDF output matches the screen display in the case of transparent colors applied to fill and stroke: the object show through the stroke and the stroke hence appears as if it had two colors. So that's fine on this point.
- blur is not supported (this is not surprising however). the object
is not even rasterized, it is just displayed without the blur
The cairo API does not support blur so Inkscape will need to draw a rasterized image. Even if cairo did support blur, PDF does not, so either way this needs to be rasterized to obtain correct output.
Yes I guessed it was the case. I just tested to see if Cairo would do the rasterizing for Inkscape ;)
all gradients are well supported
bitmaps embedded or linked are conserved
markers and clones are handled perfectly
So the largest issue, by far, is the transparency. Many applications on OS X deal with PDFs and they all use PDFKit. Plus, Preview is a very slick and fast PDF viewer so I guess that most people go with it and don't even install the huge, over-crowed and slow adobe reader. It can't be considered as an alternative then. I am conscious that, since Adobe Reader renders Cairo's PDF correctly, the bug is probably on Apple's side. But I am afraid there is no way they would change this soon and the effort will have to be done on Cairo's side. I hope it will not be too hard to fix.
This appears to have been fixed in Leopard. There is no work around that can be implemented in cairo for PDF viewers that do not support SMask other than image fallbacks.
OK. that's a bummer but I understand. Don't know how we'll handle that when shipping Inkscape though...
As a last note it seems like if Cairo's PDF ouput, though of reasonable size, made both Preview and Adobe Reader choke on the file, to the point of hanging several seconds, when zooming far in (>1000%). Other PDF files on my machine do not lead to this kind of behaviour.
Brian tells me that he can not reproduce the slow down in Leopard.
OK so maybe Preview.app has improved on Leopard regarding this also. I can't reproduce it reliably either here. It is probably a combination of some cairo properties which cause Preview to choke. If I find a document that reliable produces this and is simple enough to track the problem down, I'll let you know.
Thanks again.
JiHO --- http://jo.irisson.free.fr/
On Wed, 17 Oct 2007 15:17:33 -0300, "bulia byak" wrote:
On 10/17/07, jiho <jo.irisson@...400...> wrote:
However I agree that having a better functionality in the old release than in the dev builds feels strange. I have had to keep a copy of 0.45.1 at hand to export some of my PDFs which were fine in 0.45.1 but mostly rasterized by Cairo. Why should these two PDF exporters be exclusive? Couldn't we have _both_ in the dev builds? Furthermore, if Cairo does not progress on this side before 0.46, one should probably have to re-enable the internal PDF exporter and it would be good to test it a bit before release IMHO.
Definitely, though which exporter to ship with depends on when we release and how much progress cairo will have by then. I suggest we revisit this issue closer to our release, and if latest cairo is still not good enough by then, we'll have to reenable the old one exactly as Mental did for 0.45.
Our strategy with cairo has been to make things correct first, (even if ridiculously inefficient---see PDF files with mega-rasterization), and then to incrementally improve the performance while maintaining correctness.
That is, we've tried very hard to avoid regressions. And, during the 1.5 series there have been a *lot* of great optimizations to cairo's PDF output.
Now, I'm coming in to the middle of this conversation, (thanks for CC'ing me), but what are the current issues being faced? Are the regressions that you have found in cairo's PDF output? If so, I definitely want to get these fixed before cairo's 1.6.0 release.
Thanks,
-Carl
participants (11)
-
Aaron Spike -
Adib Taraben -
Adrian Johnson -
Alexandre Prokoudine -
bulia byak -
Carl Worth -
Gustav Broberg -
Jaime Martínez-Figueroa -
jiho -
MenTaLguY -
Tavmjong Bah