[ 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)