Sven Neumann wrote:

>Hi,
>
>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
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Reply via email to