Bug 41667 - ImageProvider should be overridable in ImageFactory
Summary: ImageProvider should be overridable in ImageFactory
Status: NEW
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: images (show other bugs)
Version: 0.93
Hardware: PC other
: P3 normal
Target Milestone: ---
Assignee: fop-dev
Depends on:
Reported: 2007-02-21 02:32 UTC by Torok Edwin
Modified: 2012-04-07 01:52 UTC (History)
0 users

Use JAI ImageIO as default (877 bytes, patch)
2007-02-21 02:37 UTC, Torok Edwin
Details | Diff
tiff images to reproduce bug (36.25 KB, application/octet-stream)
2007-02-23 00:25 UTC, Torok Edwin

Note You need to log in before you can comment on or make changes to this bug.
Description Torok Edwin 2007-02-21 02:32:59 UTC
Fop-0.93 uses its internal TIFFImage reader, and I have encountered problems
with it:
- tiff is compressed using group4 compression
- I include the tiff in a generated PDF by using external-graphic in my .fo file

The resulting image is corrupt (size wrong, extra white lines in the middle of
the image, like for a broken interlaced file).

Using JAI ImageIO the generated PDF looks ok. Using JAI only, the generated PDF
looks ok, but the size of the image is wrong.

The imageprovider being used is hardcoded in the ImageFactory constructor. This
should be overridable. (eg: a setting in FOUserAgent).
Comment 1 Torok Edwin 2007-02-21 02:37:25 UTC
Created attachment 19617 [details]
Use JAI ImageIO as default

I have temporarely used this patch to use JAI ImageIO by default.
Of course this assumes you have jai_imageio.jar on classpath, and fails

A better solution could be to use jai_imageio/jai only if the jar is available
on classpath. IOW if an imageprovider can't deal with an image, use the next
one in the list.

Currently if ImageIO is the first one, and you don't have jai_imageio
available, the loading of fop's ImageIO wrapper succeeds, but
FopImage.loadDimensions() fails.
Comment 2 Jeremias Maerki 2007-02-22 10:44:41 UTC
Hmm, TIFFs with Group 4 compression are supposed to work. Any chance you could
attach/send the TIFF so I can take a look when I've got time?

BTW, it is planned to redesign the whole image package. This will improve the
situation a lot and I plan to add facilities to make the image providers easily
Comment 3 Torok Edwin 2007-02-23 00:25:29 UTC
Created attachment 19632 [details]
tiff images to reproduce bug

I can't send you the original pictures due to copyright issues. 

However we have discovered what is different on tiffs that don't work, and have
created 2 sample tiffs for you: 001.tif works with fop, 002.tif doesn't work
with fop.

I have used fop-0.93, and created works/notworks.pdf like this:
edwin@edwin-t-new:~/fopp$ sh ./fop works.fo -pdf works.pdf
edwin@edwin-t-new:~/fopp$ sh ./fop notworks.fo -pdf notworks.pdf

Open notworks.pdf, and compare it with works.pdf. 

Images 001.tif and 002.tif are the same, except for the pixel aspect ratio.

The problem is with pixel aspect ratio. When pixel aspect ratio is square, fop
handles the image correctly. When pixel aspect ratio is custom (like for fax
images), fop doesn't handle the image correctly. The pixel aspect ratio should
be square for proper viewing.

[You can see/change the pixel aspect ratio of a tiff in Photoshop (image->pixel
aspect ratio)]
Comment 4 Alexander Bub 2007-03-27 02:38:33 UTC
I've got another set of files to reproduce this bug with fop-0.93. Using the
external-graphic tag, the bug occurs with a multi-strip tiff (group 4
compression). A single-strip copy of the image works. Both files are single-page
tiffs and otherwise identical. 

Should I attach my files? (A4 pages, ~ 260 KB zip with the PDFs)
Comment 5 Glenn Adams 2012-04-07 01:43:56 UTC
resetting P2 open bugs to P3 pending further review