[
https://issues.apache.org/jira/browse/PDFBOX-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931286#comment-13931286
]
John Hewson edited comment on PDFBOX-1975 at 3/12/14 2:19 AM:
--------------------------------------------------------------
1) That's fine, having working code is more useful, once it works and we have
unit tests then we can re-refactor. Either the JAI BMP provider or "mergeTree"
is buggy, I suspect it is the BMP provider, the correct behaviour should be as
you say, to "blend into the existing data".
2) I think we should remove the ImageIOUtil.writeImage method which takes a
filename, it's only used in the tests and, as you say, its prefix behaviour is
weird. If instead we change the filename behaviour then any end-users of this
method are going to get silent failures, which is always something to be wary
of, even for major-version releases. There are probably not many (or any)
end-user consumers of this particular method anyway, but it's better for us to
let them have compiler errors rather than silently different behaviour.
Update: Perhaps a good middle-option is to replace it with a new method which
instead of having a String parameter for the filename, it could have a File
parameter. That way we can provide a new method with better prefix behaviour
without introducing silent behaviour changes.
4) Good question, probably not, we could drop support for it in 2.0 and if
someone really wants it we can always put it back in a minor-version release.
was (Author: jahewson):
1) That's fine, having working code is more useful, once it works and we have
unit tests then we can re-refactor. Either the JAI BMP provider or "mergeTree"
is buggy, I suspect it is the BMP provider, the correct behaviour should be as
you say, to "blend into the existing data".
2) I think we should remove the ImageIOUtil.writeImage method which takes a
filename, it's only used in the tests and, as you say, its prefix behaviour is
weird. If instead we change the filename behaviour then any end-users of this
method are going to get silent failures, which is always something to be wary
of, even for major-version releases. There are probably not many (or any)
end-user consumers of this particular method anyway, but it's better for us to
let them have compiler errors rather than silently different behaviour.
4) Good question, probably not, we could drop support for it in 2.0 and if
someone really wants it we can always put it back in a minor-version release.
> Improve TestImageIOUtils unit tests to check image resolution and compression
> -----------------------------------------------------------------------------
>
> Key: PDFBOX-1975
> URL: https://issues.apache.org/jira/browse/PDFBOX-1975
> Project: PDFBox
> Issue Type: Task
> Components: Utilities
> Affects Versions: 2.0.0
> Reporter: Tilman Hausherr
> Assignee: Tilman Hausherr
> Priority: Minor
> Labels: imageio, test, tiff
> Fix For: 2.0.0
>
>
> Because of the problems with recent changes (see PDFBOX-1963), I will improve
> the unit tests so that image resolution and compression is checked.
> I found out that JPEGs don't have a resolution, BMP had the wrong resolution.
> The fault wasn't in the java TIFF writer as I thought before, it is in the
> java PNG writer, which uses the PixelSize values wrongly, i.e. it interprets
> them as "pixels per mm" instead of "mm per pixel" as per specification. The
> JPEG writer throws an exception "JFIF APP0 must be first marker after SOI".
> The BMP writer can set the resolution, but the BMP reader doesn't read it.
> (Some of this might be different depending on the version)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
