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