[
https://issues.apache.org/jira/browse/PDFBOX-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13921263#comment-13921263
]
John Hewson edited comment on PDFBOX-1094 at 3/23/14 11:22 PM:
---------------------------------------------------------------
I'm still having problems with patterns. There's an issue that currently a
pattern is drawn with its origin at the current (x,y) coordinate and using the
current CTM, but it should be drawn with its origin at the current stream's
initial (x,y) coordinate and using the stream's initial CTM, from the PDF spec:
{quote}
Every pattern has a pattern matrix, a transformation matrix that maps the
pattern’s internal coordinate system to the default coordinate system of the
pattern’s parent content stream (the content stream in which the pattern is
defined as a resource).
{quote}
So the current CTM is ignored, which is confirmed by:
{quote}
Changes to the page’s transformation matrix that occur within the page’s
content stream, such as rotation and scaling, have no effect on the pattern;
it maintains its original relationship to the page no matter where on the page
it is used.
{quote}
Conceptually, the pattern is drawn over the entire page at the very beginning
and when we fill a shape with a pattern we are filling it with a "window"
through to the pattern which covers the page (that's not actually what happens
but it helps to think that way to understand).
Update: It looks like we need to pass the parent stream's default matrix to
PDFStreamEngine processStream (or processSubStream, processTilingPattern) in
order to implement patterns in line with the PDF spec.
was (Author: jahewson):
I'm still having problems with patterns. There's an issue that when a pattern
is drawn it is not drawn with its origin at the current (x,y) coordinate and
using the current CTM, rather it should be drawn with its origin at the current
stream's initial (x,y) coordinate and using the stream's initial CTM, from the
PDF spec:
{quote}
Every pattern has a pattern matrix, a transformation matrix that maps the
pattern’s internal coordinate system to the default coordinate system of the
pattern’s parent content stream (the content stream in which the pattern is
defined as a resource).
{quote}
So the current CTM is ignored, which is confirmed by:
{quote}
Changes to the page’s transformation matrix that occur within the page’s
content stream, such as rotation and scaling, have no effect on the pattern;
it maintains its original relationship to the page no matter where on the page
it is used.
{quote}
Conceptually, the pattern is drawn over the entire page at the very beginning
and when we fill a shape with a pattern we are filling it with a "window"
through to the pattern which covers the page (that's not actually what happens
but it helps to think that way to understand).
Update: It looks like we need to pass the parent stream's default matrix to
PDFStreamEngine processStream (or processSubStream, processTilingPattern) in
order to implement patterns in line with the PDF spec.
> 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: John Hewson
> Priority: Minor
> Attachments: ColoredTilingPaint.patch, PATTYP1.pdf, PATTYP2.pdf,
> PDF32000_2008_pg737.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)
