[
https://issues.apache.org/jira/browse/PDFBOX-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236485#comment-17236485
]
Tres Finocchiaro edited comment on PDFBOX-5022 at 11/20/20, 10:34 PM:
----------------------------------------------------------------------
[~tilman] I had just assumed it was some type of circular reference, but I
don't know the PDF specification well enough to understand.
Slightly off-topic, but in regards to the out-of-memory stuff, is there a way
(perhaps through an enhancement) to ignore the
transparency-forces-rasterization behavior? As the printers get higher and
higher quality, this can really be a detriment.
Assuming this request is preposterous, could this be (easily) done
programmatically using the API, so that downstream care can be taken to avoid
transparency-forced rasterization at all costs? This technique may be common
for some (e.g. manuals , brochures), but it's very rare for others (e.g.
reports, labels, folios, invoices) and having control over this would help
guard the memory issues, albeit downstream.
was (Author: tresf):
[~tilman] I had just assumed it was some type of circular reference, but I
don't know the PDF specification well enough to understand.
Slightly off-topic, but in regards to the out-of-memory stuff, is there a way
(perhaps through an enhancement) to ignore the
transparency-forces-rasterization behavior? As the printers get higher and
higher quality, this can really be a detriment.
Assuming this request is preposterous, could this be (easily) done
programmatically using the API, so that downstream care can be taken to avoid
transparency-forced rasterization at all costs? This technique may be common
for some (e.g. manuals , brochures), but it's very rare for others (e.g.
reports, labels, folios, invoices) and having control over this would help
guard the memory issues.
> Recursion is too deep
> ---------------------
>
> Key: PDFBOX-5022
> URL: https://issues.apache.org/jira/browse/PDFBOX-5022
> Project: PDFBox
> Issue Type: Bug
> Components: Rendering
> Affects Versions: 2.0.21
> Reporter: Tres Finocchiaro
> Priority: Major
> Attachments: crash_pdf.pdf
>
>
> *OS:* Windows 10 x86_64
> *Java:* 1.8.0u271 x86_64
> The attached A4 PDF is created with TCPDF 6.2.26.
> * At 600dpi, the attached PDF prints over > 4GB (-Xmx4096m) heap and crashes
> the JVM.
> * At 300dpi, the attached PDF prints under 2GB (-Xmx2048m) heap but shows
> the following warning(s).
> Google Chrome and Adobe can print this PDF without issue. The crash only
> occurs using PDFBOX.
> * Calling "*PDFDebugger*" does NOT crash the JVM.
> * Calling "*PrintPDF*" DOES crash the JVM.
> For reference, the public mailing list where this was reported:
> [https://groups.google.com/g/qz-print/c/REV9fP3rqeM/m/OW1Gf2QZBQAJ]
>
> {code:java}
> Nov 19, 2020 10:53:46 PM
> org.apache.pdfbox.contentstream.operator.graphics.DrawObject process
> SCHWERWIEGEND: recursion is too deep, skipping form XObject
> Nov 19, 2020 10:53:46 PM
> org.apache.pdfbox.contentstream.operator.graphics.DrawObject process
> SCHWERWIEGEND: recursion is too deep, skipping form XObject
> Nov 19, 2020 10:53:47 PM
> org.apache.pdfbox.contentstream.operator.graphics.DrawObject process
> SCHWERWIEGEND: recursion is too deep, skipping form XObject{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
