[
https://issues.apache.org/jira/browse/PDFBOX-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14123717#comment-14123717
]
John Hewson edited comment on PDFBOX-2302 at 9/5/14 10:34 PM:
--------------------------------------------------------------
I've added a workaround for the example-striped.pdf file. As far as I can tell,
Java 2D's rendering isn't compatible with PDF's rules for scan conversion,
found in "Scan Conversion Rules", PDF 32000:
{quote}
Pixel boundaries always fall on integer coordinates in device space.
{quote}
Which means no sub-pixels.
{quote}
A shape shall be scan-converted by painting any pixel whose square region
intersects the shape, no matter how small the intersection is. This ensures
that no shape ever disappears as a result of unfavourable placement relative
to the device pixel grid, as might happen with other possible scan conversion
rules. The area covered by painted pixels shall always be at least as large as
the area of the original shape.
{quote}
Which requires the path to be expanded greedily to fill pixels.
{quote}
The position of the centre of such a pixel—in other words, the point whose
coordinate values have fractional parts of one-half—shall be mapped back into
source space to determine how to colour the pixel. There shall not be averaging
over the pixel area;
{quote}
Which basically says "no anti-aliasing" in destination space (but source space
is ok).
Most of the time this doesn't matter at all, anti-aliasing works well, it's
only when sub-pixel alignment is necessary that we see issues, which is,
anecdotally, when gradients are simulated by piecewise rectangular filled
paths. My workaround is simply to detect rectangular paths and not anti-alias
them, as their lines are already straight.
was (Author: jahewson):
I've added a workaround for the example-striped.pdf file. As far as I can tell,
Java 2D's rendering isn't compatible with PDF's rules for scan conversion,
found in "Scan Conversion Rules", PDF 32000:
{quote}
Pixel boundaries always fall on integer coordinates in device space.
{quote}
Which means no sub-pixels.
{quote}
A shape shall be scan-converted by painting any pixel whose square region
intersects the shape, no matter how small the intersection is. This ensures
that no shape ever disappears as a result of unfavourable placement relative
to the device pixel grid, as might happen with other possible scan conversion
rules. The area covered by painted pixels shall always be at least as large as
the area of the original shape.
{quote}
Which requires the path to be expanded greedily to fill pixels.
{quote}
The position of the centre of such a pixel—in other words, the point whose
coordinate values have fractional parts of one-half—shall be mapped back into
source space to determine how to colour the pixel. There shall not be averaging
over the pixel area;
{quote}
Which basically says "no anti-aliasing" in destination space (but source space
is ok).
Most of the time this doesn't matter at all, anti-aliasing works well, it's
only when sub-pixel alignment is necessary that we see issues, which is,
anecdotally, when gradients are simulated by piecewise rectangular filled
paths. My workaround is simply to detect rectangular paths and not anti-alias
them, as their lines are already straight.
> Make better use of RenderingHints
> ---------------------------------
>
> Key: PDFBOX-2302
> URL: https://issues.apache.org/jira/browse/PDFBOX-2302
> Project: PDFBox
> Issue Type: Improvement
> Components: Rendering
> Affects Versions: 2.0.0
> Reporter: John Hewson
> Assignee: John Hewson
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: PDFBOX-1691-FORIS-HV.pdf-2.png,
> PDFBOX-1691-FORIS-HV.pdf-2.png, PDFBOX-1691-FORIS-HV2-200dpi.png,
> PDFBOX-1691-FORIS-HV2-good.png, PDFBOX-1691-FORIS-HV2-poor.png,
> PDFBOX-1794-vattenfall1.jpg, PDFBOX-1794-vattenfall1_before.jpg,
> bugzilla8677511.jpg, bugzilla8677511_before.jpg, example-striped.pdf,
> example-striped.pdf-1.png, mori-cvpr01.pdf
>
>
> PageDrawer doesn't make effective use of Java 2D's RenderingHints. The
> situation now is a little odd due to code having been moved around and copied
> and pasted. Most of the time we're not making use of higher quality
> renderings which are available to us.
> Some examples of strangeness:
> - drawTilingPattern sets VALUE_FRACTIONALMETRICS_ON, yet this applies only to
> AWT fonts
> - drawGlyph2D sets VALUE_ANTIALIAS_ON but strokePath and fillPath set it to
> VALUE_ANTIALIAS_OFF
> - drawBufferedImage sets KEY_INTERPOLATION to
> VALUE_INTERPOLATION_NEAREST_NEIGHBOR which is the lowest quality image
> scaling method
> - shadingFill sets VALUE_ANTIALIAS_OFF (but that might make more sense
> because we're Paint-ing these ourselves, OTOH if the canvas is buffered
> already for anti-aliasing do we save anything by disabling it?)
> - drawPage sets VALUE_ANTIALIAS_ON but this is always overridden by the
> various drawing methods
> Currently we're missing out on anti-aliasing for paths (other than glyphs)
> and we're getting low-quality resizing of images, which makes Type 3 fonts
> look particularly ugly. Setting the appropriate rendering hints would improve
> this greatly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
