[
https://issues.apache.org/jira/browse/PDFBOX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923210#comment-13923210
]
Tilman Hausherr commented on PDFBOX-1963:
-----------------------------------------
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.
No, 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 provide also a method with dpi. 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. Remember also some guy here who was very p****ed
off about the bouncycastle folks who constantly change their API.
> 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)