[
https://issues.apache.org/jira/browse/PDFBOX-1970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925164#comment-13925164
]
Tilman Hausherr edited comment on PDFBOX-1970 at 3/9/14 10:02 AM:
------------------------------------------------------------------
I did some research:
- It's only a flip
- It's not always for type 1
- It's always for type 4+5
- It's never for type 2+3 (which may be because these handle the transforms in
a different way that can't be used for the other types).
I don't have an overview over the complete project, so I can't tell why the
AffineTransform is like it is in 1.8 (and whether 1.8 or 2.0 have the wrong
one). Instead, I tested this code for types 1,4 and 5 which flips the
AffineTransform:
{code}
xform.scale(1,-1);
xform.translate(0, -pageHeight);
{code}
Now all the images come out correctly, including those that were not flipped
before.
I'll wait a bit, but if there isn't a better solution, I would commit the
change above (with a //TODO notice at that code explaining why) because
- had I started the shading implementation at the time there was no "2.0
trunk", I would have flipped it anyway
- per my interpretation of TDD ideology, code is correct if the tests pass, and
all the images are rendered correctly with the code change :-)
was (Author: tilman):
I did some research:
- Its only a flip
- Its not always for type 1
- Its always for type 4+5
- Its almost never for type 2+3 (which may be because these handle the
transforms in a different way that can't be used for the other types).
I don't have an overview over the complete project, so I can't tell why the
AffineTransform is like it is in 1.8 (and whether 1.8 or 2.0 have the wrong
one). Instead, I tested this code for types 1,4 and 5 which flips the
AffineTransform:
{code}
xform.scale(1,-1);
xform.translate(0, -pageHeight);
{code}
Now all the images come out correctly, including those that were not flipped
before.
I'll wait a bit, but if there isn't a better solution, I would commit the
change above (with a //TODO notice at that code explaining why) because
- had I started the shading implementation at the time there was no "2.0
trunk", I would have flipped it anyway
- per my interpretation of TDD ideology, code is correct if the tests pass, and
all the images are rendered correctly with the code change :-)
> 1.8 shadings are sometimes flipped
> ----------------------------------
>
> Key: PDFBOX-1970
> URL: https://issues.apache.org/jira/browse/PDFBOX-1970
> Project: PDFBox
> Issue Type: Bug
> Affects Versions: 1.8.4
> Reporter: Tilman Hausherr
> Labels: shading, shadingpattern
> Attachments: _asy-gouraud.pdf-1.png, asy-gouraud.pdf
>
>
> Some of my shading test images are sometimes flipped when done with the 1.8
> branch, not with the trunk. I have observed this with shadingtype 1, 4 and 5.
> The shadingContext is created with an AffineTransform (the CTM is identical
> and its just a translation) of
> [1.0, 0.0, 399.0]
> [0.0, 1.0, 49.0]
> for the 1.8 branch (bad)
> and with
> [1.0, 0.0, 399.0]
> [0.0, -1.0, 149.0]
> for the trunk (good).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
