Re: [Gimp-developer] Print plugin
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? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Solving Bug 356716 – GimpZo omPreview is broken in some plug-ins
Hi, On Thu, 2007-07-19 at 11:52 +0300, Aurimas Juška wrote: * jigsaw -- looks like lot of code would have to be changed to make it work with GimpZoomPreview correctly. However, I don't understand why this plug-in would need zoom preview at all. It doesn't do anything that someone would like to check at high zoom level. My suggestion: use GimpPreview instead. You probably mean GimpDrawablePreview as GimpPreview is abstract. I agree that it is probably best to go back to a simple scrollable preview for this plug-in. * polar, whirlpinch -- both need fetching pixels. Of course, it's possible to ask core to scale down some part, but I don't think we would like to do that for each pixel. Efficient solution would be to scale small regions (tiles) and cache them. For example, lens is doing that. However, it is not very easy to implement (or copy paste from somewhere) such functionality and I think such functionality should be provided by core. The core does the scaling quite efficiently. So unless it turns out to be a performance problem, I don't see any need to add complex caching to the plug-ins. If at all, this should be done in the GimpZoomPreview itself and we can leave that to be done for the time after 2.4. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
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
Re: [Gimp-developer] Print plugin
Sven Neumann wrote: Hi, On Sun, 2007-07-22 at 14:43 -0600, D. Stimits wrote: For me, it is a serious problem. I work in the print industry, typically creating PostScript drivers. The PS output is quite good quality, and every conversion generally suffers serious quality issues. Gimp is one of the best tools available for UNIX side PostScript. Photoshop and some other tools, despite being Adobe products, tend to break standards compliant high end print systems (most of those products work great so long as you don't mix them with other people's products, then they suck...gimp PS works flawlessly with all of the certified systems). As soon as you start making PDF-to-PostScript conversions or PostScript-to-PDF-to-PostScript, the output is hopeless. Don't do it. We are talking about the new Print plug-in here, not about the plug-in that is used to save an image as a Postscript file. So your concerns are probably not valid. Yes and no. The PostScript which I have to slice-and-dice is from save as, but all of the printers involved are PostScript printers. Some can handle PDF, others cannot. If I were to print a high res image on a quality printer (definitely not some ink jet from the local store), it'd be rare that any conversion process would leave the quality in tact. The only time exporting a transparency is a problem is if you plan to print on some sort of custom paper that isn't plain white, but then there should be a background color anyway. With an exception that is irrelevant, there are no printers with transparent ink (that exception being in the dye sublimation, but the transparent ink is a coating for longevity, and has no knowledge of any alpha channel). Show me a printer takes advantage of mixing transparent inks, taking advantage of an alpha channel, and I'll agree that there is a reason to not export to a non-transparent color space. On the other hand, every single printer out there which handles PostScript natively (and there is no such thing as a good PCLprinter, even if it emulates PostScript) will suffer by removing direct PostScript output. I do indeed print directly from gimp without an intermediate step, as proofs and other samples going to a quality PostScript printer are best done from gimp...some of the other products are known to crash printers under some images, gimp never does this, it's the only really stable program for that purpose (all of these printers are Adobe certified, the low end systems start at about $10k, the I-Gen systems range from over $100k on up...which Adobe products tend to crash). Being able to take advantage of a PPD file during print from gimp is very useful, and I print directly from gimp daily. A PDF conversion would ruin this, so I'm in the opposite position by having a real PostScript system. So I pose this question...if print via PDF is to be considered, why remove the existing PS system, which is pretty much the best quality PostScript among all of the apps (commercial and free)? There isn't any reason to not add a PDF print preference, but PDF language is not intended as a print language, it is a document interchange format, and should not be converted to this format until interchange is needed. A preference could easily be set if both formats are available, but there is a genuine need for real PostScript output in the non-windows world. I don't want to hand craft save-as-eps files for specific hardware every time someone wants a sample print, just so I can keep the image quality. I really don't understand why anyone would want to remove PostScript print options instead of adding PDF to it, especially since much of the PostScript code directly translates to PDF code. 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
