You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@pdfbox.apache.org by Joshua <jo...@gmail.com> on 2026/06/03 07:13:29 UTC
Re: High object numbers trigger OOME during save operation
Hi,
https://javadoc.io/static/org.apache.pdfbox/pdfbox/3.0.7/org/apache/pdfbox/pdfwriter/compress/Compr…
<https://javadoc.io/static/org.apache.pdfbox/pdfbox/3.0.7/org/apache/pdfbox/pdfwriter/compress/CompressParameters.html#CompressParameters-int->
I understood the int constructor like the amount of objects (= the number
of xrefs) were limited to 200 by default.
What would be a rational value for a compression with as less quality loss
as possible? Would you advise to use the default value even for large PDFs
with high resolution images?
Joshua
Joshua <jo...@gmail.com> schrieb am Do., 28. Mai 2026, 11:08:
> Hi,
>
> We will upgrade to the PDFBox 3.0.7 and see if the problem still occurs.
> Though, I could not find any code changes that would prevent this from
> happening.
>
> By saving the PDF using compressed object streams, do you mean calling the
> save method without compression parameters? As far as I understand the
> docs, this would limit the amount of objects beeing saved, meaning the
> saved PDF would be missing content. Please correct me, if I'm wrong.
>
> Best regards,
> Joshua
>
Re: High object numbers trigger OOME during save operation
Posted by Andreas Lehmkühler via users <us...@pdfbox.apache.org>.
Am 03.06.26 um 09:13 schrieb Joshua:
> Hi,
>
> https://javadoc.io/static/org.apache.pdfbox/pdfbox/3.0.7/org/apache/pdfbox/pdfwriter/compress/Compr…
> <https://javadoc.io/static/org.apache.pdfbox/pdfbox/3.0.7/org/apache/pdfbox/pdfwriter/compress/CompressParameters.html#CompressParameters-int->
>
> I understood the int constructor like the amount of objects (= the number
> of xrefs) were limited to 200 by default.
This is the maximum number of object per object stream. I don't see any
need to make this configurable.
> What would be a rational value for a compression with as less quality loss
> as possible? Would you advise to use the default value even for large PDFs
> with high resolution images?
Another misunderstanding ;-)
This is not about image compression. It is all about the compression of
text. It is done lossless, so that there is no need for any kind of
compression quality value.
To sum it up, you won't loose anything when using object stream compression
>
>
> Joshua
>
> Joshua <jo...@gmail.com> schrieb am Do., 28. Mai 2026, 11:08:
>
>> Hi,
>>
>> We will upgrade to the PDFBox 3.0.7 and see if the problem still occurs.
>> Though, I could not find any code changes that would prevent this from
>> happening.
>>
>> By saving the PDF using compressed object streams, do you mean calling the
>> save method without compression parameters? As far as I understand the
>> docs, this would limit the amount of objects beeing saved, meaning the
>> saved PDF would be missing content. Please correct me, if I'm wrong.
>>
>> Best regards,
>> Joshua
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: users-help@pdfbox.apache.org
Re: High object numbers trigger OOME during save operation
Posted by Joshua <jo...@gmail.com>.
Hi,
Thanks again for clarifying. As I'm not a PDF expert, this was a little
confusing to me. Maybe you can further elaborate this in the java doc
sometime in the future ;)
We will apply your suggestions and let you know whether it worked once we
received feedback.
Best regards,
Joshua
Joshua <jo...@gmail.com> schrieb am Mi., 3. Juni 2026, 09:13:
> Hi,
>
>
> https://javadoc.io/static/org.apache.pdfbox/pdfbox/3.0.7/org/apache/pdfbox/pdfwriter/compress/Compr…
> <https://javadoc.io/static/org.apache.pdfbox/pdfbox/3.0.7/org/apache/pdfbox/pdfwriter/compress/CompressParameters.html#CompressParameters-int->
>
> I understood the int constructor like the amount of objects (= the number
> of xrefs) were limited to 200 by default.
>
> What would be a rational value for a compression with as less quality loss
> as possible? Would you advise to use the default value even for large PDFs
> with high resolution images?
>
>
> Joshua
>
> Joshua <jo...@gmail.com> schrieb am Do., 28. Mai 2026, 11:08:
>
>> Hi,
>>
>> We will upgrade to the PDFBox 3.0.7 and see if the problem still occurs.
>> Though, I could not find any code changes that would prevent this from
>> happening.
>>
>> By saving the PDF using compressed object streams, do you mean calling
>> the save method without compression parameters? As far as I understand the
>> docs, this would limit the amount of objects beeing saved, meaning the
>> saved PDF would be missing content. Please correct me, if I'm wrong.
>>
>> Best regards,
>> Joshua
>>
>