[ 
https://issues.apache.org/jira/browse/PDFBOX-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039898#comment-14039898
 ] 

John Hewson commented on PDFBOX-2153:
-------------------------------------

{quote}
this is so "80ies"
{quote}

That made me laugh :)

Yes, I use the IntelliJ plugin for SVN, it adds a gutter next to each line 
labelling its commit. GitHub's "history" view is also very useful.

{quote}
What will happen with the transition to the next "must have" versioning system?
{quote}

Alternatively, what happens when we move to the next "must have" issue tracking 
system?

Fortunately we now live in the future where loosing the history isn't necessary 
(if indeed it ever was) because of tools like 
[git-svn|http://git-scm.com/book/en/Git-and-Other-Systems-Git-and-Subversion]. 
Given that CVS can be migrated to SVN I don't understand why all the 
sourceforge commits were lost in the first place - it was a long time ago.

> 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, 2.0.0
>            Reporter: Tilman Hausherr
>              Labels: shading, shadingpattern
>
> 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)

Reply via email to