sschwieb edited a comment on pull request #127: URL: https://github.com/apache/pdfbox/pull/127#issuecomment-894871845
I did some testing, with rendering the PDFs linked in [PDFBOX-4718](https://issues.apache.org/jira/browse/PDFBOX-4718) and [PDFBOX-4743](https://issues.apache.org/jira/browse/PDFBOX-4743) via the `PDFDebugger`. By overriding `transferClip` as ``` protected void transferClip(PDGraphicsState graphicsState, Graphics2D graphics) { List<GeneralPath> paths = graphicsState.getCurrentClippingPaths(); boolean allDone = true; for (GeneralPath path : paths) { if (!path.getPathIterator(null).isDone()) { allDone = false; break; } } if (allDone) { // PDFBOX-4821: avoid bug with java printing that empty clipping path is ignored by // replacing with empty rectangle, works because this is not an empty path graphics.setClip(new Rectangle()); return; } GeneralPath first = paths.get(0); graphics.setClip(first); for (int i = 1; i < paths.size(); i++) { graphics.clip(paths.get(i)); } } ``` , the OOM that occurred in the 1st PDF disappears, and the 2nd PDF is rendered much faster (still needs several seconds though). It seems that `SunGraphics2D.clip()` is doing a much better job than `Area.intersect()`. If it turns out that this is always the case, maybe the remaining calls to `getCurrentClippingPath()` could be refactored as well - but I haven't looked into that yet, can't tell. DYT it's worth to refactor `PageDrawer` and `PDGraphicsState`, to allow users to customize how the clip is transferred to the graphics? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
