Hi Andreas, for the additional columns
- subitems: that shouldn't be necessary, as this will be part of a regular entry. A sample is 7.4 Filter and 7.4.2 - 7.4.10 with all the subentries. I think there is a limit though as to what detail we should go. - read/r, write/w … - good idea. What type of information would you consider? reading, writing, rendering? other? - WDYT about another columns %completed which could provide a rough estimate about completeness with regards to the spec. The table should provide an overview only. As the table grows I plan to split it up a little so it's easier to read. I would envision the Javadocs to be used for additional information. E.g o.a.p.filter.DCTFilter is available but the methods themselves are only placeholders. Maybe this could be part of the javadocs for the individual classes. Currently one needs to look into the source to get to the information. BR Maruan Sahyoun Am 29.11.2013 um 12:31 schrieb Andreas Lehmkühler <[email protected]>: > Hi, > >> Maruan Sahyoun <[email protected]> hat am 28. November 2013 um 20:56 >> geschrieben: >> >> >> Hi, >> >> I started documenting the PDFBox implementation state with regards to the PDF >> Spec. A (very early) attempt can be found at > Thanks again for your efforts to improve our documentation. > >> http://pdfbox.staging.apache.org/docs/1.8.2/pdfcoverage.html >> >> Apart from the details available and the completion necessary is there >> something specific you would expect from such a document? The more details we >> would like to cover the more effort is required so this table can only >> provide >> a rough overview. >> > Maybe we should add 2 more columns: > - one to devide the description into subitems if necessary, e.g. encryption > algos, different kinds of pattern etc. > - one to describe how PDFBox supports a specific feature, such as "read/r", > "write/w" > > WDYT? > >> BR >> >> Maruan > > BR > Andreas Lehmkühler
