Sven Neumann wrote:
>On Sun, 2007-07-22 at 14:10 +0200, Stefan Roellin wrote:
>>The current implementation/patch now has a disadvantage: if you print to a
>>postscript target, the image has to be exported TWICE: once for the 'print
>>preview widget' (with alpha) and once for the postscript target (without
>>alpha). This is certainly not optimal regarding memory consumption.
>I have attached a patch to the bug report that outlines a way to work
>around this problem.
>>If yes, a solution could be to not distinguish between a Postscript and a
>>PDF target (i.e. to embed only opaque images into a PDF despite the fact
>>that PDF can handle images with alpha values).
>Would this approach have any disadvantages?
It pretty much doesn't matter what you can do with a PDF target, so long
as there is still the ability to directly print as PostScript and save
as EPS/PS. Should an image be intended for print, then there would be no
harm in dumping alpha and using opaque. Someone may want to actually
further edit an image, in which case a PDF losing alpha would be a
disadvantage...but PDF is the wrong format for this anyway (most of the
PDF editing tools out there are junk, set with features to sell a
product that breaks if you mix it with the wrong situation).
The up side to only embedding opaque is easier maintenance, common code
set, etc. Quite likely it would result in better reuse of code.
If you want a final answer, you're going to have to know who uses alpha
in a PDF which is intended to be in its final form, and not as an
intermediate product of editing. Newer PDF formats have a lot of
features which barely anyone uses...when they are used, I see it for
interactive purpose, not for print.
D. Stimits, stimits AT comcast DOT net
Gimp-developer mailing list