6:01 a.m.
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
--
Jaime F. Martínez Figueroa
Electronics and Computer Science in the way
[P!]Wack in the net, visit http://alumnos.elo.utfsm.cl/~jmartinez/
meatPixel at http://meatpixel.net
6:44 a.m.
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/
10:48 a.m.
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
---
http://jo.irisson.free.fr/
--
Jaime F. Martínez Figueroa
Electronics and Computer Science in the way
[P!]Wack in the net, visit http://alumnos.elo.utfsm.cl/~jmartinez/
meatPixel at http://meatpixel.net
11:17 a.m.
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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
11:21 a.m.
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/
11:35 a.m.
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
12:22 p.m.
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.*
1:34 p.m.
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:
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]
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
2:02 p.m.
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
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
1:25 a.m.
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:
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]
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
11:58 a.m.
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
Inkscape. Draw Freely.
http://www.inkscape.org
12:04 p.m.
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
12:11 p.m.
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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
12:31 p.m.
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
12:23 p.m.
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
12:38 p.m.
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
--
Jaime F. Martínez Figueroa
Electronics and Computer Science in the way
[P!]Wack in the net, visit http://alumnos.elo.utfsm.cl/~jmartinez/
meatPixel at http://meatpixel.net
12:33 p.m.
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
2:15 p.m.
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/
3:09 p.m.
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
8:09 a.m.
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
1:46 p.m.
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
2:53 a.m.
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/
2:10 p.m.
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 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.
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
3:22 p.m.
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
3:42 p.m.
[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:
http://tavmjong.free.fr/INKSCAPE/MANUAL/web/svg_tests.xml
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
7:27 a.m.
New subject: Cairo PDF status. Was: Weird issue saving in PDF
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:
http://cairographics.org/news/cairo-1.5.2/
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/
1:27 a.m.
New subject: Cairo PDF status. Was: Weird issue saving in PDF
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:
>
> http://cairographics.org/news/cairo-1.5.2/
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
---
http://jo.irisson.free.fr/
-------------------------------------------------------------------------
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
1:47 a.m.
New subject: Cairo PDF status. Was: Weird issue saving in PDF
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:
>>
>> http://cairographics.org/news/cairo-1.5.2/
>
> 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/
11:26 a.m.
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
5852
days inactive
5889
days old
inkscape-devel@lists.inkscape.org
29 comments
11 participants
participants (11)
-
Aaron Spike -
Adib Taraben -
Adrian Johnson -
Alexandre Prokoudine -
bulia byak -
Carl Worth -
Gustav Broberg -
Jaime Martínez-Figueroa -
jiho -
MenTaLguY -
Tavmjong Bah