[
https://issues.apache.org/jira/browse/PDFBOX-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Lehmkühler updated PDFBOX-1694:
---------------------------------------
Merged into 1.8-branch in revision 1542735
> Bug in org.apache.pdfbox.io.Ascii85InputStream
> ----------------------------------------------
>
> Key: PDFBOX-1694
> URL: https://issues.apache.org/jira/browse/PDFBOX-1694
> Project: PDFBox
> Issue Type: Bug
> Affects Versions: 1.7.1
> Environment: Any
> Reporter: Peter Costello
> Assignee: Andreas Lehmkühler
> Labels: Ascii85Decode
> Fix For: 1.8.3, 2.0.0
>
> Attachments: test.java
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> Method 'org.apache.pdfbox.io.Ascii85InputStream.read()' has bug when reading
> final set of char that are not modulo-4.
> Test
> file="www.mzweb.com.br/grupobimbo/web/arquivos/Bimbo_Historia_20070409_Esp.pdf".
>
> On page#0 there is a dictionary "323 0 obj << /Length 1492 /Filter
> [/Ascii85Decode /FlateDecode]>>"
> Last set of bytes to decode is "%f" or 0x25, 0x66
> Ascii85InputStream pads this to "%f~!!" and correctly generates the final
> byte 0x0f.
> Including the '~' end-of-data char in the padding is a major bug.
> If the final padding were "%f!!!", the final byte decoded would be 0x0e
> (which is wrong).
> The correct padding is the 'u' char, or "%fuuu" (See
> http://en.wikipedia.org/wiki/Ascii85)
> This is a quick fix.
> The PDF files for corporate website "Grupo Bimbo" include lots of examples
> using Ascii85Decode/
--
This message was sent by Atlassian JIRA
(v6.1#6144)
