[
https://issues.apache.org/jira/browse/PDFBOX-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15807569#comment-15807569
]
Tilman Hausherr edited comment on PDFBOX-3000 at 1/15/17 2:59 PM:
------------------------------------------------------------------
I found out from Boris Aronshtam and Dr. Paul Jones why the blending files
don't render properly:
http://www.pdfvt.com/PDFVT_TransparencyGuide.html
{quote}
It is wrong to treat the page background as a separate color. Page background
is not a color, but the unmarked space.
...
blending with the background ignores the blend mode, and is equivalent to
blending with BM=Normal against the opaque white color.
{quote}
We use a white page background, and we don't know about "unmarked space". Java
does not have such a concept AFAIK. Doing a "Screen" blend against white
background brings a white result.
The attached file gs-bugzilla689931_reduced-ScreenBlendPageBackground.pdf shows
a small white rectangle in a blue rectangle with Adobe Reader. The white area
is because I filled a white rectangle there; in the rest I did nothing thus the
difference. PDFBox treats all as white background so it displays the whole PDF
as white. Adobe treats the outside as "unmarked space" so it just copies and
the inside as "white" so the screen blend result is white.
Mitigation:
- most files have "Multiply" blend mode which doesn't bring this effect
- most files wouldn't use any "interesting" blend modes against the paper
background because it wouldn't make any difference
Update 15.1.2017:
It is even weirder. In the blend demo file by Boris Aronshtam one can see that
blue on orange in blend mode "ColorDodge" produces an orange result with Adobe
and a pink result with PDFBox. I did the calculations (source: 0 0 1, dest: 1
0.7 0, result: 1 0.7 1) and pink is correct. The only explanation why Adobe
shows it as orange would be that the 0 in the 1 0.7 0 orange destination is
also considered to be "undefined" and is to stay as it is. To test this, I
tried rendering on a slightly modified orange background, i.e. 1 0.7 0.01. Now
the Adobe result is also pink.
was (Author: tilman):
I found out from Boris Aronshtam and Dr. Paul Jones why the blending files
don't render properly:
http://www.pdfvt.com/PDFVT_TransparencyGuide.html
{quote}
It is wrong to treat the page background as a separate color. Page background
is not a color, but the unmarked space.
...
blending with the background ignores the blend mode, and is equivalent to
blending with BM=Normal against the opaque white color.
{quote}
We use a white page background, and we don't know about "unmarked space". Java
does not have such a concept AFAIK. Doing a "Screen" blend against white
background brings a white result.
The attached file gs-bugzilla689931_reduced-ScreenBlendPageBackground.pdf shows
a small white rectangle in a blue rectangle with Adobe Reader. The white area
is because I filled a white rectangle there; in the rest I did nothing thus the
difference. PDFBox treats all as white background so it displays the whole PDF
as white. Adobe treats the outside as "unmarked space" so it just copies and
the inside as "white" so the screen blend result is white.
Mitigation:
- most files have "Multiply" blend mode which doesn't bring this effect
- most files wouldn't use any "interesting" blend modes against the paper
background because it wouldn't make any difference
> Transparency Group issues
> -------------------------
>
> Key: PDFBOX-3000
> URL: https://issues.apache.org/jira/browse/PDFBOX-3000
> Project: PDFBox
> Issue Type: Bug
> Components: Rendering
> Affects Versions: 2.0.0
> Reporter: John Hewson
> Fix For: 2.1.0
>
> Attachments: 007087-payment-due-p58_reduced2.pdf, blendmodes.pdf,
> BlendModes-rgb.pdf, circle-simple.pdf, ds-firewall-enterprise-p1_reduced.pdf,
> gs-bugzilla689309-reduced-bc0.pdf, gs-bugzilla689309-reduced-bc1.pdf,
> gs-bugzilla689309-reduced.pdf, gs-bugzilla689931_reduced-Multiply.pdf,
> gs-bugzilla689931_reduced-ScreenBlendPageBackground.pdf,
> gs-bugzilla689931_reduced-Screen.pdf, gs-bugzilla690022_reduced.pdf,
> gs-bugzilla690022-reduced-rotations.pdf, gs-bugzilla691157_mod_unc.pdf,
> gs-bugzilla691157_mod_unc.png, gs-bugzilla691157.pdf, gs-bugzilla691348.pdf,
> gs-bugzilla691650-2.pdf, gs-bugzilla692217_reduced.pdf,
> gs-bugzilla693322_reduced.pdf, gs-bugzilla694556-3.pdf,
> gs-bugzilla695354.pdf, gs-bugzilla695582-transparency-fill-stroke.pdf,
> gs-bugzilla695582-transparency-fill-stroke.pdf-1.png,
> PDFBOX-1697-reduced-rotations.pdf, PDFBOX-2182_mod.pdf,
> PDFBox3359PanelTestEnhanced.java, PDFBOX-3400-RGB.pdf,
> PDFBOX-3494_reduced_cropX.pdf, PDFBOX-3494_reduced.pdf, PDFBOX-3564-Mask.pdf,
> PDFJS-2845-p1.pdf, PDFJS-5526-p13_reduced1.pdf, PDFJS-5526-p13_reduced2.pdf,
> PDFJS-5526-p13_reduced3-nogroup.pdf, PDFJS-5811-2-p3_reduced4.pdf,
> PDFJS-5811-2-p3_reduced.pdf, PDFJS-5811-2-p4_reduced-rotations.pdf,
> PDFJS-5811-2.pdf, PDFJS-5853_reduced.pdf,
> PDFJS-6967_reduced_outside_softmask.pdf,
> samsung_galaxy_s_4_um-p1_reduced.pdf, snowman-nose-gradient.pdf,
> snowman-nose-gradient-rgb.pdf,
> snowman-nose-gradient-rgb_reduced-0.6-bad2.pdf,
> snowman-nose-gradient-rgb_reduced-0.7-good2.pdf,
> snowman-nose-gradient-screenshot-comparison-11.12.2016.jpg,
> snowmen-opacity-clipping-masks-2.0.3.png,
> snowmen-opacity-clipping-masks-2.1.0-SNAPSHOT-2016-12-07.png,
> snowmen-opacity-clipping-masks-2.1-SNAPSHOT-10.12.2016.png,
> snowmen-opacity-clipping-masks-adobe-illustrator.png,
> snowmen-opacity-clipping-masks.pdf, SoftMask-Clipped.pdf, SoftMask.pdf,
> softmask-rewrite-alt1.patch, softmask-rewrite.patch
>
>
> This is a follow-up issue for transparency group issues from PDFBOX-2423.
> More details to come.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
