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

Andreas Lehmkühler resolved PDFBOX-1870.
----------------------------------------

    Resolution: Fixed
      Assignee: Andreas Lehmkühler

I've merged all changes to the 1.8 branch in revision 1563611

Thanks for the contribution!

> PDFunctionType0 incorrect
> -------------------------
>
>                 Key: PDFBOX-1870
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-1870
>             Project: PDFBox
>          Issue Type: Sub-task
>          Components: PDModel
>    Affects Versions: 2.0.0
>            Reporter: Tilman Hausherr
>            Assignee: Andreas Lehmkühler
>            Priority: Minor
>             Fix For: 1.8.5, 2.0.0
>
>         Attachments: Devicen3.after.jpg, Devicen3.before.jpg, Devicen3.pdf, 
> PDFunctionType0.patch, PDFunctionType0.patch, PDFunctionType0.patch, 
> devicen3.pdf-1.png, technical_v2_p9.before.jpg, technical_v2_p9.before.pdf, 
> technical_v2_p9.before.pdf-1.png, technical_v2_p91.after.jpg
>
>
> Type 0 (Sampled) Functions are described in 3.9.1 of the pdf spec and 
> basically, its cheating: there's an n-dimensional grid of values ("samples") 
> and the function shall return these values or something in-between.
> PDFunctionType0 has two bugs:
> 1) it does not do any interpolation. The function interpolate() is called 
> several times, but only adjust values between ranges etc, not to calculate 
> the color between 2^n samples - that part is "outputValues[i] = 
> (outputValuesPrevious[i] + outputValuesNext[i]) / 2". The spec does not tell 
> much, only that "Interpolation is used to determine output values from the 
> nearest surrounding values in the sample table". I have done a 
> linear/bilinear interpolation implementation for 1D/2D inputs. I did not do 
> an interpolation implementation for 3D and higher, because its unclear 
> whether this is actually used. Instead, I return random (!) values.
> 2) the sample bits are not collected correctly, the current code ignores the 
> leftover bits when a row is done. The spec tells us "Successive values are 
> adjacent in the bit stream; there is no padding at byte boundaries". Luckily, 
> that one is easy to correct, three lines must be moved up. Alternatively, one 
> might use the bit-io lib I mention in PDFBOX-615.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to