[jira] [Comment Edited] (PDFBOX-5683) Inconsistent/incomplete PDF rendering

["Patrick Dalla Bernardina (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PDFBOX-5683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765590#comment-17765590 ] 

Patrick Dalla Bernardina edited comment on PDFBOX-5683 at 9/15/23 1:29 PM:
---------------------------------------------------------------------------

Yes, Working with invalid/inconsistent and unpredictable data could lead to endless loops. But, forensically, it would be worthwhile to recover as much info as possible. Our tool works with timeouts, to avoid/skip these kind of problems.

"The other idea to search for missing fonts, color spaces will most like not work. ": The idea of a Object Recoverer interface to delegate the recover of missing objects could solve some of these missing objects in alternate ways, depending of the implementation. For example, if the PDF being carved is from a well known collection of available PDFs, the used fonts or color spaces could be inferred to be the same.


was (Author: patrickdalla):
Yes, Working with invalid/inconsistent and unpredictable data could lead to endless loops. But, forensically, it would be worthwhile to recover as much info as possible. Our tool works with timeouts, to avoid/skip these kind of problems.

"The other idea to search for missing fonts, color spaces will most like not work. ": The idea of a Object Recoverer interface to delegate the recover of missing objects could solve some of these missing objects in alternate ways, depending of the implementation. For example, if the PDF being carved is from a well know collection of available PDFs, the used fonts or color spaces could be inferred to be the same.

> Inconsistent/incomplete PDF rendering
> -------------------------------------
>
>                 Key: PDFBOX-5683
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-5683
>             Project: PDFBox
>          Issue Type: New Feature
>          Components: Parsing
>            Reporter: Patrick Dalla Bernardina
>            Priority: Minor
>              Labels: Forensic
>         Attachments: pdf1.pdf
>
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> We have integrated tika and its default parsers in a Forensic Tool (IPED). As a forensic tool, it tries to recover/carve deleted PDF files, some of which can be partially recovered.
> PDFParser throws Exception if there is no PDF version header on the parsed content, avoiding any further content parsing.
> Commenting this exception, the parser still throws the exception "Missing root object specification in trail" in initialParse method, as this root object is normally at begin of a PDF file.
> Although, I could made some simple effort to build a "fake" root COSDictionary and build the PAGES entry with the recoverable PAGEs, searching them from document.getXrefTable();
> {code:java}
>     protected void initialParse() throws IOException
>     {
>         COSDictionary trailer = retrieveTrailer();
>     
>         COSDictionary root = trailer.getCOSDictionary(COSName.ROOT);
>         if (root == null)
>         {
>             // rebuild root from xref recovered info
>             root = new COSDictionary();
>             root.setItem(COSName.TYPE, COSName.CATALOG);
>             trailer.setItem(COSName.ROOT, root);
>             // identify recovered pages from xref to mount COSName.PAGES
>             Map<COSObjectKey, Long> xrefTable = document.getXrefTable();
>             COSArray kids = new COSArray();
>             for (Entry<COSObjectKey, Long> e : xrefTable.entrySet()) {
>                 COSObject o = document.getObjectFromPool(e.getKey());
>                 if (o.getObject() instanceof COSDictionary) {
>                     COSDictionary d = (COSDictionary) o.getObject();
>                     COSName type = d.getCOSName(COSName.TYPE);
>                     if (type != null) {
>                         if (type.equals(COSName.PAGE)) {
>                             kids.add(d);
>                         }
>                     }
>                 }
>             }
>             
>             COSDictionary pages = new COSDictionary();
>             pages.setItem(COSName.TYPE, COSName.PAGES);
>             pages.setItem(COSName.COUNT, COSInteger.get(kids.size()));
>             pages.setItem(COSName.KIDS, kids);
>             document.setDecrypted();
>             root.setItem(COSName.PAGES, pages);
>             initialParseDone = true;
>             return;
>             // throw new IOException("Missing root object specification in trailer.");
>         }
>         // in some pdfs the type value "Catalog" is missing in the root object
>         if (isLenient() && !root.containsKey(COSName.TYPE))
>         {
>             root.setItem(COSName.TYPE, COSName.CATALOG);
>         }
>         // check pages dictionaries
>         checkPages(root);
>         document.setDecrypted();
>         initialParseDone = true;
>     }
> {code}
> This simple effort was enough to show the recoverable pages on PDFDebugger, export XMP metadatas, text, and get the rendered pages buffered images to use on my OCR module.
> So, it would be very useful if PDFBOX already have some optional parameterizable mode to open/recover inconsistent/incomplete pdf file, with at least the implementation above or further recover actions.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org