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

Maruan Sahyoun commented on PDFBOX-1000:
----------------------------------------

Thanks for your valuable feedback. I'll try to provide a status from time to 
time to inform about the progress. 

With the startxref - my mistake it's EOF being required [PDF 1.7 App. H 18]. 
That was the idea behind Acrobat parsing mode to implement the notes in App. H. 
But I think you are right, 2 Strict and Relaxed should be enough.

For the documentation I'm putting links to the reference into the code wherever 
I feel that structures are defined which are related to the spec, to describe 
what is going on or where assumptions are made. Small sample:

                case DelimiterChars.OpeningAngleBracket:                // 
Dictionary or Hex String
                        // This could be either the start of a 
                        // Dictionary [PDF 1.7: 3.2.6] or a 
                        // Hexadecimal String [PDF 1.7: 3.2.3]
                        // so we need to read the next ch to make 
                        // a decision

At the moment I'm trying to get to a state where I can submit the code and it's 
really doing something useful. There will be TODOs I'm documenting within the 
code. I think at that point in time I'm looking for feedback and help. One of 
the lacking areas is doing formal unit tests although I'm testing individual 
functions against some PDFs I have as development moves forward. So I'm glad 
that you can commit your PDFs for unit testing.
                
> Conforming parser
> -----------------
>
>                 Key: PDFBOX-1000
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-1000
>             Project: PDFBox
>          Issue Type: New Feature
>          Components: Parsing
>            Reporter: Adam Nichols
>            Assignee: Adam Nichols
>         Attachments: COSUnread.java, ConformingPDDocument.java, 
> ConformingPDFParser.java, ConformingPDFParserTest.java, XrefEntry.java, 
> conforming-parser.patch, gdb-refcard.pdf
>
>
> A conforming parser will start at the end of the file and read backward until 
> it has read the EOF marker, the xref location, and trailer[1].  Once this is 
> read, it will read in the xref table so it can locate other objects and 
> revisions.  This also allows skipping objects which have been rendered 
> obsolete (per the xref table)[2].  It also allows the minimum amount of 
> information to be read when the file is loaded, and then subsequent 
> information will be loaded if and when it is requested.  This is all laid out 
> in the official PDF specification, ISO 32000-1:2008.
> Existing code will be re-used where possible, but this will require new 
> classes in order to accommodate the lazy reading which is a very different 
> paradigm from the existing parser.  Using separate classes will also 
> eliminate the possibility of regression bugs from making their way into the 
> PDDocument or BaseParser classes.  Changes to existing classes will be kept 
> to a minimum in order to prevent regression bugs.
> [1] Section 7.5.5 "Conforming readers should read a PDF file from its end"
> [2] Section 7.5.4 "the entire file need not be read to locate any particular 
> object"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to