[
https://issues.apache.org/jira/browse/PDFBOX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923619#comment-13923619
]
Tilman Hausherr edited comment on PDFBOX-1963 at 3/7/14 2:39 PM:
-----------------------------------------------------------------
The unit test was there, its the one for TIFF images (that differs between
color and bitonal) I complained about earlier. See also PDFBOX-1734 (in which
you participated) which has a specific handling of TYPE_BYTE_BINARY images
because TIFF provides a compressor (G4) that is unmatched by all the others.
Yes I need TYPE_BYTE_BINARY, and no it is not a "recipe for disaster", so the
nice thing to do with a code revert or improvement. I need the image type, the
PDPage, the dpi resolution and the TIFF unit tests. Lets avoid discussion why
someone has used the existing features in the past.
Btw I just made a brute force test by changing to TYPE_BYTE_BINARY in
PDFRenderer. Not only it works fine, there is no loss of time, at least not one
that is felt. I rather feel it is faster.
I'm not just doing high speed scanning, I'm involved with all sort of
applications that do document managing / image managing. This goes back over
two decades, i.e. long before PDFBOX. Customers have specific requirements in
DPI. Most images are stored in b/w in PDF because this makes them small and
very fast to process. Storing documents in color isn't done much, only when its
really needed because its a photograph. Commercial documents almost never have
useful information in color. There's the company logo, but this isn't really
"information" so it can be kept in b/w.
was (Author: tilman):
Removing something from the API then asking for a unit test as a proof for the
need isn't helpful. Better get a consensus first or live with the risk of
getting disapproval. The unit test was there, its the one for TIFF images (that
differs between color and bitonal) I complained about earlier. See also
PDFBOX-1734 (in which you participated) which has a specific handling of
TYPE_BYTE_BINARY images because TIFF provides a compressor (G4) that is
unmatched by all the others.
Yes I need TYPE_BYTE_BINARY, and no it is not a "recipe for disaster", so the
nice thing to do with a code revert or improvement. I need the image type, the
PDPage, the dpi resolution and the TIFF unit tests. Lets avoid discussion why
someone has used the existing features in the past.
Btw I just made a brute force test by changing to TYPE_BYTE_BINARY in
PDFRenderer. Not only it works fine, there is no loss of time, at least not one
that is felt. I rather feel it is faster.
I'm not just doing high speed scanning, I'm involved with all sort of
applications that do document managing / image managing. This goes back over
two decades, i.e. long before PDFBOX. Customers have specific requirements in
DPI. Most images are stored in b/w in PDF because this makes them small and
very fast to process. Storing documents in color isn't done much, only when its
really needed because its a photograph. Commercial documents almost never have
useful information in color. There's the company logo, but this isn't really
"information" so it can be kept in b/w.
> 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)
