[
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/6/14 10:27 PM:
--------------------------------------------------------------
{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}
The use of DPI here is a bit unusual, most graphics APIs deal with scaling, not
with DPI (think of Apple's high-dpi mode, it's called "2x" not "144dpi". This
is certainly something which can be discussed further and we may want to
provide both methods? WDYT?
EDIT: I should add that my experience has been that most users don't really
understand DPI, especially due to the Windows = 96 but Mac = 72 confusion.
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}
The use of DPI here is a bit unusual, most graphics APIs deal with scaling, not
with DPI (think of Apple's high-dpi mode, it's called "2x" not "144dpi". This
is certainly something which can be discussed further and we may want to
provide both methods? WDYT?
> 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)
