Probably. Support was added for JPEG images to be embedded directly into
PDF. Until then JPEGS were read into memory by Jimi and written to the
PDF as a normal bitmap equal to the way GIFs and PNGs are written (using
non-lossy ZLib compression). So probably, Jimi was able to open those
JPEG images but something goes wrong today with the JPEGs that are
directly embedded in a PDF.

As the whole image support stuff is rather hardcoded at the moment, you
might want to try to modify org.apache.fop.images.FopImageFactory and
org.apache.fop.images.analyser.ImageReaderFactory to comment out JPEG
support. That will restore the way JPEG images were handled back in
0.20.2. But you will get bigger PDFs.

This is of course a short-term work-around. We still need to find out
the real problem. Would you mind checking BugZilla, if there's already
an entry for this problem? If not, please open a new bug report and add
one or two of your problem-JPEGs as an attachment. This way we can fix
it eventually. No idea if I get to have a look at it, because I wanted
to work mostly on the redesign during the next few weeks. So takers are

I hope this clears it up a bit.

On 26.07.2002 20:37:51 Darrel Riekhof wrote:
> We found the same thing.  We also found that images with ICC Profiles display 
>correctly in FOP 0.20.2, but appear as black boxes in FOP 0.20.3 and 0.20.4.
> Anyone know what happened between .2 and .3 that would break this?
> Is there a way to strip out the ICC Profile of an image at runtime?  Our users are 
>not terribly technical, asking them to not upload images with ICC Profiles may be a 
>little too much for them.
> Darrel

Jeremias Maerki

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to