View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0011065||Scribus||Graphics / Image Frames||public||2012-09-06 19:24||2012-09-07 21:11|
|Summary||0011065: PNGs with transparency print incorrectly|
|Description||When placing in fact any transparent image into an ImageFrame, the image when printed may have some combination of issues. The first is the inclusion of a black background in all places where tranparency is expected. The second is displaced image segments appearing in areas where transparency is expected. The third is displaced transparency clipping the image with transparency in unexpected areas. The images are being prepared in GIMP 2.0 for Windows.|
|Tags||No tags attached.|
||It appears the alpha channel is being ignored in the print operation. Black without transparency appears to be the reason for seeing black. Printing to PDF exhibits only this effect. Paper printing exhibits all issues.|
Further, following a hunch, it appears this behaviour is related to image size, beyond which, transparency handling fails. I took an image that was rendering correctly and tripled its resolution. The result was a blackened background on what was an otherwise correctly performing image.
||Having reverted the upsized image and recovered to a drawable state I would like to upgrade this to Reproducible: Always|
please try to create a PDF 1.4 and print it through acrobat reader...
you have to make sure that your whole workflow support transparencies, and i'm not sure that printing directly from scribus supports it.
Is there a good way of knowing when a workflow supports certain features like this? It seemed like there were several things going on, possibly incorrect indexing when reading the image data as well as the transparency or lack of it. I have found a way around this issue, that I was using a PDF printer rather than the built-in export to PDF feature (completely missed it.) Using PDF export and printing from Acrobat has worked out to be a solid solution.
i wonder if the preflight verifier should not warn if there are images with transparencies...
i think it's worth to check if there is a feature request for it...
||Basically Windows print system is far from what PDF transparency features allows. Also almost all PDF 'printers" use Postscript as an intermediate language, language which does not support transparency at all... By consequence for printing PDF transparencies on Windows, one need a transparency flattener for circumventing Windows printing system capabilities. This is a feature request which is already logged as issue 0000876. This task is however the most complex we have on the bug tracker (1 year project at least and involves lots of research). Currently the only apps i know which have a decent transparency flattener are Adobe apps and Quark's. So as ale mentionned it, the best results will be achieved by exporting a PDF and printing it from Acrobat Reader or Acrobat Pro.|
|2012-09-06 19:24||jilbruke||New Issue|
|2012-09-06 19:36||jilbruke||Note Added: 0028908|
|2012-09-06 19:43||jilbruke||Note Added: 0028909|
|2012-09-06 19:44||jilbruke||Note Edited: 0028909|
|2012-09-06 19:49||jilbruke||Note Added: 0028910|
|2012-09-07 12:06||ale||Note Added: 0028916|
|2012-09-07 14:30||jilbruke||Note Added: 0028918|
|2012-09-07 21:06||ale||Note Added: 0028919|
|2012-09-07 21:11||jghali||Note Added: 0028920|
|2012-09-07 21:11||jghali||Relationship added||duplicate of 0000876|
|2012-09-07 21:11||jghali||Status||new => resolved|
|2012-09-07 21:11||jghali||Resolution||open => duplicate|
|2012-09-07 21:11||jghali||Assigned To||=> jghali|
|2012-09-07 21:11||jghali||Status||resolved => closed|
|2015-09-17 20:10||Kunda||Category||Graphics / Image Frames => Graphics/Img Frames|
|2015-09-17 20:11||Kunda||Category||Graphics/Img Frames => Graphics / Image Frames|