Form Comb Field
Hello, I'm about to start investigating how to have FOP generate a form comb field input area. By a "form comb field input area" I mean an area where the line is underlined, with letter areas separated by half-length pipes coming up from the underline. I do not plan to have this area pre-filled with text, but do plan to use it for form generation. Has anyone done anything like this previously and had any success; perhaps someone has already designed an SVG snippet they can share? Thanks, Josh The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer.
RE: How to get a tiled TIFF from FOP rather than striped
Robrez- This is actually an Apache XmlGraphics question that isn't specific to FOP. ImageWriterParams is sorely lacking in functionality for TIFF rendering. The class contains some JPEG-specific functionality and some TIFF-specific functionality, with some very minor crossover, but little in the way of customization. I have expanded this functionality for my own purposes for TIFFs with the patch here (use the latest patch plus ResolutionUnit.java): https://issues.apache.org/bugzilla/show_bug.cgi?id=50657 which allows explicit alteration of Resolution Unit, variable scaled resolutions and rows per strip. It is an excellent starting point for expanding custom TIFF functionality. -Josh -Original Message- From: robrez [mailto:resendez.j...@gmail.com] Sent: Friday, May 27, 2011 6:13 PM To: fop-users@xmlgraphics.apache.org Subject: How to get a tiled TIFF from FOP rather than striped Not really sure if this is a FOP question, a JAI question, or Both… I am successfully producing a TIFF via fop using a configuration file that has the following set for the renderer: [renderer mime=image/tiff] [compression]CCITT T.4[/compression] [/renderer] Because I am using CCITT compression, jai_imageio.jar is required. PROBLEM: I am pulling my hair out trying to figure how to force TILED rendering rather than STRIPED rendering of the tiff image. There does not appear to be any obvious way to configure JAI to produce such results. The only approach that looked (somewhat) plausible was found on the internets…. FOUserAgent ua = fopFactory.newFOUserAgent(); TIFFRenderer tr = new TIFFRenderer(); TIFFImageWriteParam trp = new TIFFImageWriteParam(Locale.US); //requires jai_imageio.jar trp.setTilingMode(TIFFImageWriteParam.MODE_DEFAULT); ua.setRendererOverride(tr); Which is swell… but, I don’t see any sort of ‘setImageWriteParam()’ method ANYWHERE… the closest thing I’ve seen is – TIFFRenderer tr = new TIFFRenderer(); ImageWriterParams imp = tr.getWriterParams(); And as far as I can tell, ImageWriterParams has nothing to do with TIFFImageWriteParam (extends ImageWriteParam). All of the example code with regards to TIFFImageWriteParam involves direct interaction with the output stream… doesn’t really feel like something that is easily done or should even be attempted given my exact usage – sending xsl-fo to FOP who is then using JAI for tiff rendering. Any help would be greatly appreciated!!! -- View this message in context: http://old.nabble.com/How-to-get-a-tiled-TIFF-from-FOP-rather-than-striped-tp31720664p31720664.html Sent from the FOP - Users mailing list archive at Nabble.com. - The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer.
RE: Font Weight
Thanks Medhi, but as I've explained we're trying to move away from producing PostScript files and instead produce TIFF files. Our old practice: produce a PostScript via FOP and use a third-party software to convert to TIFF. Our future practice: just produce the TIFF via FOP. My goal is to get the font to render a bit darker in the TIFF than it is being produced at this time in order to come closer to the quality of the image produced by PostScript then converting to TIFF. -Josh -Original Message- From: mehdi houshmand [mailto:med1...@gmail.com] Sent: Thursday, March 10, 2011 3:10 AM To: fop-users@xmlgraphics.apache.org Subject: Re: Font Weight Hi Guys, Sorry to jump onto this so late in the game, but if you're trying to using TTF fonts with PostScript there is a branch called Temp_TrueTypeInPostScript which may help you. It allows you to embed TTFs in the PostScript which will mean you won't have to have the font installed on your printer and you can reference the font-file from your fop.xconf. If you have any issues I'd be more than happy to help. Mehdi On 9 March 2011 21:24, Marquart, Joshua D joshua.marqu...@firstdata.com wrote: The process that we have to take user-generated input and end up with a G4 TIFF file. The current process is like this: 1 - We've got a front-end system that generates HTML from XSLT with a flag for input purposes (input form fields are generated), or output style. 2 - Generated html is passed through a transformer with html_to_fo.xsl applied to create XSL-FO data. 3a - Today, we take the resulting XSL-FO data and use FOP to generate a PostScript file, which is sent to a legacy third party library that transforms the PostScript into a beautiful near-identical G4 TIFF. For technical reasons, we have to stop using the third party library which is both EOL and creates issues (the library does not ignore a console shutdown signal and kills the service). 3b - Tomorrow, I'd like to just take the resulting XSL-FO data and generate the G4 TIFF files using FOP (hence my TIFF-focused Buzilla contributions 49695, 49696 and 50657) . At the moment, I'm just straight generating the TIFF from the XSL-FO data. It mostly looks like the source, but for some reason the lesser fonts are a lot lighter. It's my understating that Fop is output-only when it comes to PostScript, correct? For comparison purposes, I'm generating the PostScript and Tiff files as flat files. Then I 1 - compare them side-by-side on the screen 2 - throw them both at a printer (and make sure the Tiff is sent through PhotoShop and not shrunk to fit). The printouts line up physically, but the font for any 10pt in the Tiff is much lighter (likely due to aliasing) than that produced with the PostScript, or even that produced by a Tiff that has undergone the process described in 3a above. With the Oddly comment quoted below, apparently the PostScript deferred to any,normal,400 and any,normal,700 when confronted with Arial,normal,400, which is not a big deal because my eventual goal is removing the PostScript. -Josh From: Eric Douglas [mailto:edoug...@blockhouse.com] Sent: Wednesday, March 09, 2011 2:18 PM To: fop-users@xmlgraphics.apache.org Subject: RE: Font Weight 1. If it's actually printing the wrong font that's a different issue. We'd have to see your font code for that. That would be everything in the font tags in the xconf file if you're using one, or your font loading method if you're using embedded code, plus the text in the fo which references the font triplet values. 2. What do you mean by lightness? Are you using the PSRenderer and/or TIFFRenderer to send output directly to a printer, to the same printer, back to back? Are you somehow using both renderers to generate image files to compare, or comparing something printed to something on the screen? Did you use the PSRenderer to send output directly to a printer and the TIFFRenderer to create an image file then send that image file to the printer? It sounds like we need more details on what you're trying to do. It sounds like you may be comparing apples to oranges. From: Marquart, Joshua D [mailto:joshua.marqu...@firstdata.com] Sent: Wednesday, March 09, 2011 2:07 PM To: Glenn Adams Cc: fop-users@xmlgraphics.apache.org Subject: RE: Font Weight I was just doing research on this topic, came back here to supplement my message with info, and saw you already beat me to it. Helpful method: getFontInfo().dumpAllTripletsToSystemOut() So... yes, I do not have fonts installed for font weights of 300, 500, etc. and that would account for resolving to 400/700. The problem I'm seeing is when generating a PostScript and a Tiff from the same xsl-fo file. The text generated in the Tiff (for the 400 weight) appears much lighter than identical text in the PostScript and is likely due to using
RE: Font Weight
“FOP does not synthesize fonts with different weights. You need to supply the fonts with the weights you specify in FO content.” I understand Fop doesn’t synthesize the weights. I understand that it has two specific built-in weights (700 and 400) that are being used to replace other weights per the following: When I set-up using a Java2DRenderer and specify the following FO content snippets: fo:table-cell font-size=10pt font-family=Helveticafo:block line-height=13pt fo:block white-space-collapse=true fo:inline font-weight=900900 Weight /fo:inline … fo:inline font-weight=800800 Weight /fo:inline … fo:inline font-weight=700700 Weight /fo:inline … fo:inline font-weight=600600 Weight /fo:inline … fo:inline font-weight=500500 Weight /fo:inline … fo:inline font-weight=400400 Weight /fo:inline … fo:inline font-weight=300300 Weight /fo:inline /fo:block/fo:block/fo:table-cell … the logger gives me the following information: WARNING: Font Helvetica,normal,900 not found. Substituting with Helvetica,normal,700. WARNING: Font Helvetica,normal,800 not found. Substituting with Helvetica,normal,700. WARNING: Font Helvetica,normal,600 not found. Substituting with Helvetica,normal,700. WARNING: Font Helvetica,normal,500 not found. Substituting with Helvetica,normal,400. WARNING: Font Helvetica,normal,300 not found. Substituting with Helvetica,normal,400. So I would need to supply very specific replacement fonts for Helvetica,normal,900 ( and 800-300, not counting 400)? (Same as above when replacing Helvetica with Arial). I DO understand the following: 1- that per the current specs, item 7.9.9 for font-weight has a “TODO relative font weights” message. 2 - that per the current build, the font classes generated from Helvetica.xml and HelveticaBold.xml are used for 400 and 700 respectively 3 - that per the fuzzy replacement, 700 is used for 900-600 and 400 is used for 500-100(probably). So my questions still stand 1 - is there a simpler way to use / access / apply a darker 500 or 600 weight Helvetica and if so, what’s the best process to handle it given the codebase? 2 - should I instead render a “Helvetica500.xml” and generate the appropriate font class; obviously since that’s not yet been done with the existing fop codebase, it is probably a lot more work than needed. 3 - Any other option I should pursue? If there is a process started to handle item 7.9.9, I would be happy to pitch in and help, I am just not certain where to start. Thanks, Josh From: Glenn Adams [mailto:gl...@skynav.com] Sent: Tuesday, March 08, 2011 6:40 PM To: fop-users@xmlgraphics.apache.org Cc: Marquart, Joshua D Subject: Re: Font Weight FOP does not synthesize fonts with different weights. You need to supply the fonts with the weights you specify in FO content. Regards, Glenn On Tue, Mar 8, 2011 at 4:31 PM, Marquart, Joshua D joshua.marqu...@firstdata.com wrote: I have a question about Font Weight. We’re using Helvetica and using FOP to take the FO file and generate it as both (1) a PostScript file and (2) a TIFF file. Additionally, we are able to use third-party software to take the PostScript file and convert it directly to a second TIFF file (for comparison reasons). Of course, the fonts on the TIFF from FOP are a little pixilated and the “normal” font could stand to be rendered a bit darker. I am using Helvetica and tried to set the font-weight to 500 or 600, but it gets replaced with weight 400, which is apparently the “normal” Helvetica font registered in the system. Font-weight Bold and values of 800 and 900 use the “bold” Helvetica which is weight 700. Is there an easy way to use / access a darker 500 or 600 weight Helvetica, or possibly render the or am I really sunk here? I’ve already extended the Java2DRenderer, for my own purposes. The following Graphics2D rendering hints don’t seem to do much when included: graphics.setRenderingHint(RenderingHints.KEY_FRACTIONALMETRICS, RenderingHints.VALUE_FRACTIONALMETRICS_ON); graphics.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON); graphics.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.VALUE_TEXT_ANTIALIAS_ON); graphics.setRenderingHint(RenderingHints.KEY_RENDERING, RenderingHints.VALUE_RENDER_QUALITY); graphics.setRenderingHint(RenderingHints.KEY_STROKE_CONTROL, RenderingHints.VALUE_STROKE_PURE); Suggestions would be very helpful. Much thanks, Josh in error, please notify First Data immediately by replying to this message and deleting it from your computer. - The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you
RE: Font Weight
I was just doing research on this topic, came back here to supplement my message with info, and saw you already beat me to it. Helpful method: getFontInfo().dumpAllTripletsToSystemOut() So… yes, I do not have fonts installed for font weights of 300, 500, etc. and that would account for resolving to 400/700. The problem I’m seeing is when generating a PostScript and a Tiff from the same xsl-fo file. The text generated in the Tiff (for the 400 weight) appears much lighter than identical text in the PostScript and is likely due to using the Java2DRenderer vs. the PsRenderer. Oddly, when I set the font to Arial in the xsl-fo: - the font in the resulting PostScript appears Times Roman - the font in the resulting Tiff is identical to the font used in the Tiff when Helvetica was specified. Other than hunting down, installing and registering a weight 500 or so font for Helvetica or Arial (where might I find one? No idea.), are there other options that might I employ to lessen the lightness of the 400-weight ? Thanks, -Josh From: Glenn Adams [mailto:gl...@skynav.com] Sent: Wednesday, March 09, 2011 12:02 PM To: Marquart, Joshua D Cc: fop-users@xmlgraphics.apache.org Subject: Re: Font Weight Josh, What you have not said yet is whether you actually have (on your system) a font with the desired weight or not. Specifically, do you actually have installed multiple font instances with the distinct weights you wish to reference? If you do not, then it doesn't do much good to discuss referring to them. On the other hand, if you do have distinct faces with weights 300, 500, 600, 800, 900, etc., installed, then it is merely a matter of ensuring that the reference in your FO file correctly maps to the associated font instance. That can be handled in different ways. So please answer whether you do have the fonts installed in the first place with these weights. G. On Wed, Mar 9, 2011 at 9:50 AM, Marquart, Joshua D joshua.marqu...@firstdata.com wrote: “FOP does not synthesize fonts with different weights. You need to supply the fonts with the weights you specify in FO content.” I understand Fop doesn’t synthesize the weights. I understand that it has two specific built-in weights (700 and 400) that are being used to replace other weights per the following: When I set-up using a Java2DRenderer and specify the following FO content snippets: fo:table-cell font-size=10pt font-family=Helveticafo:block line-height=13pt fo:block white-space-collapse=true fo:inline font-weight=900900 Weight /fo:inline … fo:inline font-weight=800800 Weight /fo:inline … fo:inline font-weight=700700 Weight /fo:inline … fo:inline font-weight=600600 Weight /fo:inline … fo:inline font-weight=500500 Weight /fo:inline … fo:inline font-weight=400400 Weight /fo:inline … fo:inline font-weight=300300 Weight /fo:inline /fo:block/fo:block/fo:table-cell … the logger gives me the following information: WARNING: Font Helvetica,normal,900 not found. Substituting with Helvetica,normal,700. WARNING: Font Helvetica,normal,800 not found. Substituting with Helvetica,normal,700. WARNING: Font Helvetica,normal,600 not found. Substituting with Helvetica,normal,700. WARNING: Font Helvetica,normal,500 not found. Substituting with Helvetica,normal,400. WARNING: Font Helvetica,normal,300 not found. Substituting with Helvetica,normal,400. So I would need to supply very specific replacement fonts for Helvetica,normal,900 ( and 800-300, not counting 400)? (Same as above when replacing Helvetica with Arial). I DO understand the following: 1- that per the current specs, item 7.9.9 for font-weight has a “TODO relative font weights” message. 2 - that per the current build, the font classes generated from Helvetica.xml and HelveticaBold.xml are used for 400 and 700 respectively 3 - that per the fuzzy replacement, 700 is used for 900-600 and 400 is used for 500-100(probably). So my questions still stand 1 - is there a simpler way to use / access / apply a darker 500 or 600 weight Helvetica and if so, what’s the best process to handle it given the codebase? 2 - should I instead render a “Helvetica500.xml” and generate the appropriate font class; obviously since that’s not yet been done with the existing fop codebase, it is probably a lot more work than needed. 3 - Any other option I should pursue? If there is a process started to handle item 7.9.9, I would be happy to pitch in and help, I am just not certain where to start. Thanks, Josh From: Glenn Adams [mailto:gl...@skynav.com] Sent: Tuesday, March 08, 2011 6:40 PM To: fop-users@xmlgraphics.apache.org Cc: Marquart, Joshua D Subject: Re: Font Weight FOP does not synthesize fonts with different weights. You need to supply the fonts with the weights you specify in FO content. Regards, Glenn On Tue, Mar 8, 2011 at 4:31 PM, Marquart, Joshua D joshua.marqu
RE: Font Weight
The process that we have to take user-generated input and end up with a G4 TIFF file. The current process is like this: 1 - We've got a front-end system that generates HTML from XSLT with a flag for input purposes (input form fields are generated), or output style. 2 - Generated html is passed through a transformer with html_to_fo.xsl applied to create XSL-FO data. 3a - Today, we take the resulting XSL-FO data and use FOP to generate a PostScript file, which is sent to a legacy third party library that transforms the PostScript into a beautiful near-identical G4 TIFF. For technical reasons, we have to stop using the third party library which is both EOL and creates issues (the library does not ignore a console shutdown signal and kills the service). 3b - Tomorrow, I'd like to just take the resulting XSL-FO data and generate the G4 TIFF files using FOP (hence my TIFF-focused Buzilla contributions 49695, 49696 and 50657) . At the moment, I'm just straight generating the TIFF from the XSL-FO data. It mostly looks like the source, but for some reason the lesser fonts are a lot lighter. It's my understating that Fop is output-only when it comes to PostScript, correct? For comparison purposes, I'm generating the PostScript and Tiff files as flat files. Then I 1 - compare them side-by-side on the screen 2 - throw them both at a printer (and make sure the Tiff is sent through PhotoShop and not shrunk to fit). The printouts line up physically, but the font for any 10pt in the Tiff is much lighter (likely due to aliasing) than that produced with the PostScript, or even that produced by a Tiff that has undergone the process described in 3a above. With the Oddly comment quoted below, apparently the PostScript deferred to any,normal,400 and any,normal,700 when confronted with Arial,normal,400, which is not a big deal because my eventual goal is removing the PostScript. -Josh From: Eric Douglas [mailto:edoug...@blockhouse.com] Sent: Wednesday, March 09, 2011 2:18 PM To: fop-users@xmlgraphics.apache.org Subject: RE: Font Weight 1. If it's actually printing the wrong font that's a different issue. We'd have to see your font code for that. That would be everything in the font tags in the xconf file if you're using one, or your font loading method if you're using embedded code, plus the text in the fo which references the font triplet values. 2. What do you mean by lightness? Are you using the PSRenderer and/or TIFFRenderer to send output directly to a printer, to the same printer, back to back? Are you somehow using both renderers to generate image files to compare, or comparing something printed to something on the screen? Did you use the PSRenderer to send output directly to a printer and the TIFFRenderer to create an image file then send that image file to the printer? It sounds like we need more details on what you're trying to do. It sounds like you may be comparing apples to oranges. From: Marquart, Joshua D [mailto:joshua.marqu...@firstdata.com] Sent: Wednesday, March 09, 2011 2:07 PM To: Glenn Adams Cc: fop-users@xmlgraphics.apache.org Subject: RE: Font Weight I was just doing research on this topic, came back here to supplement my message with info, and saw you already beat me to it. Helpful method: getFontInfo().dumpAllTripletsToSystemOut() So... yes, I do not have fonts installed for font weights of 300, 500, etc. and that would account for resolving to 400/700. The problem I'm seeing is when generating a PostScript and a Tiff from the same xsl-fo file. The text generated in the Tiff (for the 400 weight) appears much lighter than identical text in the PostScript and is likely due to using the Java2DRenderer vs. the PsRenderer. Oddly, when I set the font to Arial in the xsl-fo: - the font in the resulting PostScript appears Times Roman - the font in the resulting Tiff is identical to the font used in the Tiff when Helvetica was specified. Other than hunting down, installing and registering a weight 500 or so font for Helvetica or Arial (where might I find one? No idea.), are there other options that might I employ to lessen the lightness of the 400-weight ? Thanks, -Josh From: Glenn Adams [mailto:gl...@skynav.com] Sent: Wednesday, March 09, 2011 12:02 PM To: Marquart, Joshua D Cc: fop-users@xmlgraphics.apache.org Subject: Re: Font Weight Josh, What you have not said yet is whether you actually have (on your system) a font with the desired weight or not. Specifically, do you actually have installed multiple font instances with the distinct weights you wish to reference? If you do not, then it doesn't do much good to discuss referring to them. On the other hand, if you do have distinct faces with weights 300, 500, 600, 800, 900, etc., installed, then it is merely a matter of ensuring that the reference in your FO file correctly maps to the associated font
Font Weight
I have a question about Font Weight. We're using Helvetica and using FOP to take the FO file and generate it as both (1) a PostScript file and (2) a TIFF file. Additionally, we are able to use third-party software to take the PostScript file and convert it directly to a second TIFF file (for comparison reasons). Of course, the fonts on the TIFF from FOP are a little pixilated and the normal font could stand to be rendered a bit darker. I am using Helvetica and tried to set the font-weight to 500 or 600, but it gets replaced with weight 400, which is apparently the normal Helvetica font registered in the system. Font-weight Bold and values of 800 and 900 use the bold Helvetica which is weight 700. Is there an easy way to use / access a darker 500 or 600 weight Helvetica, or possibly render the or am I really sunk here? I've already extended the Java2DRenderer, for my own purposes. The following Graphics2D rendering hints don't seem to do much when included: graphics.setRenderingHint(RenderingHints.KEY_FRACTIONALMETRICS, RenderingHints.VALUE_FRACTIONALMETRICS_ON); graphics.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON); graphics.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.VALUE_TEXT_ANTIALIAS_ON); graphics.setRenderingHint(RenderingHints.KEY_RENDERING, RenderingHints.VALUE_RENDER_QUALITY); graphics.setRenderingHint(RenderingHints.KEY_STROKE_CONTROL, RenderingHints.VALUE_STROKE_PURE); Suggestions would be very helpful. Much thanks, Josh - The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer.
RE: Font Weight
Of course, I subscribe to the DIGEST version and totally missed today's thread of font substitution question which is similarly related. I have seen the following TODO note: 7.9.9 font-weight Basic partial partial partial TODO relative font weights I plan to contact fop-dev and see if there is any way I can help with this. -Josh - The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: Various TIFF Rendering Questions
- Resolution Unit to inches (2); I'm currently getting Centimeters (3) As you noticed already, this is currently hard-coded. A change would be necessary here. Yeah, and a fairly large change it would be, according to the source code. Is there a recommendation to use centimeters over inches, over was it just coded that way due to cultural preference (Europeans prefer metric; Americans prefer U.S. Units)? I am very willing to coordinate to help code an abstraction of the Resolution Unit. Meanwhile, I'm working to replace the Tiff Renderer with one of my own and override the Tiff Writer, but I can't get the ImageWriterRegistry.register() method to overrite with my custom ImageIOImageWriter class. Services loads the appropriate writers to ImageWriterRegistry, but default-preferred-order.properties is in the same package level as the class and I don't know if I want to mess with my ClassLoader to check in the base package level first. Unfortunately, due to getPriority() using the internal default properties file, the .imageio classes (priority 2000) are always preferred and my ImageWriter is never found; additionally, there is no way to set a priority when registering the ImageWriter. The comment for register() states Registers a new ImageWriter implementation in the registry. If an ImageWriter for the same target MIME type has already been registered, it is overwritten with the new one. Which, due to priority, ends up being false. I have a solution for this requiring alterations to ImageWriterRegistry; my current workaround is a custom Renderer that doesn't use ImageWriterRegistry. I have read that producing a TIFF as one large strip / one entry per page per above results in a similar quality file with an overall smaller footprint. Where have you read that? On the Sun forums: http://forums.sun.com/thread.jspa?threadID=5161294 I haven't tested it myself, but it looks like it produces the sort of file I'm aiming for, and I'll see what I can do to incorporate portions of his solution into my own code. -Josh - The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Various TIFF Rendering Questions
All- Per my earlier posts, I'm converting FO to TIFF; I would like to be able to set - Resolution Unit to inches (2); I'm currently getting Centimeters (3) - Rows Per Strip to preference one large strip (length of the ImageLength field) instead of value 1 - StripOffsets to result in one entry per page (one large strip), rather than one per row - StripByteCounts to be the number of bytes in the page after compression. I have read that producing a TIFF as one large strip / one entry per page per above results in a similar quality file with an overall smaller footprint. Are these settings possible in FOP to TIFF conversion? I figure these would be Renderer Options, but so far I'm not finding any data on this. I'll continue looking and post a solution if I find anything, but if anyone happens to know the answers to the above, that would be helpful. Thanks, -Josh - The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer.
RE: Various TIFF Rendering Questions
Investigation ongoing, but it looks like Resolution Unit is hardcoded default to Centimeters (3) in the updateMetadata method of org.apache.xmlgraphics.image.writer.imageio.ImageIOTIFFImageWriter.class -Josh - The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer.
RE: XML to TIFF CITT conversion - aid requested
As I noted in my original post, I'd follow-up with any findings. In my research (I walked through TIFFRendererConfigurator) I discovered the reason the following suggested in-line code was not working FOUserAgent ua = fopFactory.newFOUserAgent(); TIFFRenderer renderer = new TIFFRenderer(); renderer.setUserAgent(ua); renderer.getWriterParams().setCompressionMethod(TIFFConstants.COMPRESSIO N_CCITT_T6); ua.setRendererOverride(renderer); It is missing the following line after setUserAgent() renderer.setBufferedImageType(BufferedImage.TYPE_BYTE_BINARY); SIDE-EFFECT NOTE: If you call on a Renderer which extends Java2DRenderer you don't need to call ua.setRenfererOverride(renderer) as this is side-effect called in renderer.setUserAgent(ua) Hope this helps anyone who reads this going forward. -Josh - The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: XML to TIFF CITT conversion - aid requested
Resolved. I walked through the Main class code and replicated the steps. Part of my problem was I was trying to use the java code posted earlier instead of the userconfig.xml FOUserAgent ua = fopFactory.newFOUserAgent(); TIFFRenderer renderer = new TIFFRenderer(); renderer.setUserAgent(ua); renderer.getWriterParams().setCompressionMethod(TIFFConstants.COMPRESSIO N_CCITT_T6); ua.setRendererOverride(renderer); The above will throw the exception I had been seeing. Thanks for all the help! I'll see what I can do to contribute to the group. -Josh -Original Message- From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch] Sent: Wednesday, July 14, 2010 2:49 AM To: fop-users@xmlgraphics.apache.org Subject: Re: XML to TIFF CITT conversion - aid requested Hi Joshua Make the config file: fop version=1.0 renderers renderer mime=image/tiff compressionCCITT T.6/compression /renderer /renderers /fop ...and you're there. As for your other question, you can do something like: FOUserAgent ua = fopFactory.newFOUserAgent(); TIFFRenderer renderer = new TIFFRenderer(); renderer.setUserAgent(ua); renderer.getWriterParams().setCompressionMethod(TIFFConstants.COMPRESSIO N_CCITT_T6); ua.setRendererOverride(renderer); ...but the above only applies to FOP 0.95 or later, I think. On 14.07.2010 00:48:13 Marquart, Joshua D wrote: Hello, I've been working on a project to transform XML to TIFF in the CITT G4 Format and have read several threads regarding the conversion, which has lead me to believe conversion is a common problem among users. Most of the G4 TIFF-related threads end with guru JM providing an explanation, but with no follow-up response from the thread-starting user as to whether the explanation/solution worked. I promise if my issue gets resolved, I will post a success story as a follow-up to this thread. Here is my situation: I am trying to convert a FOP-readable xml file into a G4 TIFF. No matter what I do, it applies as PackBits. In addition to resolving this, I am curious as to why there appears to be no programmatic way to set CCITT compression within the code (ex: a setCompression(String) method), when TIFFRenderer even contains String constants representing the three available compression types. Also, I could not find a sample configuration file in the distribution; maybe I missed it. Any help / advice would be much appreciated, thanks. -Josh (details follow) JARS on CLASSPATH: avalon-framework-4.2.0.jar batik-all-1.6.jar commons-io-1.3.1.jar commons-logging-1.0.4.jar fop.jar (implementation.94) serializer-2.7.0.jar xaland-2.7.0.jar xercesImpl-2.7.1.jar xml-apis-1.3.02.jar xmlgraphics-commons-1.2.jar log4j-1.2.13.jar jai-imageio.jar (implementation 1.1) FILES: There are 3 files involved in this (contents follow) FILE 1 - testFop.xml This is the fop formatted xml; I've successfully transformed it to PostScript and Tiff. FILE 2 - tiffFopConfig.xml This only contains the compression line for CCITT T.6 FILE 3 - FopTiffTester.javaThis is the java file for conversion. The code is abstracted from my own larger codebase where I do instantiate a single fopFactory and perform best practices - no need for best practices on this example, IMHO. :-) FILE CONTENT: FILE 1 - testFop.xml ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master margin-top=0.0in margin-bottom=0.0in page-width=8.5in page-height=11.0in master-name=single fo:region-body padding=0pt 0pt margin-bottom=0cm margin-top=0.5cm margin-right=1cm margin-left=1cm/ fo:region-before padding=0pt display-align=after extent=1cm region-name=left-top/ fo:region-after padding=0pt display-align=before extent=1cm region-name=footer/ fo:region-start padding=0pt display-align=center precedence=true extent=1in region-name=outside/ fo:region-end padding=0pt display-align=after precedence=true extent=1in region-name=inside/ /fo:simple-page-master fo:page-sequence-master master-name=contents fo:repeatable-page-master-reference master-reference=single/ /fo:page-sequence-master /fo:layout-master-set fo:page-sequence initial-page-number=2 master-reference=contents fo:flow flow-name=xsl-region-body fo:table width=100% table-layout=fixed fo:table-column column-width=19cm/ fo:table-body fo:table-row fo:table-cell font-size=9pt font-family=Helvetica fo:block line-height=14pt fo:block white-space-collapse=true fo:block font-family=Helvetica font-size=10ptTest test test test test times five./fo:block /fo:block /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table /fo:flow /fo:page-sequence /fo:root FILE 2 - tiffFopConfig.xml fop version=1.0 renderer mime=image/tiff compressionCCITT T.6/compression /renderer /fop FILE 3 - FopTiffTester.java import java.io.BufferedOutputStream; import java.io.File; import
RE: XML to TIFF CITT conversion - aid requested
I updated everything to the latest JAR and am still getting the above compression exception. What's meant by this is that I even moved to Fop .95 to check (per the jar list that followed where I note .95 as the version) and am still getting the problem. I'm curious if other can replicate it, or if my system is unique, or if possibly I am missing something. Beyond the JAI Tools jar, does there have to be an alteration to the JRE in use, as with a JAI deployment? -Josh - The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: XML to TIFF CITT conversion - aid requested
Hi Jeremias, I've changed the app as follows. Apparently JAI Tools JAR gets ignored because I'm using xmlgraphics 1.2, which is bundled with fop 94. I updated to xmlgraphics 1.4 and kept the same fop .94, and I'm getting the compression exception mentioned in the other e-mail: javax.imageio.IIOException: Bits per sample must be 1 for T6 compression! I updated everything to the latest JAR and am still getting the above compression exception. From what I can tell by viewing the source of the JAI Tools code, if the bits per sample array in the write function of TIFFT6Compressor isn't length 1 containing a value of 1 (which is appropriate for a Group 4 compression tiff), it throws. Bits per sample array size is set by the numBands calculated in IO Tools TIFFImageWriter, which is determined by the samplemodel and the colormodel. Bits per sample value (1 is needed) is set by the bitDepth, calculated in same, which since it needs to be 1, is determined by sampleSize[0], which is also set by samplemodel.getSampleSize() Since I see attachments work well in this mailing list, I'm attaching my latest JAVA file and FOP-formatted XSL file. Maybe my resulting xml is overkill in some way, causing an unexpectedly high value in samplemodel? I'm going to investigate further and see how the sampleModel is being set within the code and what values it received, but while I'm still researching, any advice would be greatly appreciated. Worst case on this, I'll end up trying to create a Graphics2D and using JAI Tools to create the TIFF (I'll make sure to post the code as a follow-up), or go back to our old way of generating a PostScript from FOP and using a third party tool to convert it to TIFF (a tactic I am trying to avoid). Also, semi-topical since it concerns TIFF conversion and since you're the one who made the fix, would you happen to know if the multi-threading issue with with Java2D renderer (Revision 895012) is resolved with xmlgraphics 1.4, or if that is still unreleased; I'm still getting up to speed on how / whether some specific revisions/fixes are applied to releases. Much Thanks, Josh (JAR LIST FOLLOWS) JAR LIST jai_imageio.jar (1.1) avalon-framework-4.2.0.jar batik-all-1.6.jar commons-logging-1.0.4.jar fop.jar (.95) serializer-2.7.0.jar xalan-2.7.0.jar xercesImpl-2.7.1.jar xml-apis-1.3.02.jar log4j-1.2.13.jar commons-io-1.4.jar xmlgraphics-commons-1.4.jar - The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer. FopTiffTester.java Description: FopTiffTester.java testFop.xsl Description: testFop.xsl - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: XML to TIFF CITT conversion - aid requested
Hi Jeremias, I've applied your change and now it proceeds, but I receive the following exception: java.lang.UnsupportedOperationException: Compression method not supported: CCITT T.6 at org.apache.xmlgraphics.image.writer.internal.TIFFImageWriter.createTIFFE ncodeParams(TIFFImageWriter.java:75) at org.apache.xmlgraphics.image.writer.internal.TIFFImageWriter.access$000( TIFFImageWriter.java:41) at org.apache.xmlgraphics.image.writer.internal.TIFFImageWriter$TIFFMultiIm ageWriter.writeImage(TIFFImageWriter.java:135) at org.apache.fop.render.bitmap.TIFFRenderer.stopRenderer(TIFFRenderer.java :140) Maybe I missed something with the JAI Tools jar? I'll take a look at the source as well and see what's supposed to happen. -Josh - The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
RE: XML to TIFF CITT conversion - aid requested
I've changed to using Xml Graphics 1.4 (from 1.2, which is bundled with fop94) and I get a different exception (entirety is post-sig). javax.xml.transform.TransformerException: javax.imageio.IIOException: I/O error writing TIFF file! ... Caused by: javax.imageio.IIOException: Bits per sample must be 1 for T6 compression! at com.sun.media.imageioimpl.plugins.tiff.TIFFT6Compressor.encode(TIFFT6Com pressor.java:178) at com.sun.media.imageioimpl.plugins.tiff.TIFFImageWriter.writeTile(TIFFIma geWriter.java:2309) at com.sun.media.imageioimpl.plugins.tiff.TIFFImageWriter.write(TIFFImageWr iter.java:2686) I'll see about updating to fop95.jar -Josh javax.xml.transform.TransformerException: javax.imageio.IIOException: I/O error writing TIFF file! at org.apache.xalan.transformer.TransformerIdentityImpl.transform(Transform erIdentityImpl.java:501) at FopTiffTester.main(FopTiffTester.java:61) Caused by: javax.imageio.IIOException: I/O error writing TIFF file! at org.apache.fop.area.RenderPagesModel.endDocument(RenderPagesModel.java:2 47) at org.apache.fop.area.AreaTreeHandler.endDocument(AreaTreeHandler.java:283 ) at org.apache.fop.fo.FOTreeBuilder.endDocument(FOTreeBuilder.java:171) at org.apache.xalan.transformer.TransformerIdentityImpl.endDocument(Transfo rmerIdentityImpl.java:962) at org.apache.xerces.parsers.AbstractSAXParser.endDocument(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl.endEntity(Unknown Source) at org.apache.xerces.impl.XMLEntityManager.endEntity(Unknown Source) at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source) at org.apache.xerces.impl.XMLEntityScanner.skipSpaces(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl$TrailingMiscDispatcher.dis patch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unkno wn Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(Transform erIdentityImpl.java:484) ... 1 more - javax.imageio.IIOException: I/O error writing TIFF file! at org.apache.fop.area.RenderPagesModel.endDocument(RenderPagesModel.java:2 47) at org.apache.fop.area.AreaTreeHandler.endDocument(AreaTreeHandler.java:283 ) at org.apache.fop.fo.FOTreeBuilder.endDocument(FOTreeBuilder.java:171) at org.apache.xalan.transformer.TransformerIdentityImpl.endDocument(Transfo rmerIdentityImpl.java:962) at org.apache.xerces.parsers.AbstractSAXParser.endDocument(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl.endEntity(Unknown Source) at org.apache.xerces.impl.XMLEntityManager.endEntity(Unknown Source) at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source) at org.apache.xerces.impl.XMLEntityScanner.skipSpaces(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl$TrailingMiscDispatcher.dis patch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unkno wn Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(Transform erIdentityImpl.java:484) at FopTiffTester.main(FopTiffTester.java:61) - javax.imageio.IIOException: I/O error writing TIFF file! at com.sun.media.imageioimpl.plugins.tiff.TIFFImageWriter.write(TIFFImageWr iter.java:2706) at com.sun.media.imageioimpl.plugins.tiff.TIFFImageWriter.insert(TIFFImageW riter.java:2903) at com.sun.media.imageioimpl.plugins.tiff.TIFFImageWriter.writeInsert(TIFFI mageWriter.java:2862) at com.sun.media.imageioimpl.plugins.tiff.TIFFImageWriter.writeToSequence(T IFFImageWriter.java:2754) at org.apache.xmlgraphics.image.writer.imageio.ImageIOImageWriter$IIOMultiI mageWriter.writeImage(ImageIOImageWriter.java:277) at org.apache.fop.render.bitmap.TIFFRenderer.stopRenderer(TIFFRenderer.java :140) at org.apache.fop.area.RenderPagesModel.endDocument(RenderPagesModel.java:2 45) at org.apache.fop.area.AreaTreeHandler.endDocument(AreaTreeHandler.java:283 ) at org.apache.fop.fo.FOTreeBuilder.endDocument(FOTreeBuilder.java:171) at org.apache.xalan.transformer.TransformerIdentityImpl.endDocument(Transfo rmerIdentityImpl.java:962) at org.apache.xerces.parsers.AbstractSAXParser.endDocument(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl.endEntity(Unknown Source) at org.apache.xerces.impl.XMLEntityManager.endEntity(Unknown Source) at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source) at
XML to TIFF CITT conversion - aid requested
Hello,
I've been working on a project to transform XML to TIFF in the CITT G4
Format and have read several threads regarding the conversion, which has
lead me to believe conversion is a common problem among users.
Most of the G4 TIFF-related threads end with guru JM providing an
explanation, but with no follow-up response from the thread-starting
user as to whether the explanation/solution worked. I promise if my
issue gets resolved, I will post a success story as a follow-up to this
thread.
Here is my situation:
I am trying to convert a FOP-readable xml file into a G4 TIFF. No
matter what I do, it applies as PackBits.
In addition to resolving this, I am curious as to why there appears to
be no programmatic way to set CCITT compression within the code (ex: a
setCompression(String) method), when TIFFRenderer even contains String
constants representing the three available compression types.
Also, I could not find a sample configuration file in the distribution;
maybe I missed it.
Any help / advice would be much appreciated, thanks.
-Josh (details follow)
JARS on CLASSPATH:
avalon-framework-4.2.0.jar
batik-all-1.6.jar
commons-io-1.3.1.jar
commons-logging-1.0.4.jar
fop.jar (implementation.94)
serializer-2.7.0.jar
xaland-2.7.0.jar
xercesImpl-2.7.1.jar
xml-apis-1.3.02.jar
xmlgraphics-commons-1.2.jar
log4j-1.2.13.jar
jai-imageio.jar (implementation 1.1)
FILES:
There are 3 files involved in this (contents follow)
FILE 1 - testFop.xml
This is the fop formatted xml; I've successfully transformed it to
PostScript and Tiff.
FILE 2 - tiffFopConfig.xml
This only contains the compression line for CCITT T.6
FILE 3 - FopTiffTester.javaThis is the java file for conversion. The
code is abstracted from my own larger codebase where I do instantiate a
single fopFactory and perform best practices - no need for best
practices on this example, IMHO. :-)
FILE CONTENT:
FILE 1 - testFop.xml
?xml version=1.0 encoding=UTF-8?
fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format;
fo:layout-master-set
fo:simple-page-master margin-top=0.0in margin-bottom=0.0in
page-width=8.5in page-height=11.0in master-name=single
fo:region-body padding=0pt 0pt margin-bottom=0cm margin-top=0.5cm
margin-right=1cm margin-left=1cm/
fo:region-before padding=0pt display-align=after extent=1cm
region-name=left-top/
fo:region-after padding=0pt display-align=before extent=1cm
region-name=footer/
fo:region-start padding=0pt display-align=center precedence=true
extent=1in region-name=outside/
fo:region-end padding=0pt display-align=after precedence=true
extent=1in region-name=inside/
/fo:simple-page-master
fo:page-sequence-master master-name=contents
fo:repeatable-page-master-reference master-reference=single/
/fo:page-sequence-master
/fo:layout-master-set
fo:page-sequence initial-page-number=2 master-reference=contents
fo:flow flow-name=xsl-region-body
fo:table width=100% table-layout=fixed
fo:table-column column-width=19cm/
fo:table-body
fo:table-row
fo:table-cell font-size=9pt font-family=Helvetica
fo:block line-height=14pt
fo:block white-space-collapse=true
fo:block font-family=Helvetica font-size=10ptTest test test test
test times five./fo:block
/fo:block
/fo:block
/fo:table-cell
/fo:table-row
/fo:table-body
/fo:table
/fo:flow
/fo:page-sequence
/fo:root
FILE 2 - tiffFopConfig.xml
fop version=1.0
renderer mime=image/tiff
compressionCCITT T.6/compression
/renderer
/fop
FILE 3 - FopTiffTester.java
import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileOutputStream;
import java.io.OutputStream;
import java.io.StringReader;
import java.net.URL;
import javax.xml.transform.Source;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.sax.SAXResult;
import javax.xml.transform.stream.StreamSource;
import org.apache.avalon.framework.configuration.Configuration;
import
org.apache.avalon.framework.configuration.DefaultConfigurationBuilder;
import org.apache.commons.io.FileUtils;
import org.apache.fop.apps.FOUserAgent;
import org.apache.fop.apps.Fop;
import org.apache.fop.apps.FopFactory;
import org.apache.fop.apps.MimeConstants;
import org.apache.log4j.helpers.Loader;
public class FopTiffTester {
public FopTiffTester() {}
public static void main(String[] args) {
try {
// Load the File Objects
File testPath = new File(C:\\test\\foptifftest\\);
testPath.mkdirs();
File fopFile = new File(testPath, testFop.xsl);
File tiffFile = new File(testPath,
String.valueOf(System.currentTimeMillis()) + .tiff);
// Read FOP File to String
String fopString = FileUtils.readFileToString(fopFile);
// Get Fop Factory and Configure
FopFactory fopFactory = FopFactory.newInstance();
URL configUrl =
Loader.getResource(tiffFopConfig.xml);
RE: How to initialize Log4j logging in Oracle 11g
Hi Jaynt, That is the standard Log4j warning message when Log4j logging is not configured correctly for the application. It can be safely ignored, but if you wish to configure your logging, you should throw a log4j.xml or log4j.properties configuration file into your classpath. Here is a link to the log4j wiki http://wiki.apache.org/logging-log4j/ -Josh -Original Message- From: Jayant Ghagre [mailto:jayant.gha...@ambest.com] Sent: Monday, July 12, 2010 4:04 PM To: fop-users@xmlgraphics.apache.org Subject: How to initialize Log4j logging in Oracle 11g Hello, I am getting following warning message when I execute FOP 0.95 in Oracle 11g using Java Stored procedure. How can I address this issue? log4j:WARN No appenders could be found for logger (org.apache.fop.util.ContentHandlerFactoryRegistry). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. Thanks, Jayant - The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer. - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
