I've been trying to educate myself about our printing problem by exploring cairo, librsvg, the uberconvertor and pdf in general. I stumbled across this document entitled, "Achieving Reliable Print Output from Adobe Applications when Using Transparency."
http://partners.adobe.com/public/asn/en/print_resource_center/TXPGuide.pdf
It seems to me that most all of the functionality needed for flattening out transparency already exists in Inkscape. A rather brute force method could be:
1) Replace all strokes with paths 2) Decompose all overlapping objects (this would be an additional boolean op, and it has been requested twice in my recent memory) 3) Replace all area's of overlapping transparency with a bitmap copy. 4) Replace all non overlapping transparency with the resultant color.
Further optimizations would of course be possible. My exploration of cairo and librsvg has only been very casual, but I can't imagine that either of them will be well suited to this sort of decomposition task. But maybe with all of the recent excitement and advancement around vectors a good LGPL computational geometry library will pop up.
Aaron Spike
On Tue, 21 Feb 2006, Aaron Spike wrote:
It seems to me that most all of the functionality needed for flattening out transparency already exists in Inkscape. A rather brute force method could be:
- Replace all strokes with paths
- Decompose all overlapping objects (this would be an additional boolean op,
and it has been requested twice in my recent memory) 3) Replace all area's of overlapping transparency with a bitmap copy. 4) Replace all non overlapping transparency with the resultant color.
I don't think rendering to a bitmap is required. I think, if you've already split all of the objects up into their various sub components, you should be able to calculate the correct color without transparency. I think the only time you need a bitmap is for overlapping gradients with transparency.
Yeah, I think that everything is in Inkscape, it's just a matter of writing it all :) It would be nice if the sub-functions were written as effects: Split Overlaps and Remove Transparency. I could see uses for them outside of printing.
--Ted
On 2/21/06, Aaron Spike <aaron@...749...> wrote:
- Replace all strokes with paths
- Decompose all overlapping objects (this would be an additional
boolean op, and it has been requested twice in my recent memory) 3) Replace all area's of overlapping transparency with a bitmap copy. 4) Replace all non overlapping transparency with the resultant color.
I can only repeat my strong conviction that implementing transparency via PDF 1.4 is several orders of magniture simpler, not to mention more practical. The demand for transparency in PS is only going to decrease with time.
Not to mention the really abominable (IMHO) unnaturalness and baroqueness of the above approach. Many times I have cursed when Xara created a (unusable for me) Postscript with embedded bitmaps, due to some apparent overlooked bits of transparency in the source drawing. Given the bugginess of our boolean ops and the many unfixed bugs even in the current PS export, I really think our effects could be better spent.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
On 2/21/06, Aaron Spike <aaron@...749...> wrote:
- Replace all strokes with paths
- Decompose all overlapping objects (this would be an additional
boolean op, and it has been requested twice in my recent memory) 3) Replace all area's of overlapping transparency with a bitmap copy. 4) Replace all non overlapping transparency with the resultant color.
I can only repeat my strong conviction that implementing transparency via PDF 1.4 is several orders of magniture simpler, not to mention more practical. The demand for transparency in PS is only going to decrease with time.
Not to mention the really abominable (IMHO) unnaturalness and baroqueness of the above approach. Many times I have cursed when Xara created a (unusable for me) Postscript with embedded bitmaps, due to some apparent overlooked bits of transparency in the source drawing. Given the bugginess of our boolean ops and the many unfixed bugs even in the current PS export, I really think our effects could be better spent.
Seems that both Xara and Adobe are giving credibility to the really abominable unnaturalness and baroqueness of this approach. ;-)
I agree that it is unnatural and I too would prefer a PDF 1.4+ solution. But support for PDF 1.3- is going to remain pertinent for a much longer time than we would like. There has got to be hosts of application that still support only the opaque drawing mode.
And if anyone in the OSS community is going to affect such a gnarly solution, it would be easiest for us because we have the infrastructure.
Don't worry. This was just an observation not a call to action. I'm still exploring and educating myself.
Latest observation, rsvg-convert uses cairo to generate pdfs, but they are fully rasterized, though from skimming through the pdf surface source in cairo cvs it would appear they have code to write pdf drawing operations.
Aaron Spike
On Tuesday 21 February 2006 21:20, Aaron Spike wrote:
bulia byak wrote:
On 2/21/06, Aaron Spike <aaron@...749...> wrote:
- Replace all strokes with paths
- Decompose all overlapping objects (this would be an additional
boolean op, and it has been requested twice in my recent memory) 3) Replace all area's of overlapping transparency with a bitmap copy. 4) Replace all non overlapping transparency with the resultant color.
I can only repeat my strong conviction that implementing transparency via PDF 1.4 is several orders of magniture simpler, not to mention more practical. The demand for transparency in PS is only going to decrease with time.
Not to mention the really abominable (IMHO) unnaturalness and baroqueness of the above approach. Many times I have cursed when Xara created a (unusable for me) Postscript with embedded bitmaps, due to some apparent overlooked bits of transparency in the source drawing. Given the bugginess of our boolean ops and the many unfixed bugs even in the current PS export, I really think our effects could be better spent.
Seems that both Xara and Adobe are giving credibility to the really abominable unnaturalness and baroqueness of this approach. ;-)
I agree that it is unnatural and I too would prefer a PDF 1.4+ solution. But support for PDF 1.3- is going to remain pertinent for a much longer time than we would like. There has got to be hosts of application that still support only the opaque drawing mode.
And if anyone in the OSS community is going to affect such a gnarly solution, it would be easiest for us because we have the infrastructure.
Don't worry. This was just an observation not a call to action. I'm still exploring and educating myself.
Latest observation, rsvg-convert uses cairo to generate pdfs, but they are fully rasterized, though from skimming through the pdf surface source in cairo cvs it would appear they have code to write pdf drawing operations.
I'll stick my Scribus head in here and say you should implement one, and if possible, see if we can work together on it (at least in spec, if not code). PDF 1.3 is still very popular amongst the printing world, and while PDF 1.4 is getting there its not there yet. There are many many printers that do not accept PDF print jobs even if they have the latest equipment that they can just throw a well formed PDF at and out comes the print job. Many of them still attempt to import a PDF into Q* Xpress which is a miserable PDF importer at the best of times.
Of course, getting PDF 1.4 support first would be the best way to go. IMO.
FWIW though, theres a strong move to migrate all printing on Linux to use PDF vs PS.
Craig
On 2/21/06, Aaron Spike <aaron@...749...> wrote:
Seems that both Xara and Adobe are giving credibility to the really abominable unnaturalness and baroqueness of this approach. ;-)
Sure, but they both are much older than Inkscape. I don't know if they would choose to do the same thing if they were writing their applications from scratch now, as opposed to 10 or 15 years ago.
One thing I did not mention in my last mail is that, even when I do need PS output emulating transparency (and I do need it sometimes), at least Xara's attempts to do it have always been useless to me. The joints between the bitmap and vector parts of the image are always too unpredictable and too visible, which ruins the output. In all these cases, to do it right requires human intelligence: I group all things that use transparency AND most other thing that logically belong with them (usually they all constitute a loosely understood "background") together and export them all as bitmap. The rest of the composition (usually only text and sometimes line art) I export as PS. Then I quickly reassemble the bitmap background and the vector text in AI and send the result to the client (most clients require AI or PDF). This works nice, but as you can see, I can do (and I actually do) just the same with Inkscape+AI as I used to do with Xara+AI, so Xara's intelligent rasterizer-in-PS is of no use to me. YMMV, but this is my experience.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Le Tue, 21 Feb 2006 08:30:51 -0600, Aaron Spike a écrit :
It seems to me that most all of the functionality needed for flattening out transparency already exists in Inkscape. A rather brute force method could be:
- Replace all strokes with paths
- Decompose all overlapping objects (this would be an additional boolean
op, and it has been requested twice in my recent memory) 3) Replace all area's of overlapping transparency with a bitmap copy. 4) Replace all non overlapping transparency with the resultant color.
Further optimizations would of course be possible. My exploration of cairo and librsvg has only been very casual, but I can't imagine that either of them will be well suited to this sort of decomposition task.
Cairo developper plan is to implement more or less what you have described. Currently, PDF and PS backends only produce rasterized outputs. But they definitely want to use vector operations as much as possible, and only fallback to bitmap when necessary.
On a related note, I've contributed a SVG backend to cairo, which will be included as experimental in next stable release. I guess it could be possible to use poppler + cairo + SVG backend for import of PDF in inkscape.
Regards,
Emmanuel.
participants (5)
-
unknown＠example.com -
Aaron Spike -
bulia byak -
Craig Bradney -
emmanuel