[
https://issues.apache.org/jira/browse/PDFBOX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923258#comment-13923258
]
John Hewson commented on PDFBOX-1963:
-------------------------------------
{quote}
PDFBOX can render to the BITONAL type \[...]
{quote}
Internally PDFBox expects images to be RGB or ARGB, other formats might work
but that might just be luck. Allowing the user to pass in any image type they
want is a recipe for disaster, but we could explicitly add support for
TYPE_BYTE_BINARY. Is that what you need?
Please don't be surprised when things in trunk change, just comment on the
relevant JIRA issue and the problem can always be solved. If you have specific
functionality which you want PDFBox to continue to support consider writing a
unit test so that it is clear to other developers that the functionality serves
a purpose (there's a lot of cruft and legacy code in PDFBox which is slowly
being removed/replaced).
---
Regarding DPI, "high speed scanning" makes you an expert user, so your
experience is not typical. I'm really trying to think about the completely
average user, someone who is not you or I.
---
{quote}
@deprecate it instead, and remove it in the next release
{quote}
Trunk is unstable and that's a good thing. Applying stable-release practices to
trunk would just hold back progress and encourage stagnation rather than
improvement.
There's a lot of refactoring to be done in 2.0, and there will always be a JIRA
issue which corresponds to a given commit but I'm not going to discuss every
detail on the mailing list or open a new sub-issue. If something changes in
trunk which causes a problem for another developer then mentioning it in the
corresponding JIRA issue is the ideal solution. The problem can always be
remedied and SVN never forgets.
{quote}
Everything that you see in an API had a reason to be there
{quote}
There plenty of ancient crappy code in PDFBox which has stuck around for the
sake of 1.x stability. There's a reason it's there but it isn't necessarily a
good one. Once again trunk is **unstable** it should be changing. Once we hit
2.0.0 release then we keep things stable. If you want stability from trunk,
you're doing it wrong.
> 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)
