Skip navigation
James Quirk
James Quirk
Currently Being Moderated

possible transparency bug in Linux AR8.1.x

Dec 31, 2007 5:45 AM

The following test PDF:

http://www.amrita-cfd.org/4adobe/trans/test.pdf

suggests that there might be a problem with transparency under
Linux AR8.1.x . It is a two page document where page 1 is a blank coloured
page and page 2 is the same blank coloured page with the addition of
a single png image containing transparency. There is a marked difference
in the page colours between page 1 and page 2. Page 1 appears
as #505050 and Page2 appears as #021518. Now there is no difference
when the document is viewed using AR8.1.1 under windows XP,
nor when viewed with xpdf . Hence this posting.

The test PDF was generated using the LaTeX file:

http://www.amrita-cfd.org/4adobe/trans/test.tex

with the PNG file:

http://www.amrita-cfd.org/4adobe/trans/trans.png

it is a green square (#ff0000) with a square transparent cutout.

After looking inside the PDF (generated using pdftex 1.40.3-2.2)
it looks like the /SMask for the png image is affecting the
whole page. For instance, one can comment out "/Im1 Do" from the page
stream, to suppress the png image, and the color for page 2 is still
affected. On the other hand, if the /SMask is commented out of
the png's /XObject then the png is drawn without transparency (the cutout
appears as a red square) and the color for page 2 is correct.
I havn't yet fully digested the PDF Reference to know whether
AR is at fault or pdftex is generating erroneous PDF.

Any guidance that can be offered on this matter would be gratefully
appreciated.

Thanks,

James Quirk
792 Views   3 Replies   Latest reply: (shinoj), Dec 11, 2008 9:44 PM
 
Replies
  • Currently Being Moderated
    1. (Leonard_Rosenthol),
    Dec 31, 2007 7:05 AM   in reply to James Quirk
    Report
    It's not that the PDF is erroneous - it's a perfectly valid PDF. However, it isn't taking into account the fact that when transparency is present, Acrobat (as per the PDF Reference) uses a different "path" to rendering that involves an "transparency blending space". By default, that space is DeviceCMYK and thus your RGB colors are being converted to CMYK when rendered.

    If pdfTeX were to add a /Group dictionary to any page containing transparency and specify in there to use /DeviceRGB instead as the blending space - your colors wouldn't shift.

    Leonard Rosenthol
    Adobe Systems
     
    |
    Mark as:
  • James Quirk
    Currently Being Moderated
    2. James Quirk,
    Dec 31, 2007 7:30 AM   in reply to James Quirk
    Report
    Leonard,

    Thanks for your quick response. I've forwarded it on
    to the pdftex newsgroup and hopefully a suitable patch
    will make it into the next pdftex release. As I admitted
    in my post, I've not yet managed to digest the relevant
    sections from the PDF Reference that deal with transparency
    and so my understanding on that topic is clearly incomplete.

    Sorry for troubling you,

    James
     
    |
    Mark as:
  • Currently Being Moderated
    3. (shinoj),
    Dec 11, 2008 9:44 PM   in reply to James Quirk
    Report
    Iam also facing issue where i have a CMYK image where transparency is enabled. But it is not working properly, while in the case of a RGB image with transparency enabled, the transparency works fine
    Iam using the filter /DCTDecode for decoding the image in both cases
    What could be the possible reason for this?
     
    |
    Mark as:
Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)