[
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 11:34 AM:
------------------------------------------------------------------
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.
was (Author: tilman):
Don't remove something from the API then tell ME to write a unit test to
"prove" to you that you should put it back. Just don't remove it in the first
place without asking and getting a consensus first. (And actually, the unit
test WAS there, you broke it, its the one for TIFF images I complained about.
And you know about my change in ImageIOUtils re: TIFF images because you wrote
in that issue, that one 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" (don't
use scare tactics anyway - whats next, will TYPE_BYTE_BINARY harm our children
or facilitate terrorism or drugs?), and re "The problem can always be remedied"
then please start doing it instead of endless discussing to prevent it or to
make it discussing-time-intensive. PLEASE put back the image type, the page
type, the resolution and the unit tests. Discussion should be about new
features, not about defending oneself because of having used existing features.
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 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 and
these are 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)
