I have tried to produce pdf documents either with blue text or embedding a svg graphic with blue color in it (#0000FF, or rgb(0,0,255)), but this color does not render correctly. However, when the embedding option is removed, blue text does fine within the 'color' option in the fo/xsl document.
Can you try with 0.95beta and see if the problem persists? (possible duplicate of Bug #43274)
(In reply to comment #1) > Can you try with 0.95beta and see if the problem persists? (possible duplicate > of Bug #43274) > I hve tried with 0.95beta and nothing changes.
Please attach an FO file that demonstrates the problem. I can't reproduce the problem with your description alone. Furthermore, can you elaborate on what you mean by "does not render correctly"?
Created attachment 22043 [details] SVG file with blue text and an opaque box
Created attachment 22044 [details] FO file to embed the SVG document (named email.svg)
Hello FOP community I have checked the problem again (Bug #45027) and actually this problem resides in the SVG document. When the ‘opacity’ attribute (with a value less than 1) is included in a determinate shape element, this affects the color of the text, even if such text lies outside the shape range. That is what I mean ‘does not render correctly’. As an example, I attached a SVG file with blue text and a rect element with an opacity attribute less than one. If you embed this with a FO/XSL file, the text won’t be blue anymore. Perhaps this issue belongs to the ‘SVG Component’, but it is up to you to decide this...
Thanks for the test files. I can now reproduce the effect. This is really strange. What I can tell you is that the text painting code in PDF doesn't change if I remove the opacity from the rectangle being painted AFTER the text. But what's important to note is that I've seen the effect only on Acrobat 8 but not on Acrobat 5 or GhostScript/GhostView. At the moment I have absolutely no clue why this happens. I'm attaching the two PDF files (with compression turned off) to demonstrate the difference. Maybe someone could check if the effect occurs on other Acrobat versions like 6 or 7 and report back here. As a side-note: It's a bit strange that Batik paints the transparent rectangle as a bitmap as this is such a simple element. That could probably be improved somehow. That accounts for the increase in size when opacity is turned used, but it doesn't explain why the text color changes to a darker blue. There's also an inconsistency about how the coordinate system for the rectangle is set up between the two variants. But again, this doesn't account for the color change.
Created attachment 22056 [details] Uncompressed PDF without opacity
Created attachment 22057 [details] Uncompressed PDF with opacity
(In reply to comment #7) > Thanks for the test files. I can now reproduce the effect. This is really > strange. What I can tell you is that the text painting code in PDF doesn't > change if I remove the opacity from the rectangle being painted AFTER the text. > But what's important to note is that I've seen the effect only on Acrobat 8 but > not on Acrobat 5 or GhostScript/GhostView. At the moment I have absolutely no > clue why this happens. I'm attaching the two PDF files (with compression turned > off) to demonstrate the difference. Maybe someone could check if the effect > occurs on other Acrobat versions like 6 or 7 and report back here. > > As a side-note: It's a bit strange that Batik paints the transparent rectangle > as a bitmap as this is such a simple element. That could probably be improved > somehow. That accounts for the increase in size when opacity is turned used, > but it doesn't explain why the text color changes to a darker blue. There's > also an inconsistency about how the coordinate system for the rectangle is set > up between the two variants. But again, this doesn't account for the color > change. > Actually I realized this problem when I printed a document using Acrobat 5, (the blue was not printed correct). As you said, in the screen of Acrobat 5 the blue renders accurate but it doesn't in the printer. Acrobat 8 is in this sense ‘more WYSIWYG’.
(In reply to comment #7) > Thanks for the test files. I can now reproduce the effect. This is really > strange. What I can tell you is that the text painting code in PDF doesn't > change if I remove the opacity from the rectangle being painted AFTER the text. > But what's important to note is that I've seen the effect only on Acrobat 8 but > not on Acrobat 5 or GhostScript/GhostView. At the moment I have absolutely no > clue why this happens. I'm attaching the two PDF files (with compression turned > off) to demonstrate the difference. Maybe someone could check if the effect > occurs on other Acrobat versions like 6 or 7 and report back here. > > As a side-note: It's a bit strange that Batik paints the transparent rectangle > as a bitmap as this is such a simple element. That could probably be improved > somehow. That accounts for the increase in size when opacity is turned used, > but it doesn't explain why the text color changes to a darker blue. There's > also an inconsistency about how the coordinate system for the rectangle is set > up between the two variants. But again, this doesn't account for the color > change. jeremias, does this bug need to stay in the needinfo state, or should it be moved to resolved?
Well, the bug is on NEEDINFO because what happens here is not understood, yet. If anything, this marks a known problem but IMO it shouldn't be closed.
resetting P2 open bugs to P3 pending further review
issue happens with Adobe X 10.1.3 on the Mac, does not happen with Mac's own Preview. seems an Adobe issue to me, just like the dull colors issue.