Dear Inkscape Developers,
I use Inkscape regularly to edit figures for scientific publications. Because I like to use transparency effects but many journals only accept EPS files for publication, I ran into the well-known "transparency and PostScript export" problem. First I used to remove the transparency by hand as described in the "Tips and Tricks" tutorial [1]. This has been a hard job and sometimes it is virtually impossible.
To facilitate this task I have automated this workaround (removing transparency by adding shapes covering the overlapping areas with the corresponding mixed color). So far I am quite happy with that solution, although it obviously does not work for gradients etc., and I would like to include it in the official Inkscape version.
In this regard I have a few questions to you:
1) Are there any general objections to add this code to Inkscape?
2) Where would you place this function in the UI? (For my personal use I have added the item "Remove Transparency" to the Path menu, which probably is not appropriate.) Related to this question is the question how to deal with the limited ability of this approach in order to not confuse or annoy users (e.g. when they use it with gradients).
3) Where would you ideally add the code for this feature? Currently I have added four functions sp_remove_transparency*() to splivarot.cpp. I chose this file because of the relation to sp_selected_path_intersect(). Also, I have copied some code from sp_selected_path_boolop() to get the intersection shapes and I suggest to put the common code in a more generic boolean operation function in order to avoid duplicate code.
I'm looking forward to receive your comments and thoughts.
Thanks, Marco
Marco Steinacher wrote:
Dear Inkscape Developers, ... To facilitate this task I have automated this workaround (removing transparency by adding shapes covering the overlapping areas with the corresponding mixed color). So far I am quite happy with that solution, although it obviously does not work for gradients etc., and I would like to include it in the official Inkscape version.
Very cool :) But why does it "obviously" not work for gradients? As long as the transparency doesn't vary over the gradient it shouldn't be too difficult, and if it does you could try adding stops to keep the appearance more or less the same.
In this regard I have a few questions to you:
- Are there any general objections to add this code to Inkscape?
I doubt it (without having looked at the code of course).
- Where would you place this function in the UI? (For my personal use I
have added the item "Remove Transparency" to the Path menu, which probably is not appropriate.)
Perhaps just do it automatically at export? (Possibly adding some hard to find checkbox to disable it, or make it depend on the background colour, if anyone feels the need.) I mean, why would anyone NOT want to do this? As far as I'm concerned it's just a way to make the EPS export as correct as possible. Or am I missing something?
Explicitly exposing it to the user seems like a bit of a cludge, it would just make the document more complex and harder to manage, while keeping the appearance the same.
Related to this question is the question how to deal with the limited ability of this approach in order to not confuse or annoy users (e.g. when they use it with gradients).
I'm not a big fan of popping up message boxes stating that "features XYZ are not supported in this format", but perhaps something like that will suffice if there aren't too many unsupported features.
- Where would you ideally add the code for this feature? Currently I
have added four functions sp_remove_transparency*() to splivarot.cpp. I chose this file because of the relation to sp_selected_path_intersect(). Also, I have copied some code from sp_selected_path_boolop() to get the intersection shapes and I suggest to put the common code in a more generic boolean operation function in order to avoid duplicate code.
Sounds sensible, but I have hardly any experience with this part of the code, so I can't really comment on the appropriateness of the location.
Jasper van de Gronde wrote:
Marco Steinacher wrote:
Dear Inkscape Developers, ... To facilitate this task I have automated this workaround (removing transparency by adding shapes covering the overlapping areas with the corresponding mixed color). So far I am quite happy with that solution, although it obviously does not work for gradients etc., and I would like to include it in the official Inkscape version.
Very cool :) But why does it "obviously" not work for gradients? As long as the transparency doesn't vary over the gradient it shouldn't be too difficult, and if it does you could try adding stops to keep the appearance more or less the same.
Yes, you're right. It's not obvious and it should be possible to do. I was a bit unspecific about the shortcomings of the current version. Currently the method only works for shapes filled with flat color. There are also some problems regarding strokes (and possibly other things I don't know of yet...) I have to address.
I intend to improve the current (incomplete) version, which already is very helpful for my specific use but probably not for the general user. I just wanted to know whether it makes sense to invest more time and discuss some basic questions.
- Where would you place this function in the UI? (For my personal use I
have added the item "Remove Transparency" to the Path menu, which probably is not appropriate.)
Perhaps just do it automatically at export? (Possibly adding some hard to find checkbox to disable it, or make it depend on the background colour, if anyone feels the need.) I mean, why would anyone NOT want to do this? As far as I'm concerned it's just a way to make the EPS export as correct as possible. Or am I missing something?
Yes, I thought of this possibility too. However, I haven't look at the export code and have no clue of the concepts yet.
Explicitly exposing it to the user seems like a bit of a cludge, it would just make the document more complex and harder to manage, while keeping the appearance the same.
I agree. The only reason I currently see is to be able to fix some things manually before exporting to PostScript. However, this can still be done by opening and editing the exported EPS file, when the method is applied automatically at exprt.
Marco
On Tue, Nov 25, 2008 at 5:10 AM, Marco Steinacher <msteinacher@...2086...> wrote:
I intend to improve the current (incomplete) version, which already is very helpful for my specific use but probably not for the general user. I just wanted to know whether it makes sense to invest more time and discuss some basic questions.
Current SVN uses cairo exporter to PS and EPS, which automatically converts areas with transparency into bitmaps. Do you think your solution still makes sense as an alternative to that? If so, I would welcome it added to our code, of course as an export option for these formats rather than a standalone command. Of course it should work with both flat and gradient transparency, and preserve appearance in almost all cases, perhaps excepting a few special cases.
bulia byak wrote:
On Tue, Nov 25, 2008 at 5:10 AM, Marco Steinacher <msteinacher@...2086...> wrote:
I intend to improve the current (incomplete) version, which already is very helpful for my specific use but probably not for the general user. I just wanted to know whether it makes sense to invest more time and discuss some basic questions.
Current SVN uses cairo exporter to PS and EPS, which automatically converts areas with transparency into bitmaps. Do you think your solution still makes sense as an alternative to that?
OK, good to know that. Probably this solution is appropriate for many cases. However, I think maybe it would be nice to have a pure vector-based alternative, because it preserves the quality of vector graphics while minimizing the file size (useful for professional publication or when printed on a poster).
I'll get the current SVN version and check how the cairo EPS exporter does for my application. If I'm happy with it, I will not carry on with my approach.
Thanks, Marco
Marco Steinacher wrote:
bulia byak wrote:
Current SVN uses cairo exporter to PS and EPS, which automatically converts areas with transparency into bitmaps. Do you think your solution still makes sense as an alternative to that?
OK, good to know that. Probably this solution is appropriate for many cases. However, I think maybe it would be nice to have a pure vector-based alternative, because it preserves the quality of vector graphics while minimizing the file size (useful for professional publication or when printed on a poster).
I'll get the current SVN version and check how the cairo EPS exporter does for my application. If I'm happy with it, I will not carry on with my approach.
Please consider carrying on anyway, bitmaps are good for their purpose, but a terrible choice when it comes to representing vector graphics (from a quality/size perspective). Of course Cairo's approach definitely has merit when no other approach is available, but it would be great to simply have a nice, small, near-perfect quality result when exporting to eps.
BTW, if you need any help, don't hesitate to ask. I probably have some time this weekend, and I usually spend some time on Inkscape each Tuesday.
On Wed, Nov 26, 2008 at 3:00 AM, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
Marco Steinacher wrote:
bulia byak wrote:
Current SVN uses cairo exporter to PS and EPS, which automatically converts areas with transparency into bitmaps. Do you think your solution still makes sense as an alternative to that?
OK, good to know that. Probably this solution is appropriate for many cases. However, I think maybe it would be nice to have a pure vector-based alternative, because it preserves the quality of vector graphics while minimizing the file size (useful for professional publication or when printed on a poster).
I'll get the current SVN version and check how the cairo EPS exporter does for my application. If I'm happy with it, I will not carry on with my approach.
Please consider carrying on anyway, bitmaps are good for their purpose, but a terrible choice when it comes to representing vector graphics (from a quality/size perspective). Of course Cairo's approach definitely has merit when no other approach is available, but it would be great to simply have a nice, small, near-perfect quality result when exporting to eps.
Perhaps then it would make more sense to make this code part of cairo, so that it is available to every user of cairo and not just Inkscape?
Adrian: what would you say to an alternative to "rasterize transparency" PS/EPS backend approach, which would where possible intersect semitransp shapes and fill then with flat color or no-transparency gradients to preserve appearance?
2008/11/26 bulia byak wrote:
Perhaps then it would make more sense to make this code part of cairo, so that it is available to every user of cairo and not just Inkscape?
Adrian: what would you say to an alternative to "rasterize transparency" PS/EPS backend approach, which would where possible intersect semitransp shapes and fill then with flat color or no-transparency gradients to preserve appearance?
http://bugs.freedesktop.org/show_bug.cgi?id=17411 :-)
Alexandre
bulia byak wrote:
Adrian: what would you say to an alternative to "rasterize transparency" PS/EPS backend approach, which would where possible intersect semitransp shapes and fill then with flat color or no-transparency gradients to preserve appearance?
It would be a nice feature to have. But since it is something that can be done by the application, adding this to cairo is not a high priority.
On Wed, Nov 26, 2008 at 5:17 PM, Adrian Johnson <ajohnson@...1679...> wrote:
bulia byak wrote:
Adrian: what would you say to an alternative to "rasterize transparency" PS/EPS backend approach, which would where possible intersect semitransp shapes and fill then with flat color or no-transparency gradients to preserve appearance?
It would be a nice feature to have. But since it is something that can be done by the application, adding this to cairo is not a high priority.
Well, the same applies to the rasterization - it can also, in principle, be done by the application. Wouldn't it be better, from architecture viewpoint, to have both approaches implemented in one library?
bulia byak wrote:
On Wed, Nov 26, 2008 at 5:17 PM, Adrian Johnson <ajohnson@...1679...> wrote:
bulia byak wrote:
Adrian: what would you say to an alternative to "rasterize transparency" PS/EPS backend approach, which would where possible intersect semitransp shapes and fill then with flat color or no-transparency gradients to preserve appearance?
It would be a nice feature to have. But since it is something that can be done by the application, adding this to cairo is not a high priority.
Well, the same applies to the rasterization - it can also, in principle, be done by the application. Wouldn't it be better, from architecture viewpoint, to have both approaches implemented in one library?
I agree that this would be better done in cairo for all applications to use. In the case of rasterization we already have the code for rasterizing the fallback images. The problem with intersecting paths is we don't have any code in cairo for doing that (and adding new library dependencies to cairo is unlikely to be accepted). I'm happy to review any well written patches that add this functionality to cairo. But implementing it myself is not very high on my TODO list. Right now I am more interesting in implementing things like PDF Type 6/7 gradients, color management, and supporting the additional PDF features people are requesting like PDF/A, metadata and hyperlinks.
On Wed, Nov 26, 2008 at 7:22 PM, Adrian Johnson <ajohnson@...1679...> wrote:
I agree that this would be better done in cairo for all applications to use. In the case of rasterization we already have the code for rasterizing the fallback images. The problem with intersecting paths is we don't have any code in cairo for doing that (and adding new library dependencies to cairo is unlikely to be accepted).
Yes, in that case it's better to do in Inkscape, at least until you can accept 2geom as a dependency (and until 2geom itself is mature enough).
Thanks for the update!
I'd like to put in a plug for my favorite pdf/eps bug, LP 284680. running Win32 rev20225, if I create text, choose save_as pdf or eps, and uncheck the "Convert text to paths", then I get text successfully rendered as what looks like a bitmap.
If I do the same output and use "Convert text to paths" then I get nothing as output.
On Tue, 2008-11-25 at 08:26 +0100, Marco Steinacher wrote:
- Where would you ideally add the code for this feature? Currently I
have added four functions sp_remove_transparency*() to splivarot.cpp. I chose this file because of the relation to sp_selected_path_intersect(). Also, I have copied some code from sp_selected_path_boolop() to get the intersection shapes and I suggest to put the common code in a more generic boolean operation function in order to avoid duplicate code.
I would recommend subclassing Inkscape::Extention::Effect and putting it in it's own effect. Most of the internal effects live in /src/extensions/internal.
There are a few advantages of doing it this way. One, the code is very componentized so that as you work on it folks are unlikely to run into you. It creates the menu items, the verbs and all the GUI wrappers for you. All that you need to do is add the item to the menu skeleton and everything else is happy-happy. You also get live preview for free.
I would recommend leaving this as an effect rather than an output filter because I think it could have useful results for a variety of formats and also that it's likely an artist would want to tweak the results after the automatic script has run.
Cool stuff.
--Ted
Marco,
Thanks very much for this. It's really appreciated. Xmas come early infact.
Bitmap export is great but certainly not in all cases requiring pure vector output (size / colour requirements)
I can't wait for this to enter inkscape and be an export option.
Cheers mate, Andy
On Tue, Nov 25, 2008 at 3:26 PM, Marco Steinacher <msteinacher@...2086...>wrote:
Dear Inkscape Developers,
I use Inkscape regularly to edit figures for scientific publications. Because I like to use transparency effects but many journals only accept EPS files for publication, I ran into the well-known "transparency and PostScript export" problem. First I used to remove the transparency by hand as described in the "Tips and Tricks" tutorial [1]. This has been a hard job and sometimes it is virtually impossible.
To facilitate this task I have automated this workaround (removing transparency by adding shapes covering the overlapping areas with the corresponding mixed color). So far I am quite happy with that solution, although it obviously does not work for gradients etc., and I would like to include it in the official Inkscape version.
In this regard I have a few questions to you:
Are there any general objections to add this code to Inkscape?
Where would you place this function in the UI? (For my personal use I
have added the item "Remove Transparency" to the Path menu, which probably is not appropriate.) Related to this question is the question how to deal with the limited ability of this approach in order to not confuse or annoy users (e.g. when they use it with gradients).
- Where would you ideally add the code for this feature? Currently I
have added four functions sp_remove_transparency*() to splivarot.cpp. I chose this file because of the relation to sp_selected_path_intersect(). Also, I have copied some code from sp_selected_path_boolop() to get the intersection shapes and I suggest to put the common code in a more generic boolean operation function in order to avoid duplicate code.
I'm looking forward to receive your comments and thoughts.
Thanks, Marco
[1] http://www.inkscape.org/doc/tips/tutorial-tips.html
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (8)
-
Adrian Johnson -
Alexandre Prokoudine -
Alvin Penner -
Andy Fitzsimon -
bulia byak -
Jasper van de Gronde -
Marco Steinacher -
Ted Gould