[
https://issues.apache.org/jira/browse/PDFBOX-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14107328#comment-14107328
]
John Hewson edited comment on PDFBOX-1094 at 8/22/14 7:19 PM:
--------------------------------------------------------------
Yes, the device's DPI also needs to be taken into account. In the PDF model the
parent stream's initial transform should already include any device transform
(i.e. the conforming reader initialises initial_matrix = device_matrix *
stream_matrix_in_pdf). However, PDFBox doesn't do this, instead it applies the
device transform to the Graphics2D before rendering (see PDFRenderer, line 200,
and note my TODO comment below it). So technically, we only need to take into
account the parent stream's initial matrix, as in my previous comment, but in
the current implementation of PDFBox we'd also need to scale that using the
device matrix to account for DPI, as you say.
Valid fixes for this are to either:
1. Stop using Graphics2D#scale for device scaling in PDFRenderer, instead set
the initial stream matrix in PDFStreamEngine. Then pass the initial stream
matrix to the tiling pattern (this is the solution I proposed some time ago).
or:
2. Have PageDrawer extract the initial scale from Graphics2D#getTransform and
pass it to the tiling pattern in addition. This fixes the DPI problem but not
the fact that TilingPaint will be drawn to the Graphics2D using the CTM instead
of the stream's initial matrix, so that aspect will still be wrong.
was (Author: jahewson):
Yes, the device's DPI also needs to be taken into account. In the PDF model the
parent stream's initial transform should already include any device transform
(i.e. the conforming reader initialises initial_matrix = device_matrix *
stream_matrix_in_pdf). However, PDFBox doesn't do this, instead it applies the
device transform to the Graphics2D before rendering (see PDFRenderer, line 200,
and note my TODO comment below it). So technically, we only need to take into
account the parent stream's initial matrix, as in my previous comment, but in
the current implementation of PDFBox we'd also need to scale that using the
device matrix to account for DPI, as you say.
Valid fixes for this are to either:
1. Stop using Graphics2D#scale for device scaling in PDFRenderer, instead set
the initial stream matrix in PDFStreamEngine. Then pass the initial stream
matrix to the tiling pattern (this is the solution I proposed some time ago).
2. Have PageDrawer extract the initial scale from Graphics2D#getTransform and
pass it to the tiling pattern in addition. This fixes the DPI problem but not
the fact that TilingPaint will be drawn to the Graphics2D using the CTM instead
of the stream's initial matrix, so that aspect will still be wrong.
> Pattern colorspace support
> --------------------------
>
> Key: PDFBOX-1094
> URL: https://issues.apache.org/jira/browse/PDFBOX-1094
> Project: PDFBox
> Issue Type: Improvement
> Components: Rendering
> Affects Versions: 1.6.0
> Reporter: Andreas Lehmkühler
> Assignee: Andreas Lehmkühler
> Priority: Minor
> Attachments: ColoredTilingPaint.patch, PATTYP1.pdf, PATTYP2.pdf,
> PDF32000_2008_pg737.pdf, PDFBOX-1094-065514-XStep32767.pdf,
> PDFBOX-1094-094730.pdf, PDFBOX-1094-096213-p18.pdf, PDFStreamEngine.patch,
> PageDrawer.patch, _pdfbox-1094-tiling_pattern.pdf-1-blurry.png,
> jagpdf_doc_patterns.pdf, jagpdf_doc_patterns.pdf-1.png,
> pdfbox-1094-pdf32000_2008_pg737.pdf-1.png,
> pdfbox-1094-pdf32000_2008_pg737.pdf-1.png,
> pdfbox-1094-tiling_pattern.pdf-1.png, pdfbox-1094-tiling_pattern.pdf-1.png,
> pdfbox-1094-tiling_pattern.pdf-1.png, pdfbox-1861-tracemonkey.pdf-13.png,
> pdfbox-1861-tracemonkey.pdf-13.png, tiling_pattern.pdf
>
>
> PDFBox doesn't support PDPattern colorspaces
--
This message was sent by Atlassian JIRA
(v6.2#6252)
