On 12.05.2003 13:15:06 Robert P. J. Day wrote: > > in order to clarify which graphics formats are supported under what > circumstances, i invoked (under red hat linux) a small xclock client, > and used "import" to take a snapshot of that window and save it in > every format supported by that command that seemed to be relevant. > > the results of embedding all of those formats depending on compiled > support: > > neither JIMI nor JAI: > BMP, GIF, JPG > > JIMI only: > BMP, GIF, JPG, PNG > > JAI only: > BMP, GIF, JPG, PNG, TIFF > > > > observations: > > 1) since GIF and JPG are supported natively, it's not surprising that > they render no matter what. it's more surprising that BMP renders > in the first case, since it's listed as requiring either JIMI or JAI > support. curious.
Ok, let's go over this. I'm looking at the code: GIF, JPEG, BMP, EPS and SVG are supported without any additional library: - GIF is supported through JDK classes. - JPEG is implemented directly because it can be more or less embeded 1:1 in a PDF. - BMP is directly implemented. - EPS is similar to JPEG. EPS images get embedded 1:1 in the PDF. Acrobat Reader cannot display them (blank output) but looking at the PDF in GhostView or printing it on a PostScript printer shows the EPS content. - SVG is supported through Batik and FOP's own code. TIFF is a special case. TIFF images with JPEG or CCITT content will be rendered to PDF as with plain JPEGs: simple embedding without decompressing. Other TIFF subformats will be handled by JAI. TIFFs don't seem to be handled with JIMI installed (technical: since it is derived from JAIImage). So it seems like TIFF is totally unsupported if JAI is not present. PNG images are supported through either JAI or JIMI whichever is present. > 2) a number of formats that claim to be supported via JIMI (e.g., PCX, > PICT, etc.) are not rendered, although the online docs do admit that > the listed support is only "theoretical". still, it's not clear why > some should work and others not, given that their listed support is > identical. > > in all those cases, the error message printed during the processing > was of the form: > > [ERROR] Could not load external SVG: Content is not allowed in prolog. > [ERROR] Error while creating area : No ImageReader for this type of > image (file:xclock.xbm) > > it's not clear what trying to load an "external SVG" has to do > with these other formats. As J�rg already said, FOP falls back to SVG mode if it cannot identify an image. Since an unsupported image format is not SVG an error like above occurs. That's the reason for the first message. The second message tells something about ImageReaders. For each image format supported by FOP an ImageReader must exist. It's responsible to identify a particular image format and to extract some header information such as resolution and image size. Basically FOP tries through all ImageReaders until it finds a format it recognizes. The last to try is always SVG. So even if JAI or JIMI support additional format, if there's no corresponding ImageReader, the format is not supported. > 3) EPS doesn't render, although the table does state that this > native support is still limited for PDF output. See above. EPS doesn't show in Acrobat Reader. > (also, there is a "CUR" format listed in the table of type > "unknown", but on my host, the resulting file appears to be > identical to an EPS file. at least, it's the same size and > the "file" command describes them identically. are these > really the same formats under different names? again, > just curious.) Since ICO (Windows Icon) is supported by Jimi, CUR will most probably be a Windows cursor file. Not an EPS. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
