Hi,
This message was sent previously but bounced because the attachments were to big, and then apparently got lost. Apologies in case this gets double-posted.
To the issue: if I understand it correctly, the eps and pdf export was switched in the transition from version 0.46 to 0.47. In my experience, the new eps export doesn't work well, producing larger files and also converting some vector elements to raster in an unpredictable way. The new pdf export seems to produce less rasterization but also produces large files that can take a very long time to render in a pdf viewer.
I suppose there was a reason for this transition, maybe gradients, transparency and such. However, where these features are not required, the old export routines produce more compact output and avoid wanton rasterization. Also, the old-style eps files can be used with LaTeX' psfrag mechanism, whereas the new-style ones cannot.
So, my question is, could we please have the old eps export back - as an additional option, or maybe as a user-installable extension?
Thanks for consideration, best, Michael
PS Example files produced from the same svg file and exported with versions 0.46 and 0.47, respectively, are not attached (the 0.47 ones are too big and blow the message size limit) but can be viewed at http://watcut.uwaterloo.ca/_files/
On 17/2/11 17:35, Michael Palmer wrote:
PS Example files produced from the same svg file and exported with versions 0.46 and 0.47, respectively, are not attached (the 0.47 ones are too big and blow the message size limit) but can be viewed at http://watcut.uwaterloo.ca/_files/
Could you make the original SVG file available too, to allow testing with Inkscape builds from the current development branch, and different cairo versions?
Some issues with unnecessary rasterization when exporting to EPS have been addressed lately in the development branch, and it would also allow to compare your results with exports created by the current stable version (Inkscape 0.48.x).
~suv
Of course. I added it to the same directory as source.svg
http://watcut.uwaterloo.ca/_files/
Thanks for looking into it!
On Thu, Feb 17, 2011 at 12:29 PM, ~suv <suv-sf@...58...> wrote:
On 17/2/11 17:35, Michael Palmer wrote:
PS Example files produced from the same svg file and exported with
versions
0.46 and 0.47, respectively, are not attached (the 0.47 ones are too big
and
blow the message size limit) but can be viewed at http://watcut.uwaterloo.ca/_files/
Could you make the original SVG file available too, to allow testing with Inkscape builds from the current development branch, and different cairo versions?
Some issues with unnecessary rasterization when exporting to EPS have been addressed lately in the development branch, and it would also allow to compare your results with exports created by the current stable version (Inkscape 0.48.x).
~suv
On 17/2/11 17:35, Michael Palmer wrote:
To the issue: if I understand it correctly, the eps and pdf export was switched in the transition from version 0.46 to 0.47. In my experience, the new eps export doesn't work well, producing larger files and also converting some vector elements to raster in an unpredictable way.
The rasterization that happens in your example file is predictable and needed, because a lot of the objects used a minimally reduced object opacity (96%) - seemingly either to mimic a lighter shade of the fill color, or unintentionally, as the visual effect is barely noticeable compared to using 100% opacity.
Postscript does not support transparency, and every object with reduced opacity is rendered as bitmap in the exported EPS/PS file (as described in the release notes for 0.47 [1]).
With regard to your SVG example: a simple way to get a clean vector-only EPS file is to change the opacity of the objects to 100% without editing the fill/stroke colors: - 'Edit > Find…' - search for the string 'opacity:0' in the style attribute - change global opacity to 100% for the resulting selection - export to EPS
The new pdf export seems to produce less rasterization but also produces large files that can take a very long time to render in a pdf viewer.
While PDF does support transparency, for object opacity (affecting fill and stroke equally, as opposed to stroke opacity and fill opacity (the 'A' alpha channel in the Fill&Stroke dialog)) cairo uses a more complex structure to achieve the same visual effect as in the SVG file [2]. Again, one could recommend to only use reduced opacity when needed and not to just modify the shade of a color.
I suppose there was a reason for this transition, maybe gradients, transparency and such. However, where these features are not required, the old export routines produce more compact output and avoid wanton rasterization. Also, the old-style eps files can be used with LaTeX' psfrag mechanism, whereas the new-style ones cannot.
See bug #375323 https://bugs.launchpad.net/inkscape/+bug/375323 "ps and eps export with cairo in inkscape no usable with psfrag"
The next cairo version (1.12) will again support the psfrag method to extract text from the EPS file (limited to latin characters, see comment #43).
~suv
[1] http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#PDF.2C_PostScript.2C_and_EPS_export [2] described e.g. in these comments from a cairo developer: https://bugs.launchpad.net/inkscape/+bug/336638/comments/15 https://bugs.launchpad.net/inkscape/+bug/336638/comments/17
The rasterization that happens in your example file is predictable and needed, because a lot of the objects used a minimally reduced object opacity (96%) - seemingly either to mimic a lighter shade of the fill color, or unintentionally, as the visual effect is barely noticeable compared to using 100% opacity.
Indeed this was unintentional - I must have goofed it up at some point.
Removing the transparency solves all the issues with this picture.
The next cairo version (1.12) will again support the psfrag method to extract text from the EPS file (limited to latin characters, see comment #43).
that's good news.
thanks for you help! best, Michael
~suv
[1] < http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#PDF.2C_PostScript...
[2] described e.g. in these comments from a cairo developer: https://bugs.launchpad.net/inkscape/+bug/336638/comments/15 https://bugs.launchpad.net/inkscape/+bug/336638/comments/17
Michael,
ps, eps and pdf output are generated using the cairo library. This library is/will be also used for gui rendering. For us developer this means one code for different output targets. And so consistent outputs. Also there where a lot of trouble with fonts in PS files. The library rasterizes when the vectors can not translated into the target format because of (blur) filters or transparency.
Hope you understand this.
Pls communicate features that you are missing and files that you think are translated not correctly.
Regards,
Adib.
On Thu, Feb 17, 2011 at 5:35 PM, Michael Palmer <mike4561@...400...> wrote:
Hi,
This message was sent previously but bounced because the attachments were to big, and then apparently got lost. Apologies in case this gets double-posted.
To the issue: if I understand it correctly, the eps and pdf export was switched in the transition from version 0.46 to 0.47. In my experience, the new eps export doesn't work well, producing larger files and also converting some vector elements to raster in an unpredictable way. The new pdf export seems to produce less rasterization but also produces large files that can take a very long time to render in a pdf viewer.
I suppose there was a reason for this transition, maybe gradients, transparency and such. However, where these features are not required, the old export routines produce more compact output and avoid wanton rasterization. Also, the old-style eps files can be used with LaTeX' psfrag mechanism, whereas the new-style ones cannot.
So, my question is, could we please have the old eps export back - as an additional option, or maybe as a user-installable extension?
Thanks for consideration, best, Michael
PS Example files produced from the same svg file and exported with versions 0.46 and 0.47, respectively, are not attached (the 0.47 ones are too big and blow the message size limit) but can be viewed at http://watcut.uwaterloo.ca/_files/
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (3)
-
Michael Palmer
-
the Adib
-
~suv