R help - Oct 2024 - Warning object has offset 0. PDF file

Good day to all

Using 
> library(pdftools)
Using poppler version 23.04.0

I get a number of warnings such as:
> pdf_subset(infile, pages = 156:157, output = outfile)
WARNING: /Users/jla/Library/CloudStorage/Dropbox/7cordas/Caio/record/90 NEW RODA
SONG BOOK.pdf (object 7 0): object has offset 0
WARNING: /Users/jla/Library/CloudStorage/Dropbox/7cordas/Caio/record/90 NEW RODA
SONG BOOK.pdf (object 175 0): object has offset 0
WARNING: /Users/jla/Library/CloudStorage/Dropbox/7cordas/Caio/record/90 NEW RODA
SONG BOOK.pdf (object 254 0): object has offset 0

This does not prevent from getting the pages extracted properly and written to a
pdf file which is readable. Aging is probably the cause of my irritation with
such warnings.

 I assume there is a problem with the source pdf file which was assembled by
music amateurs using various sources.

My question maybe out of the scope of this list is:

How can I detect and potentially correct using appropriate open source software
what is wrong with the pdf file.
I am on macos.

Thanks for any pointers and best wishes, Jean-Louis

? Sun, 13 Oct 2024 12:45:36 +0200
"Jean-Louis Abitbol" <abitbol at sent.com> ?????:
> WARNING:
> /Users/jla/Library/CloudStorage/Dropbox/7cordas/Caio/record/90 NEW
> RODA SONG BOOK.pdf (object 254 0): object has offset 0
> 
> This does not prevent from getting the pages extracted properly and
> written to a pdf file which is readable.
> How can I detect and potentially correct using appropriate open
> source software what is wrong with the pdf file. I am on macos.
Here's a couple of links, [1] where people investigate and find the
root cause of the same warning and [2] where a number of possible ways
to corrupt PDF (and warning messages from various software) is
investigated, including this one.

Ironically, this is almost in scope for R-package-devel, because the
message comes from "qpdf", a tool used by R CMD check (and
tools::compactPDF() in particular). The internal "table of contents"
at
the end of the PDF file contains nonsensical references, which "qpdf"
complains about. If you run the following command line:

qpdf "/path/to/original/file.pdf"
"/path/to/reconstructed/file.pdf"

...qpdf will complain about the file once again, but it will also
produce a reconstructed file, which won't have this particular problem.
"qpdf" tries very hard to be "loss-less" about its
transformations, so
once you verify that the reconstructed file is fine, you can replace
the original with it.

-- 
Best regards,
Ivan

[1]
https://github.com/OpenPrinting/cups/issues/321#issuecomment-1246741326

[2]
https://openpreservation.org/blogs/trouble-shooting-pdf-validation-errors-a-case-of-pdf-hul-38/