[jira] [Updated] (PDFBOX-2099) Improve handling and writing of header and trailer versions

["John Hewson (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/PDFBOX-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Hewson updated PDFBOX-2099:
--------------------------------
    Fix Version/s: 2.0.0

> Improve handling and writing of header and trailer versions
> -----------------------------------------------------------
>
>                 Key: PDFBOX-2099
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-2099
>             Project: PDFBox
>          Issue Type: Improvement
>          Components: Parsing, Writing
>    Affects Versions: 1.8.5, 1.8.6, 2.0.0
>            Reporter: Tilman Hausherr
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> From [~msahyoun] in PDFBOX-1922:
> I'd think that instead of setting the version the current way (which is replacing the version information in the header) during the parsing the parsing should keep both version informations and getVersion within COSDocument is amended to return the correct information. What I'm suggesting is keeping both versions as this is inline with the spec and ensures that we do not override the current settings in a pdf when opening and saving out.
> From me:
> COSDocument.java has this:
> {code}
>     public void setVersion( float versionValue )
>     {
>         // update header string
>         if (versionValue != version) 
>         {
>             headerString = headerString.replaceFirst(String.valueOf(version), String.valueOf(versionValue));
>         }
>         version = versionValue;
>     }
> {code}
> So it does two things, set the version and set the headerString. My first Idea would be to remove the setting of the headerString, because this is 1. a side effect and 2. already done elsewhere. But this was inserted in 2011 by [~lehmi] as part of PDFBOX-879 so I wonder if I will break something by removing this.
> from [~lehmi]:
> As far as I can remember it, I wasn't aware of the fact that a pdf may have to versions (header + trailer). In the hindsight the change wasn't that good. I agree with Maruan Sahyoun, we have to overhaul the get/setVersion methods. Both must take both possible values into account following the pdf spec.
> My current thought:
> We may need two setters. One for "inside jobs" (i.e. parsing), that sets each version separately. One for "higher" applications (e.g. merging), that sets the version in the header and in the trailer at the same time.
> Whatever change will be done, it should not produce a regression in PDFBOX-879.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)