Stirling-PDF icon indicating copy to clipboard operation
Stirling-PDF copied to clipboard

[Bug]: XREF Table Error in Output PDFs

Open OteJlo opened this issue 5 months ago • 4 comments

Installation Method

Docker fat

The Problem

Hello,

I have encountered a problem with Stirling PDF where the output PDF often contains an XREF table error. This happens frequently after editing PDFs via Stirling PDF, I haven't tested all the tasks, but all the ones I've used generate this issue (like cropped, rearranged, layoutChanged, singlePage, etc...).

The resulting PDF triggers a repair prompt in PDF-XChange Editor, and Adobe Acrobat automatically repairs the file upon opening. This suggests the generated PDF may not fully comply with the PDF specification regarding the cross-reference table.

Could you please investigate this?

Thanks a lot for your great work on this project!

Version of Stirling-PDF

1.0.2

Last Working Version of Stirling-PDF

No response

Page Where the Problem Occurred

No response

No Duplicate of the Issue

  • [x] I have verified that there are no existing issues raised related to my problem.

OteJlo avatar Jul 10 '25 12:07 OteJlo

Hi can you share a example PDF for this?

Frooodle avatar Jul 10 '25 19:07 Frooodle

Hello, yes for example, a random PDF:

sample-1.pdf

After scaling:

sample-1_scaled.pdf

OteJlo avatar Jul 11 '25 09:07 OteJlo

Hi,

Regarding this issue, I saw it's assigned and was curious, so I did some debugging around the xref inconsistency.

To reproduce and investigate, I added a line in CropController.java to save an empty file via PDFBox:

PDDocument doc = new PDDocument(); doc.save("debug/empty_test.pdf"); doc.close();

Then I ran qpdf --show-xref on:

  • the original input file (sample-1.pdf),
  • the cropped output (sample-1_cropped.pdf), and
  • the empty test file.

Turns out the original file is fine, but when processed through PDFBox (even without doing any actual page content editing), the output can trigger this xref trailer mismatch warning in qpdf.

There’s also a related open issue on PDFBox side:
https://issues.apache.org/jira/browse/PDFBOX-5561

From what I can tell, it may be due to PDFBox not updating the /Size field correctly in some cases.

Just wanted to share this in case it's helpful context. Curious to hear how you'd prefer to handle this — whether you'd like to mark this as an upstream PDFBox limitation or approach it differently.

Thanks!

PingLin8888 avatar Jul 31 '25 12:07 PingLin8888

Here is my sample pdf & same issue logged at #2006

Same problem in versions 1.02, 1.1, 1.2

solution was suggested by @iib0011 https://github.com/Stirling-Tools/Stirling-PDF/issues/2006#issuecomment-2403551306

to change to: document.save(baos, CompressParameters.NO_COMPRESSION); & reference: https://stackoverflow.com/questions/68634216/pdfxchange-errors-detected-in-the-xref-table-after-pdfbox-modifcation/71159599#71159599

Can you implement this change to test?

STIRLINGPDF_SAMPLE_FORM.pdf

samsong avatar Aug 28 '25 13:08 samsong