RE: testing support for various graphics formats
On Wed, 14 May 2003, Victor Mote wrote: ... Many thanks to Robert P. J. Day for his persistence in bringing the needed changes to light. The substance of his efforts here was outstanding, and he has made a valuable contribution to the project. Many thanks also to Jeremias Maerki for actually developing the answers. ... while i appreciate the thought, i'm not going to take any bows for that brief flurry of anguished activity. i was, because of really tight time constraints, just trying to get FOP to deal with my graphics, based on *exactly* what i was reading online, and getting more and more frustrated as things didn't seem to jive with what i was reading. i'm glad i could be of assistance, but i also apologize to the list for my lack of ... uh, decorum. yeah, that's the word. decorum. yeesh. rday p.s. i will, of course, go back and test all the new documentation, and let you know what i find. more politely this time. :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: testing support for various graphics formats
The web site published minutes ago reflects changes to the graphics documentation that resulted from this and the related threads. Many thanks to Robert P. J. Day for his persistence in bringing the needed changes to light. The substance of his efforts here was outstanding, and he has made a valuable contribution to the project. Many thanks also to Jeremias Maerki for actually developing the answers. There may very well still be errors or omissions. If so, please raise them in this forum, and we'll work on getting them fixed. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing support for various graphics formats
From: Robert P. J. Day [EMAIL PROTECTED] snip/ 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. 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. J.Pietschmann explained this to you earlier. See http://marc.theaimsgroup.com/?l=fop-userm=105266547708310w=2 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. The way I understood J.Pietschmann's response (and I may be wrong in this), is that GIF and JPG are handled easily, then PNG, TGA, EPS and TIFF actually get passed to Jimi for processing and all other formats are assumed to be SVG. Hence why the SVG processor errors on the other formats. _ Express yourself with cool emoticons http://www.msn.co.uk/messenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing support for various graphics formats
On Mon, 12 May 2003, Chris Bowditch wrote: From: Robert P. J. Day [EMAIL PROTECTED] 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. The way I understood J.Pietschmann's response (and I may be wrong in this), is that GIF and JPG are handled easily, then PNG, TGA, EPS and TIFF actually get passed to Jimi for processing and all other formats are assumed to be SVG. Hence why the SVG processor errors on the other formats. (just as an aside, that last post was not meant to be a response to *anything* that came earlier -- i decided the most constructive thing i could do was to just test every format under different circumstances to see what worked and what didn't, and i just summarized my findings.) and you are of course correct -- all those other formats are, as j. pietschmann reported, categorized as SVG. but that suggests that the online docs should say so, and not list them as being supported thru jimi, at least for the time being, until that support is available. SVG: and on the bright side, just so i can prove i can be chipper and upbeat, i tossed a reference to an SVG file into my docbook test document, and it rendered nicely. very colorful batik logo. see? now, that's the manic half of my manic-depressive personality. rday p.s. i just looked more closely and, in contrast to what you wrote above, according to my tests, neither TGA nor TIFF was rendered properly by JIMI, although TIFF *was* rendered properly by JAI. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing support for various graphics formats
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]
Re: testing support for various graphics formats
To my explanations, I have to add that they apply to PDF only. Other renderers have different abilities. For example, TIFF's may not work properly in the PostScript renderer since the CCITT embedding has not been implemented. On 12.05.2003 15:36:58 Jeremias Maerki wrote: 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. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing support for various graphics formats
ok, this goes a long way to clearing up my confusion ... On Mon, 12 May 2003, Jeremias Maerki wrote: Ok, let's go over this. I'm looking at the code: i'll probably break down one of these days and do the same ... GIF, JPEG, BMP, EPS and SVG are supported without any additional library: welll ... semantically, i'd say that SVG *does* require the additional batik stuff, but that's being pedantic. - GIF is supported through JDK classes. - JPEG is implemented directly because it can be more or less embeded 1:1 in a PDF. so far, so good. - BMP is directly implemented. ahhh ... the online docs claim that BMP is supported through JIMI or JAI, not via native support. good, that clears up *that* point. - 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. ahhh again. i was viewing the final PDF through xpdf on linux. perhaps that's why i saw nothing in the way of EPS output. i'll test that shortly, and see if xpdf has the same limitation. - SVG is supported through Batik and FOP's own code. yup, been there, done that, got my SVG output. 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. i think that's definitely worth noting on the graphics page, since TIFF is curerntly listed as supported by *either* JAI or JIMI. PNG images are supported through either JAI or JIMI whichever is present. yup, that's what i saw. 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. just to make sure i understand this part, FOP is not responsible for processing the image in its entirety, just for perhaps recognizing the image type and invoking the correct library, right? after all, by saying that FOP supports an image format through JIMI or JAI, i'm assuming that all FOP has to do is call the appropriate routine for processing that image. that means that all that has to be done for FOP is to add the additional ImageReaders. is this even remotely close to accurate? 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. i'll check to see if this is why nothing shows up in xpdf. thanks. slowly but surely, i'm filling out my little cheat sheet. rday - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing support for various graphics formats
On Mon, 12 May 2003, Jeremias Maerki wrote: - 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. just FYI, linux's xpdf command will not display an EPS image, but it does show up in printed output. just another data point in a long list of data points. rday - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing support for various graphics formats
On 12.05.2003 16:06:04 Robert P. J. Day wrote: ok, this goes a long way to clearing up my confusion ... On Mon, 12 May 2003, Jeremias Maerki wrote: Ok, let's go over this. I'm looking at the code: i'll probably break down one of these days and do the same ... GIF, JPEG, BMP, EPS and SVG are supported without any additional library: welll ... semantically, i'd say that SVG *does* require the additional batik stuff, but that's being pedantic. Well, I'm well known to be imprecise from time to time. :-) - GIF is supported through JDK classes. - JPEG is implemented directly because it can be more or less embeded 1:1 in a PDF. so far, so good. - BMP is directly implemented. ahhh ... the online docs claim that BMP is supported through JIMI or JAI, not via native support. good, that clears up *that* point. - 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. ahhh again. i was viewing the final PDF through xpdf on linux. perhaps that's why i saw nothing in the way of EPS output. i'll test that shortly, and see if xpdf has the same limitation. Probably. GhostScript/GhostView works because it is a PostScript interpreter and can additionally understand PDF. - SVG is supported through Batik and FOP's own code. yup, been there, done that, got my SVG output. 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. i think that's definitely worth noting on the graphics page, since TIFF is curerntly listed as supported by *either* JAI or JIMI. PNG images are supported through either JAI or JIMI whichever is present. yup, that's what i saw. 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. just to make sure i understand this part, FOP is not responsible for processing the image in its entirety, just for perhaps recognizing the image type and invoking the correct library, right? Right. Although some image formats are implemented directly by FOP (JPEG, for example). Just being pedantic myself now. :-) after all, by saying that FOP supports an image format through JIMI or JAI, i'm assuming that all FOP has to do is call the appropriate routine for processing that image. that means that all that has to be done for FOP is to add the additional ImageReaders. is this even remotely close to accurate? It is. Although I think that the whole image thing could be improved. Actually, it should be possible to do an additional fallback after SVG to using JIMI or JAI directly to identify the image format and to extract header information. But that's something for the redesign. 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. i'll check to see if this is why nothing shows up in xpdf. thanks. slowly but surely, i'm filling out my little cheat sheet. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: testing support for various graphics formats
FYI ghostscript v8.00++ (and naturally ghostview) doesn't render postscript/eps inside pdf by default, unless you set -dDOPS flag on command line or ghostsview config. Reason for that is a security problem with postscript, which has file access to the client, who is interpreting the postscript file, like other programming languages. This will allow to embed postscript viruses into pdf documents invisible for the user. cu Torsten -Original Message- From: Robert P. J. Day [mailto:[EMAIL PROTECTED] Sent: Montag, 12. Mai 2003 16:12 To: [EMAIL PROTECTED] Subject: Re: testing support for various graphics formats On Mon, 12 May 2003, Jeremias Maerki wrote: - 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. just FYI, linux's xpdf command will not display an EPS image, but it does show up in printed output. just another data point in a long list of data points. rday - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing support for various graphics formats
Robert P. J. Day wrote: just FYI, linux's xpdf command will not display an EPS image, but it does show up in printed output. This is fairly obvious, as it is well known that xpdf is not a complete PS interpreter. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
