[
https://issues.apache.org/jira/browse/PDFBOX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923210#comment-13923210
]
Tilman Hausherr edited comment on PDFBOX-1963 at 3/7/14 12:55 PM:
------------------------------------------------------------------
PDFBOX can render to the BINARY type. It worked until a few hours ago and makes
sense for PDFs that have bitonal images. And it still could do it, I just
looked at the code, image.createGraphics() is still there. I used bitonal
images for 100000 PDFs 2 years ago as part of a migration project from PDF to
multipage TIFF. I don't want to implement myself an slower extra when it was
available out of the box before.
Using DPI is not unusual. One part of my paid work is related to high speed
scanning, and we usually offer 200dpi or 300dpi (which is exactly what the
scanner hardware does), not "2,7777777777777777777777777777778" or
"4,1666666666666666666666666666667". If you think you'd like scaling as
parameter, yes, please keep the old method with DPI for compatibility and
convenience. And with the image type. And with the page object.
Changing any outside API is risky. Rather discuss it here for a few days before
changing, and then @deprecate it instead, and remove it in the next release.
Everything that you see in an API had a reason to be there, and opinions may
differ. As an example how not to work, see the comments in PDFBOX-1836 about
the frequent bouncycastle API changes.
was (Author: tilman):
PDFBOX can render to the BITONAL type. It worked until a few hours ago and
makes sense for PDFs that have bitonal images. And it still could do it, I just
looked at the code, image.createGraphics() is still there. I used bitonal
images for 100000 PDFs 2 years ago as part of a migration project from PDF to
multipage TIFF. I don't want to implement myself an slower extra when it was
available out of the box before.
Using DPI is not unusual. One part of my paid work is related to high speed
scanning, and we usually offer 200dpi or 300dpi (which is exactly what the
scanner hardware does), not "2,7777777777777777777777777777778" or
"4,1666666666666666666666666666667". If you think you'd like scaling as
parameter, yes, please keep the old method with DPI for compatibility and
convenience. And with the image type. And with the page object.
As a general rule: avoid changing any outside API. If you think the API is
uncool, discuss it here for a few days before changing, and then @deprecate it
instead, and remove it in the next release. Everything that you see in an API
had a reason to be there. As an example how not to work, see the comments in
PDFBOX-1836 about the frequent bouncycastle API changes.
> 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)
