Re: Special characters in AWT preview and PDF renderers
On Mon, 30 Aug 2010 18:31:18 +0300, Pascal Sancho pascal.san...@takoma.fr wrote: '#' indicates that the glyph is not available in any font used by FOP. Note that SVG uses the fonts installed in the system, while FOP needs ?? I think you mean the AWT renderer gets its fonts from the os and the pdf renderer needs special font configuration? That's the impression I got from http://xmlgraphics.apache.org/fop/1.0/output.html#general-fonts that used fonts are set in config file (if you use a non standard font). Like I said in my post, I have fonts auto-detect/ /fonts in my fop.xconf. Is this not sufficient? Anyhow, the thing that made me wonder is that special characters are working also in fop generated pdfs if they are outside svg images - it's only the ones in the svg images that are failing. I changed the font family reference in the svg files from font-family:Swiss,Helvetica,sans-serif; to font-family:Swiss,Helvetica,sans-serif,Tahoma,Verdana; and now the special characters are ok. From this it seems to me that this was simply an issue of the font families originally listed not containing the necessary glyphs. So not really a FOP issue at all, sorry for the noise. ::Antti:: - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Special characters in AWT preview and PDF renderers
Hi! I have an SVG image with greek symbols, e.g. text text-anchor=start x=3.13063 y=1.56532 style=fill:#00; font-family:Swiss,Helvetica,sans-serif; font-size: 4.69595 HEEL φ /text This renders fine in FOP AWT preview, but as # in PDF. The pdf is fine, too, if I change (in the SVG) the first line above to: text text-anchor=start x=3.13063 y=1.56532 style=fill:#00; font-size: 4.69595 i.e. remove the font references. I know the different renderers handle fonts differently, but this far I have been able to use os fonts in pdf by having fonts auto-detect/ /fonts in my fop.xconf However, in this case it does not seem to help. Is there some other magic I need to do to make os fonts work ok inside svg? Or am I missing something else? Environment: fop 0.95 and 1.0, java 1.6.0_20, win xp sp 3 ::Antti:: - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
GC overhead limit exceeded on a 64-bit jvm
Hi! I am facing a strange memory problem with FOP 0.95. I have a rather large xsl-fo file (size 10 574 859 bytes) containing references to 1062 svg images and resulting in a 683 page pdf. What is strange is that FOP renders this fine on a 32-bit jvm, but fails with GC overhead limit exceeded on a 64-bit jvm even if given double the memory the 32-bit process is given. Here's the exception: 14.6.2010 11:33:10 org.apache.fop.render.AbstractRenderer renderXML SEVERE: Some XML content will be ignored. Could not render XML java.lang.OutOfMemoryError: GC overhead limit exceeded at java.util.Arrays.copyOfRange(Unknown Source) at java.lang.String.init(Unknown Source) at java.lang.StringBuffer.toString(Unknown Source) at org.apache.batik.bridge.SVGFontUtilities.getFontFamily(Unknown Source) at org.apache.batik.bridge.SVGTextElementBridge.getFontList(Unknown Source) at org.apache.batik.bridge.SVGTextElementBridge.getAttributeMap(Unknown Source) at org.apache.batik.bridge.SVGTextElementBridge.fillAttributedStringBuffer(Unknown Source) at org.apache.batik.bridge.SVGTextElementBridge.buildAttributedString(Unknown Source) at org.apache.batik.bridge.SVGTextElementBridge.computeLaidoutText(Unknown Source) at org.apache.batik.bridge.SVGTextElementBridge.buildGraphicsNode(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source) at org.apache.batik.bridge.GVTBuilder.build(Unknown Source) at org.apache.fop.render.pdf.PDFSVGHandler.renderSVGDocument(PDFSVGHandler.java:188) at org.apache.fop.render.AbstractGenericSVGHandler.handleXML(AbstractGenericSVGHandler.java:57) at org.apache.fop.render.AbstractRenderer.renderXML(AbstractRenderer.java:808) at org.apache.fop.render.PrintRenderer.renderDocument(PrintRenderer.java:169) at org.apache.fop.render.pdf.PDFImageHandlerXML.generateImage(PDFImageHandlerXML.java:55) at org.apache.fop.render.pdf.PDFRenderer.putImage(PDFRenderer.java:1745) at org.apache.fop.render.pdf.PDFRenderer.renderImage(PDFRenderer.java:1679) at org.apache.fop.render.AbstractRenderer.renderViewport(AbstractRenderer.java:743) at org.apache.fop.render.AbstractPathOrientedRenderer.renderViewport(AbstractPathOrientedRenderer.java:621) at org.apache.fop.render.AbstractRenderer.renderInlineArea(AbstractRenderer.java:626) at org.apache.fop.render.pdf.PDFRenderer.renderInlineArea(PDFRenderer.java:1345) at org.apache.fop.render.AbstractRenderer.renderLineArea(AbstractRenderer.java:601) at org.apache.fop.render.pdf.PDFRenderer.renderLineArea(PDFRenderer.java:1336) FOP does not stop at the first one - there are several of these in FOP output. The resulting pdf is broken, though. Here's version information on the 32-bit jvm (that is able to perform the task both with -client and -server jvms): C:\Tempjava -version java version 1.6.0_12 Java(TM) SE Runtime Environment (build 1.6.0_12-b04) Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing) And here's the corresponding info for the 64-bit jvm (only -server jvm available): g:\workjava -version java version 1.6.0_12 Java(TM) SE Runtime Environment (build 1.6.0_12-b04) Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode) On 32-bit jvm -Xmx500m is sufficient, but on the 64-bit jvm even -Xmx1000m is not enough. Any ideas on how to get around this are much appreciated. ::Antti:: - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: GC overhead limit exceeded on a 64-bit jvm
On Mon, 14 Jun 2010 13:04:05 +0300, Georg Datterl georg.datt...@geneon.de wrote: Let's blame java: http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#par_gc.oom Thanks for the link. I already knew what this exception results from but what baffles me is that how the runtime profile can be so different for 32 and 64-bit jvms for the same application + the same input data. The 32-bit process being able to complete with -Xmx500m and 64-bit jvm still failing with -Xmx1000m seems to indicate that the program, when run 64-bit, is keeping references to lots more data than the 32-bit version. Jvm being stuck in gc so that 98% of the time is spent in gc and no (significant amount of) memory is freed indicates either that the app is keeping references to large amounts of data or GC can't reclaim memory due to a jvm bug. The latter is possible but the former is much more common. Anyone else run into this issue with FOP or any other Java program? I don't mean just the GC overhead limit exceeded, but this kind of difference in results with 32- and 64-bit jvms. ::Antti:: - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: AW: GC overhead limit exceeded on a 64-bit jvm
On Mon, 14 Jun 2010 13:21:13 +0300, Georg Datterl georg.datt...@geneon.de wrote: Anyway, I used -Xincgc and had no more problems with the exception. That did the trick for me, too. Thanks a lot for your help! ::Antti:: - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: AW: AW: GC overhead limit exceeded on a 64-bit jvm
On Mon, 14 Jun 2010 16:47:11 +0300, Georg Datterl georg.datt...@geneon.de wrote: The ant task has to start a java VM, too. You just have to find out, where the VM is started and set the switch there. In case you don't want to dig into ant or fop startup scripts, a quick and dirty solution is to set the environment variable JAVA_TOOL_OPTIONS to have value -Xincgc This environment variable will be picked up by any jvm, even embedded ones. Its contents will be prepended to jvm startup options. ::Antti:: - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Problem w/ svg image size in pdf
Hi! When I use fop to directly print a document containing an svg image, the image is produced w/ correct size on paper. However, if I produce pdf and then print it w/ adobe acrobat reader, the image is sligtly (ratio about 14/15) smaller than the original. This is significant as I have to produce documents containing drawings with exact scale. The fop faq has a section about there being differences in print and pdf output, but it only talks about fonts, line heights and such, but nothing about picture sizes. Anyhow, it seems to most likely be an acrobat reader issue, since ghostview measures the image size correctly and it prints the rights size. Is this an actual acrobat reader bug or am I doing something wrong when generating the pdf? BTW, I recalled a long time ago having used measuring tools in acrobat reader to measure sizes of things in a document in centimeters. Enabling the toolbar failed - Tools - Customize Toolbar dialog contains Measuring Toolbar, but it is marked w/ an asterix meaning Only available when document rights are enabled. Can I grant these rights when generating the pdf from fop? If necessary, I can post the fo and svg files in question (quite minimal - the document only contains the single svg image). Environment: fop 0.95 java 1.5.0_15 win xp sp 2 adobe reader 8.1.3 Fop was invoked w/ no special options: fop.bat -fo test2.fo -pdf test2.pdf fop.bat -fo test2.fo -print ::Antti:: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem w/ svg image size in pdf
On Fri, 05 Dec 2008 12:46:56 +0200, Jeremias Maerki [EMAIL PROTECTED] wrote: Please see here: http://xmlgraphics.apache.org/fop/faq.html#pdf-print-contortion Thanks! I somehow missed that. Combination of setting scaling = none in the print settings and using ps driver instead of pcl driver solved the problem. ::Antti:: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fo:external-graphic w/ # in file name
On Wed, 03 Dec 2008 09:23:25 +0200, Jeremias Maerki [EMAIL PROTECTED] wrote: # in a URI has a special meaning. It's used as separator for the URI fragment. You have to escape that character using %23 (if I've looked that up correctly). url(file:/C:/Temp/test123/m2%231_1.svg) Thanks! That works perfect. ::Antti:: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
fo:external-graphic w/ # in file name
Hi! I noticed that if I have # in the file name of an external graphics file, fop is unable to find it. If I rename the file (and change the .fo file accordingly) it works. Here's what I have: fo:external-graphic src=url(file:/C:/Temp/test123/m2#1_1.svg) width=auto height=auto content-width=auto content-height=auto content-type=content-type:image/svg+xml text-align=center/ Here's the error message: 3.12.2008 8:46:20 org.apache.fop.fo.flow.ExternalGraphic bind SEVERE: Image not found: file:/C:/Temp/test123/m2#1_1.svg The file does exist: C:\Temp\test123dir m2#1_1.svg Volume in drive C is Local Disk Volume Serial Number is F8AC-6817 Directory of C:\Temp\test123 28.11.2008 13:2998 080 m2#1_1.svg 1 File(s) 98 080 bytes 0 Dir(s) 63 134 236 672 bytes free Environment: fop 0.95 windows xp sp2 java 1.5.0_15 ::Antti:: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fop Progress Output
On Thu, 19 Jun 2008 11:30:56 +0300, Andreas Delmelle [EMAIL PROTECTED] wrote: OTOH, /if/ one knows in advance how many pages a document is supposed to generate, then with the new event-mechanism, it would be possible to catch the new-page events, and derive a percentage from there. IMO it would be great just to be able to get an event every time a page is produced (or even every time a page sequence is produced). This would enable showing something other than a processing, please wait to the user - having a (somewhat) realtime running count on the number of pages produced, even w/ no idea on how much more there is to go, would be much better than nothing. That way the user could see concrete progress and know that the process is not stuck. ::Antti:: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Print preview default zoom
On Wed, 11 Jun 2008 15:24:26 +0300, Jeremias Maerki [EMAIL PROTECTED] wrote: thanks for the report. This is a bug, or rather: was. ;-) Can you please verify that my fix [1] improves the situation? It seems to work correctly now. Thanks! -Antti- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Print preview default zoom
Hi! I had a problem that svg images were rasterized w/ too low a resolution when printed. This was easy enough to solve - I set the target resolution to high enough value via an FOUserAgent object: userAgent.setTargetResolution( 280f ) ; However, this seems to have an unpleasant side effect: when using print preview, the default zoom is such that only about a quarter of the page is shown (which may have something to do w/ that I set the target resolution to be 4 times higher than the default). Now, I could of course set the target resolution higher when printing and lower when previewing, but that is not a very tempting solution as then if the user prints from print preview he will get poorly rasterized images. So, is there any way to set the target resolution without affecting the zoom factor? Being able to specify the default zoom % programmatically would also solve the problem - is this possible? Environment: fop 0.95b, win xp sp 2, java 1.5.0_15 -Antti- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Picture update problem
Hi! I have an issue that I think is due to FOP caching images. The situation is this: * FOP is embedded in our software. I create a single FopFactory and create a new FOP instance via it for each render. * I render a pdf with fo that references some svg image files. It comes out fine. * Some of the svg image files are updated on the hard drive. * I render a pdf again (w/ the same name, new FOP instance though, but created via the same fop factory instance). The image that has been changed on disk appears as it was before it was updated. Environment: fop 0.95b, win xp sp 2, java 1.5.0_15 It seems that the cause is this bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=8003 However, the workaround described in the bug report is not valid anymore since the way images are loaded has changed since (i.e. there is no class called FopImageFactory). So, my question really is: what class do I need to hack to get the cache disabled? Or is this issue within FOP at all anymore, i.e. is this nowadays an issue w/ the image loading framework? Is that in xmlgraphics-commons? Or is there a way to tell fop not to use image cache, e.g. via FOUserAgent instance? -::Antti::- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Picture update problem
On Fri, 06 Jun 2008 12:40:27 +0300, Andreas Delmelle [EMAIL PROTECTED] wrote: The cache can be reached via ImageManager.getCache() or, more complete, from the FOP-side: FopFactory.getImageManager().getCache().clearCache(); Thanks! This solved my problem. It is unfortunate that the whole cache is cleared, but in my case that is acceptable whereas using stale images is not. -::Antti::- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange printing problem
On Thu, 29 May 2008 12:35:51 +0300, Jeremias Maerki [EMAIL PROTECTED] wrote: In addition to Andreas' comments: This problem has come up here a number of times now (See archives). I tried googling for the problem before asking on the list, but found nothing. I guess I didn't come up w/ the right search terms. If this issue has come up repeatedly, wouldn't it be a good idea to add a mention of it to http://xmlgraphics.apache.org/fop/0.95/knownissues_overview.html#Other+known+issues ? Had it been there, I wouldn't have bothered the list w/ it. = ) The HP PCL drivers are known to cause problems with printing from AWT/Java2D. The HP *n priners (i.e. the ones with a network interface) usually all have PostScript capabilities. Please install the PostScript printer driver instead of the PCL one and there's a large chance that it'll work. Installing PS driver really did fix the problem! Thank you very much! -::Antti::- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Strange printing problem
Hi! When I print w/ fop using the print renderer, everything is fine when using a HP LaserJet 4350 dtn, but a lot of the content is lost when using HP LaserJet P3005dn. In a document containing some text and 5 svg pics, none of the text and only 3 of 5 images (every second image is lost) make it through to paper on P3005dn. The images are placed on the same locations on paper as on the version where no content is lost. I suspected this might be an issue w/ the PCL version the printers support, but they seem to support the same ones: http://h10010.www1.hp.com/wwpc/ca/en/sm/WF06b/12144670-12144918-12144920-12144920-12144986-12145000-29519501.html http://h10010.www1.hp.com/wwpc/us/en/en/WF06b/18972-18972-3328059-14638-236263-1846088-1846099-1846101.html Any ideas? Environment: java 1.5.0_15, fop 0.95 beta (from svn trunk this morning), win xp sp2 + the printers mentioned above. -::Antti::- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem using Lucida Console font
Hi! My adventures with fonts continue. Now I run into trouble trying to use Lucida Console (in pdf). What I have is this: fo:block space-before.minimum=0.8em space-before.optimum=1em space-before.maximum=1.2em space-after.minimum=0.8em space-after.optimum=1em space-after.maximum=1.2em hyphenate=false wrap-option=no-wrap white-space-collapse=false white-space-treatment=preserve linefeed-treatment=preserve text-align=start font-family='Lucida Console' id=d0e69blah blah/fo:block I also tried font-family=Lucida Console (i.e. without the single quotes) FOP says WARNING: Font 'Lucida Console,normal,400' not found. Substituting with 'any,normal,400'. This is strange since the other fonts in c:\WINDOWS\Fonts directory seem to work ok when referenced (e.g. Tahoma, Verdana). Could there be a problem because the font name has a space in it? Do I have to create a separate font metrics file? If so, why is this necessary for Lucida Console, but not e.g. for Tahoma and Verdana? My environment: win xp sp 2, java 1.5.0_15, fop 0.95beta in my fop.xconf I have renderers renderer mime=application/pdf fonts auto-detect/ /fonts -::Antti::- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem using Lucida Console font
On Wed, 07 May 2008 11:30:32 +0300, Jeremias Maerki [EMAIL PROTECTED] wrote: Worked fine for me with and without additional quotes in 0.95beta (same setup as yours except I used Sun JVM 1.5.0_14). Are you sure that your config file gets used? Turns out I had messed up my PATH and was using 0.94 when I thought I was using 0.95 beta. Everything works just fine w/ 0.95 beta. My mistake, sorry about the trouble, thanks for the help! -::Antti::- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Italic Tahoma
Hi! I tried using fo:inline element to produce italic text using Tahoma font. It did not work. Here's what I did: fo:inline font-family=Tahoma font-style=italicitalics/fo:inline FOP said: 6.5.2008 13:08:31 org.apache.fop.fonts.FontInfo notifyFontReplacement WARNING: Font 'Tahoma,italic,400' not found. Substituting with 'Tahoma,normal,400'. I dug around a bit and found out that Tahoma does not have an italic variant (see e.g. http://help.lockergnome.com/office/Tahoma-italic-ftopict705661.html). So, I tried oblique instead: fo:inline font-family=Tahoma font-style=obliqueitalics/fo:inline FOP said: 6.5.2008 12:16:54 org.apache.fop.fonts.FontInfo notifyFontReplacement WARNING: Font 'Tahoma,oblique,400' not found. Substituting with 'Tahoma,normal,400'. I consulted an XSL-FO reference (Definitive XSL-FO by G. Holman) and it said about font-style attribute: note that italic will match oblique if no italic face is available in the font family, so no surprise that the second try was no better. Changing font-family=Tahoma to font-family=Tahoma,Verdana makes FOP use Verdana's italic, which, at least to my eye looks good enough. But the question is: is there a known way to have italic(ish) Tahoma? E.g. MS Word somehow manages something that looks ok even if Tahoma Italic does not really exist. I suppose it makes it using oblique Tahoma (http://en.wikipedia.org/wiki/Oblique_type) - can FOP be made to perform the same trick? Environment: windows xp sp2, java 1.5.0_15, fop 0.95 beta. -::Antti::- Ps. Naturally in my fop.xconf I have renderers renderer mime=application/pdf fonts auto-detect/ /fonts ... to make this work. BTW, what is the reason font auto-detection is not enabled by default? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Controlling FOP printing
Hi!
When printing w/ FOP, how do I pop up a printing dialog to allow the
user to select the printer to print to? Now the print seems to go to the
default printer, no questions asked.
I found this related bug report:
http://issues.apache.org/bugzilla/show_bug.cgi?id=31674
It's 3.5 years old and nothing has happened to it for ages.
Going through FOP sources, I found this in
org.apache.fop.render.print.PrintRenderer:
89if (System.getProperty(dialog) != null) {
90if (!printerJob.printDialog()) {
It seems a little exotic to set system properties to parameterize the
printing workflow. Is this the only way?
What I (think I) need to do is:
- have the user select a printer
- query the created print job object (or whatever it is, I'm not (yet)
very familiar w/ java printing API) for the page size
- use the page size as a parameter for xsl transformation producing the
fo (docbook xsl stylesheets)
- have fop render the given fo to the given printer
Any hints, tips, sample code etc. are very welcome!
.::Antti::.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
