[
https://issues.apache.org/jira/browse/PDFBOX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923173#comment-13923173
]
John Hewson edited comment on PDFBOX-1963 at 3/7/14 1:50 AM:
-------------------------------------------------------------
{quote}
Your refactoring \[...] took away the possibility to decide on the type of the
BufferedImage, especially for bitonal images, which is a requirement for TIFF
CCITT G4 compression.
{quote}
Yep, that's because PDFBox's internal rendering can only render to TYPE_INT_RGB
and TYPE_INT_ARGB images. The user is free to convert the BufferedImage
themselves afterwards, doing so is the same as what was previously happening
silently: an inefficient conversion from RGB to BINARY after-the-fact.
{quote}
You also took away the dpi parameter. This wasn't discussed before, and it is
very annoying for a user to enter 300 / 72.0 as parameter instead of just 300
as before.
{quote}
Most graphics APIs deal with scaling, not with DPI (think of Apple's high-dpi
mode, it's called "2x" not "144dpi". It has been my experience that users often
misunderstand DPIs, mostly due to the Mac/Windows 72/96 legacy. I agree that
for advanced users it's nicer to be able to specify a DPI so I've added two
{{renderImageWithDPI}} methods in revision 1575080 to explicitly allow this :)
EDIT: I had to add revision 1575115 too to fix some bugs.
was (Author: jahewson):
{quote}
Your refactoring \[...] took away the possibility to decide on the type of the
BufferedImage, especially for bitonal images, which is a requirement for TIFF
CCITT G4 compression.
{quote}
Yep, that's because PDFBox's internal rendering can only render to TYPE_INT_RGB
and TYPE_INT_ARGB images. The user is free to convert the BufferedImage
themselves afterwards, doing so is the same as what was previously happening
silently: an inefficient conversion from RGB to BINARY after-the-fact.
{quote}
You also took away the dpi parameter. This wasn't discussed before, and it is
very annoying for a user to enter 300 / 72.0 as parameter instead of just 300
as before.
{quote}
Most graphics APIs deal with scaling, not with DPI (think of Apple's high-dpi
mode, it's called "2x" not "144dpi". It has been my experience that users often
misunderstand DPIs, mostly due to the Mac/Windows 72/96 legacy. I agree that
for advanced users it's nicer to be able to specify a DPI so I've added two
{{renderImageWithDPI}} methods in revision 1575080 to explicitly allow this :)
> 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)
