[
https://issues.apache.org/jira/browse/PDFBOX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923668#comment-13923668
]
John Hewson edited comment on PDFBOX-1963 at 3/7/14 12:34 PM:
--------------------------------------------------------------
Tilman,
{quote}
TestPDFToImage \[...] was testing at 96 dpi or screen resolution (the template
images are 96 dpi), now it is testing at scale 1, which is currently 72 dpi
which is the new default.
{quote}
This was an oversight, I didn't notice it because TestPDFToImage is disabled
and so it didn't break the build. *I've changed it back to 96dpi in revision
1575199*.
{quote}
The previous default of RenderUtil was 144 dpi. This should also be put back.
{quote}
This was deliberate, the comment in the original method said that it was
intended that users would down-scale the image returned, but there are 4x more
pixels at a 2x zoom factor, which quickly adds up to much slower performance.
Users who know that Java's default DPI is 72 is going to be surprised when the
image returned is at 144dpi.
*Here's an alternative solution*, why don't we just remove the default
{{#renderImage()}} method and rename {{#renderImage(pageIndex,scale)}} to
{{#renderImageWithScale(...)}} this will make it impossible for users to be
misled into thinking that PDFBox cannot render high-resolution images. It's
also obvious to newcomers that {{#renderImageWithScale(1)}} is a good starting
point without having to know anything about 72dpi.
{quote}
A default of 72 dpi will provide a poor user experience. Historically, its the
reason I choose PDFBOX over a competing open source product a years ago,
because I only got tiny images with the other one and it wasn't possible to set
the resolution (or I didn't find it in the API).
{quote}
Like I said, users don't understand DPI until they are experts! Anyhow, you
make a good point and I hope that my suggestion above addresses it.
was (Author: jahewson):
Tilman,
{quote}
TestPDFToImage \[...] was testing at 96 dpi or screen resolution (the template
images are 96 dpi), now it is testing at scale 1, which is currently 72 dpi
which is the new default.
{quote}
This was an oversight, I didn't notice it because TestPDFToImage is disabled
and so it didn't break the build. *I've changed it back to 96dpi in revision
1575199*.
{quote}
The previous default of RenderUtil was 144 dpi. This should also be put back.
{quote}
This was deliberate, the comment in the original method said that it was
intended that users would down-scale the image returned, but that is poor
advice because there are 4x more pixels at a 2x zoom factor, which quickly adds
up to much slower performance and makes PDFBox look bad. Anybody who know that
Java's default DPI is 72 is going to be surprised when the image returned is at
144dpi.
*Here's an alternative solution*, why don't we just remove the default
{{#renderImage()}} method and rename {{#renderImage(pageIndex,scale)}} to
{{#renderImageWithScale(...)}} this will make it impossible for users to be
misled into thinking that PDFBox cannot render high-resolution images. It's
also obvious to newcommers that {{#renderImageWithScale(1)}} is a good starting
point without having to know anything about 72dpi.
{quote}
A default of 72 dpi will provide a poor user experience. Historically, its the
reason I choose PDFBOX over a competing open source product a years ago,
because I only got tiny images with the other one and it wasn't possible to set
the resolution (or I didn't find it in the API).
{quote}
Like I said, users don't understand DPI until they are experts! Anyhow, you
make a good point and I hope that my suggestion above addresses it.
> PDFImageWriter doesn't make use of PDFStreamEngine
> --------------------------------------------------
>
> Key: PDFBOX-1963
> URL: https://issues.apache.org/jira/browse/PDFBOX-1963
> Project: PDFBox
> Issue Type: Improvement
> Components: Utilities
> Affects Versions: 2.0.0
> Reporter: John Hewson
> Assignee: John Hewson
> Fix For: 2.0.0
>
>
> PDFImageWriter is a subclass of PDFStreamEngine, however it never uses any of
> its functionality, the writeImage methods could be marked as static and
> behave in the same manner.
> The relationship between PDFImageWriter, RenderUtil, and ImageIOUtil no
> longer matches its historical origins and needs to be refactored.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
