[
https://issues.apache.org/jira/browse/PDFBOX-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr resolved PDFBOX-2153.
-------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0
1.8.7
Assignee: Tilman Hausherr
> Setting the correct clipping path for shading
> ---------------------------------------------
>
> Key: PDFBOX-2153
> URL: https://issues.apache.org/jira/browse/PDFBOX-2153
> Project: PDFBox
> Issue Type: Bug
> Components: Rendering
> Affects Versions: 1.8.5, 1.8.6, 1.8.7, 2.0.0
> Reporter: Tilman Hausherr
> Assignee: Tilman Hausherr
> Labels: shading, shadingpattern
> Fix For: 1.8.7, 2.0.0
>
>
> While doing tests with the file eci_altona-test-suite-v2_technical_H.pdf
> (uncompressed) of PDFBOX-1915 I noticed that by removing a "W" (modifies the
> clipping region) operator of a type 7 shading I got a lot more correct
> shadings (type 6 and lower). It looked like PDFBox had been using the
> clipping of the type 7 when drawing the type 6, which is just a rectangle
> above in that rendering. This resulted in a blank.
> By adding
> {code}
> graphics.setClip(getGraphicsState().getCurrentClippingPath());
> {code}
> in PageDrawer.shfill() just before the graphics.fill() I get several files to
> render correctly that I hadn't before.
> (Setting null will probably do the same, didn't test that yet).
> The following PDFs are rendered correctly with the change:
> McAfee-ShadingType7.pdf
> eci_altona-test-suite-v2_technical_H.pdf
> crestron-p9.pdf (these three found in PDFBOX-1915)
> PDFBOX-1451.pdf ("alfresco")
> PDFBOX-1940.pdf ("chart")
> PDFBOX-1861-tracemonkey.pdf p.11
> Not solved by the change:
> PDFBOX-2098-asyTUG.pdf p.6 (this one doesn't use shfill)
> PDFBOX-1861-tracemonkey.pdf p.6 (not shading)
> PDFBOX-1416.pdf (not shading)
> texample-rgb-triangle.pdf (John has an explanation about that one)
> WDYT? Is there any reason NOT to set the clipping path in PageDrawer.shFill()
> ?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
