[
https://issues.apache.org/jira/browse/PDFBOX-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14698645#comment-14698645
]
Andreas Lehmkühler commented on PDFBOX-2423:
--------------------------------------------
{quote}
I had a look at the existing SoftMaskPaint.java and IMHO it is incorrect and
the code either does nothing, or something that doesn't make sense (writing to
a band that is higher than the existing band count).
{code}
result.setSample(i, j, numColorComponents, alpha);
{code}
{quote}
IMHO everything is fine here. The raster has numColorComponents (=3) + 1 bands
and the last band represents the alpha channel.
{quote}
By changing that to
{code}
for (int colorComponent = 0; colorComponent < numColorComponents;
++colorComponent)
{
alpha = alpha * result.getSample(i, j, colorComponent) / 255;
result.setSample(i, j, colorComponent, alpha);
}
{code}
(and a bit more) I was able to improve 7 files, 5 are differently incorrect
now, 1 is really wrong, which is related to us not using the /BC color.
{quote}
This makes sense if the the raster uses premultiplied alpha values, but it
doesn't. BTW, the calculation of the alpha value is wrong. I must not be
multiplied with itself for every color component. It just works accidentically
for alpha sample values of 0 and 255. It should be something like the following:
{code}
int premultiplied = alpha * result.getSample(i, j, colorComponent) / 255;
{code}
> Page tree handling needs rewriting
> ----------------------------------
>
> Key: PDFBOX-2423
> URL: https://issues.apache.org/jira/browse/PDFBOX-2423
> Project: PDFBox
> Issue Type: Improvement
> Components: PDModel
> Affects Versions: 1.8.7, 2.0.0
> Reporter: John Hewson
> Assignee: John Hewson
> Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: 025957.pdf, 26101_Colors.ai-1.png,
> 26101_Colors.ai-1.png-diff.png, Basiswissen-Vorschriften.pdf-3.png,
> Basiswissen-Vorschriften.pdf-3.png-diff.png,
> Basiswissen-Vorschriften.pdf-4.png,
> Basiswissen-Vorschriften.pdf-4.png-diff.png, PDFBOX-1058.pdf-1.png,
> PDFBOX-1058.pdf-1.png-diff.png, PDFBOX-1058.pdf-4.png,
> PDFBOX-1058.pdf-4.png-diff.png, PDFBOX-1094-tiling_pattern.pdf,
> PDFBOX-1711-cmyk.pdf-1.png, PDFBOX-1711-cmyk.pdf-1.png-diff.png,
> PDFBOX-1794-vattenfall.pdf-1.png, PDFBOX-1794-vattenfall.pdf-1.png-diff.png,
> PDFBOX-1917.pdf-1.png, PDFBOX-1917.pdf-1.png-diff.png,
> Transparency_group_rewrite3.patch, asy-functionshading.pdf-1.png,
> asy-functionshading.pdf-1.png-diff.png, bugzilla869140.pdf,
> example_026.pdf-1.png, gs-bugilla691763.pdf, gs-bugzilla688601.pdf,
> gs-bugzilla689518.pdf, gs-bugzilla690467.pdf, gs-bugzilla693322.pdf,
> gs-bugzilla694385.pdf, jagpdf_doc_patterns.pdf, samsung_galaxy_s_4_um-p1.pdf
>
>
> The way in which PDFBox handles the Page tree needs to be rewritten,
> preferably from scratch. Currently the document catalog returns the raw
> objects from the page tree, wrapped in either a PDPage or PDPageNode.
> We need to abstract over the page tree and get rid of PDPageNode, we should
> provide methods which can add/remove PDPage objects *only*. The existing
> low-level access to the page tree is not needed at the PD-level.
> Inheritance of page properties such as crop box, resources, and rotation
> should be reimplemented to use whatever new page tree abstraction we invent.
> We can finally remove the old broken methods which didn't look up the
> inheritance tree when retrieving these values.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
