fopservlet classpath problem... or is it?
Most, but not all, XSL files rendered by FopServlet get me the exception below from my Tomcat 4.1.24 installation installed via RPMs. Running it at the command line works fine. I have a Tomcat 4.1.18 installation not installed via RPMs which works OK with the same XML and XSL files. On both platforms, I'm using JDK 1.4.1. I've put xalan-2.4.1.jar, xercesImpl-2.2.1.jar and xml-apis.jar into /var/tomcat4/common/endorsed. Should I be doing something else to sort out the classpath, or am I barking up the wrong tree? javax.servlet.ServletException: org.apache.fop.apps.FOPException: No flow in page-sequence at FopServlet2.renderXML(FopServlet2.java:184) at FopServlet2.doGet(FopServlet2.java:121) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown Source) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Source) at org.apache.catalina.core.StandardWrapperValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(Unknown Source) at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source) at org.apache.catalina.core.ContainerBase.invoke(Unknown Source) at org.apache.catalina.core.StandardContextValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(Unknown Source) at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source) at org.apache.catalina.core.ContainerBase.invoke(Unknown Source) at org.apache.catalina.core.StandardContext.invoke(Unknown Source) at org.apache.catalina.core.StandardHostValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(Unknown Source) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(Unknown Source) at org.apache.catalina.valves.ErrorReportValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(Unknown Source) at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source) at org.apache.catalina.core.ContainerBase.invoke(Unknown Source) at org.apache.catalina.core.StandardEngineValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok eNext(Unknown Source) at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source) at org.apache.catalina.core.ContainerBase.invoke(Unknown Source) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:562) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:619) at java.lang.Thread.run(Thread.java:536) root cause java.lang.RuntimeException: org.apache.fop.apps.FOPException: No flow in page-sequence at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3170) at org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerH andlerImpl.java:433) 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.XMLEntityManager$EntityScanner.load(Unknown Source) at org.apache.xerces.impl.XMLEntityManager$EntityScanner.skipSpaces(Unknown Source) at org.apache.xerces.impl.XMLDocumentScannerImpl$TrailingMiscDispatcher.dispatc h(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.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.TrAXFilter.parse(TrAXFilter.java:134) at org.apache.fop.apps.Driver.render(Driver.java:498) at FopServlet2.renderXML(FopServlet2.java:177) at FopServlet2.doGet(FopServlet2.java:121) at javax.servlet.http.HttpServlet.service(HttpServlet.java)
RE: fopservlet classpath problem... or is it?
Sorry to reply to my own message, but it was the RPM installation not
passing the endorsed.directories. Read on only if this is relevant to you. I
hope this helps anybody else, who might be encountering similar problems
using Fop with a Tomcat RPM installation.
This was my good start-up, which was Tomcat 4.1.18 hand-installed:
/usr/java/j2sdk1.4.1_01/bin/java -Xms32m -Xmx256m
-Djava.endorsed.dirs=/usr/java/jakarta-tomcat-4.1.18/bin:/usr/java/jakarta-t
omcat-4.1.18/common/endorsed -classpath
/usr/java/j2sdk1.4.1_01/lib/tools.jar:/usr/java/jakarta-tomcat-4.1.18/bin/bo
otstrap.jar -Dcatalina.base=/usr/java/jakarta-tomcat-4.1.18
-Dcatalina.home=/usr/java/jakarta-tomcat-4.1.18
-Djava.io.tmpdir=/usr/java/jakarta-tomcat-4.1.18/temp
org.apache.catalina.startup.Bootstrap start
And this was my bad start-up with Tomcat 4.1.24 installed using the RPM:
/usr/java/j2sdk1.4.1_02/bin/java -Djava.endorsed.dirs= -classpath
/usr/java/j2sdk1.4.1_02/lib/tools.jar:/var/tomcat4/bin/bootstrap.jar
-Dcatalina.base=/var/tomcat4 -Dcatalina.home=/var/tomcat4
-Djava.io.tmpdir=/var/tomcat4/temp org.apache.catalina.startup.Bootstrap
start
The RPM installation sets java.endorsed.dirs to nothing, which means that
the XML parser remained unendorsed.
Now that I've spotted this, I have also set -Xms32m -Xmx256m to increase the
memory for large files, and edit.
I've added into /usr/bin/dtomcat4:
8
# Endorsed directories
JAVA_ENDORSED_DIRS=${CATALINA_HOME}/common/endorsed
echo Using JAVA_ENDORSED_DIRS:${JAVA_HOME}
# Java options - we want lots of memory for Fop
JAVA_OPTS=-Xms32m -Xmx256m ${JAVA_OPTS}
8
Everything is running OK now, except for the fact that I get the error in
catalina.out similar to that reported at
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg37249.html .
Evidently, Fop's choice of XML parser doesn't agree with Tomcat. Having said
that, I have got a working configuration now.
-Original Message-
From: Rob Staveley (Tom) [mailto:[EMAIL PROTECTED]
Sent: 20 August 2003 11:34
To: [EMAIL PROTECTED]
Subject: fopservlet classpath problem... or is it?
Most, but not all, XSL files rendered by FopServlet get me the exception
below from my Tomcat 4.1.24 installation installed via RPMs. Running it at
the command line works fine. I have a Tomcat 4.1.18 installation not
installed via RPMs which works OK with the same XML and XSL files. On both
platforms, I'm using JDK 1.4.1. I've put xalan-2.4.1.jar,
xercesImpl-2.2.1.jar and xml-apis.jar into /var/tomcat4/common/endorsed.
Should I be doing something else to sort out the classpath, or am I barking
up the wrong tree?
javax.servlet.ServletException: org.apache.fop.apps.FOPException: No flow in
page-sequence
at FopServlet2.renderXML(FopServlet2.java:184)
at FopServlet2.doGet(FopServlet2.java:121)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown
Source)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown
Source)
at org.apache.catalina.core.StandardWrapperValve.invoke(Unknown
Source)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(Unknown Source)
at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source)
at org.apache.catalina.core.ContainerBase.invoke(Unknown Source)
at org.apache.catalina.core.StandardContextValve.invoke(Unknown
Source)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(Unknown Source)
at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source)
at org.apache.catalina.core.ContainerBase.invoke(Unknown Source)
at org.apache.catalina.core.StandardContext.invoke(Unknown Source)
at org.apache.catalina.core.StandardHostValve.invoke(Unknown Source)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(Unknown Source)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(Unknown
Source)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(Unknown Source)
at org.apache.catalina.valves.ErrorReportValve.invoke(Unknown
Source)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(Unknown Source)
at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source)
at org.apache.catalina.core.ContainerBase.invoke(Unknown Source)
at org.apache.catalina.core.StandardEngineValve.invoke(Unknown
Source)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(Unknown Source)
at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source)
at org.apache.catalina.core.ContainerBase.invoke(Unknown Source
RE: Line-wrap in fo:leader
Thank you for pointing out that keep-together success was spurious. That's saved me a lot of time. To set up something robust, I need to be able to calculate the lengths of the strings, using the text metrics of the font, and decide on the approach to use for leaders accordingly. That's a bit hairy-chested for XSL, and it sounds like I'm into the realm of procedural programming. Your philosophical note is very interesting. Shouldn't over-constraining be forbidden? It sound like the FO specification leaves a lot of room for interpretation. -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: 13 March 2003 20:27 To: [EMAIL PROTECTED] Subject: Re: Line-wrap in fo:leader Rob Staveley (Tom) wrote: Unfortunately the two leaders wind up on the same line, if blah is less than 50% long and the ref,ref text goes on the following line (see index.13.xsl). At the XSLT level, you can try to estimate the width of the blah and ref on one entry: string-length($stuff)*$font-size If width($blah)+$minimal-leader-length+width($ref) $allocated-width increase leader-length.optimum to $allocated-width and insert the second leader with default length set. I've tried to use keep-together with some success Spurious success, I'd bet. Keeps don't have no effect whatsoever on line breaking, unfortunately. I should know, I had already bad dreams featuring the current line breaking code. In fact, the keep properties are not even delivered anywhere near the line breaking code. Is this a Fop issue or am I expecting to achieve something from FO which is beyond its design? Tricky question: it should be possible to get it to work with keep-with-next.within-line, for example: fo:block text-align=justify text-align-last=justify fo:inline keep-with-next.within-line=alwaysblah/fo:inlinefo:leader leader-pattern=dots leader-length.minimum=6pt leader-length.optimum=100% keep-with-next.within-line=5/fo:leader leader-pattern=dots leader-length.optimum=100% keep-with-next.within-line=always/ref/fo:block This is overconstrained: The processor is advised to both keep everything within a line but expand the leaders to the full line width. OTOH the leader length can be decreased to 6pt for the first and to 0 for the secons leader, therefore if blah+(6pt leader)+ref fits on the line, nothing special happens, but if not the processor can insert a break somewhere, preferably beween the leaders, which then expand each by itself to fill all available space. However this isn't all that well defined in the spec, some processors could do something else, like simply overflowing the line. J.Pietschmann - 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: Line-wrap in fo:leader
Many thanks for the suggestion. Your help is greatly appreciated again. Unfortunately the two leaders wind up on the same line, if blah is less than 50% long and the ref,ref text goes on the following line (see index.13.xsl). I've tried to use keep-together with some success (see index.14.xsl) and this improves matters, but you can see that it appears to be ignored on the 4th page of the output, when the refs are too long, and the leader is separated from the refs. Is this a Fop issue or am I expecting to achieve something from FO which is beyond its design? Links: http://coolbox.seseit.com/~rob/fo.index.13.html http://coolbox.seseit.com/~rob/fo.index.14.html -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: 12 March 2003 20:38 To: [EMAIL PROTECTED] Subject: Re: Line-wrap in fo:leader Rob Staveley (Tom) wrote: blah, blah, blah, blah, blah,... ref,ref,ref Add text-align=justify. I'd like to get: blahref,ref blahref,ref,ref blah, blah, blah, blah, blah,... .ref,ref,ref Getting a second leader on the second line is definitely tricky. You could try to add a second leader: fo:blockblah, blah, blah, blah, blah,fo:leader leader-pattern=dots/fo:leader leader-pattern=dots leader-length.optimum=50% leader-length.minimum=0/ref,ref,ref/fo:block This will (hopefully) break if the line is half full with blah text. J.Pietschmann - 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]
Line-wrap in fo:leader
How can I handle line-wrap in fo:leader? I'd like to get: blahref,ref blahref,ref,ref blah, blah, blah, blah, blah,... .ref,ref,ref However, the justification gets lost when it line wraps for me, and I get: blahref,ref blahref,ref,ref blah, blah, blah, blah, blah,... ref,ref,ref This looks ragged. Here's a link to my stuff, which uses Fop 0.20.5rc2: http://coolbox.seseit.com/~rob/mims_index_218.xml.index.6.xsl.fo.fop-0.2 0.5rc2.rtf.html Any help would be greatly appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: fo:leader weird output (again) ;o)
I do apologise. I've unfirewalled port 8080. I hadn't realised that it was set up like that. -Original Message- From: laurent marot [mailto:[EMAIL PROTECTED] Sent: 09 March 2003 17:43 To: [EMAIL PROTECTED] Subject: Re: fo:leader weird output (again) ;o) sorry but url doesn't work when i click submit button - Original Message - From: Rob Staveley (Tom) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, March 09, 2003 6:34 PM Subject: RE: fo:leader weird output (again) ;o) Thank you so much! I followed your recommendations and http://coolbox.seseit.com/~rob/fop.0.20.5rc2.using-index.3.html looks good to me with 0.20.5rc2 -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: 09 March 2003 11:29 To: [EMAIL PROTECTED] Subject: Re: fo:leader weird output (again) ;o) Rob Staveley (Tom) wrote: In the same vein... I'm trying to put together a catalogue index, which is dependent on fo:leader. I'm also getting a ragged right-hand margin from 0.20.5rc2 (see to GET from http://coolbox.seseit.com/~rob/fop.0.20.5rc2.html), but when I used the last of yesterday's snapshot from the CVS repository (xml-fop_20030309052748.tar.gz) the output looks worse rather than better (sorry I've not got a link for this). The problem is, the lines are correctly aligned during layout, in the PDF renderer the (912) strings have exactly the same x-position and area width. I can only guess something weird happens with the space calculation between the leader and the word on the line end. Also , the space at the block end is occasionally a problem. As a workaround: - Use leader-alignment=reference-area. This guarantees the leaders end at the same x-position if the followig word has the same length as on the line before. It also looks better. - Write your XSLT so that no extra space occurs at the end of the line, i.e. ...080)/fo:inline/fo:block instead of ...080)/fo:inline /fo:block This looks already much better. J.Pietschmann - 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] - 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: fo:leader weird output (again) ;o)
In the same vein... I'm trying to put together a catalogue index, which is dependent on fo:leader. I'm also getting a ragged right-hand margin from 0.20.5rc2 (see to GET from http://coolbox.seseit.com/~rob/fop.0.20.5rc2.html), but when I used the last of yesterday's snapshot from the CVS repository (xml-fop_20030309052748.tar.gz) the output looks worse rather than better (sorry I've not got a link for this). I therefore wonder if I'm doing something stupid. My link has got my XML source and XSL... I was wondering if some kind soul could eye-ball the XSL to see if there is something I can do to improve matters, or if I should hang back and wait for fo:leader to be sorted out by the maestros? -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: 04 March 2003 22:02 To: [EMAIL PROTECTED] Subject: Re: fo:leader weird output (again) ;o) Clay Leeds wrote: When you say this bug is fixed in CVS do you mean that it's fixed in the maintenance branch (i.e., the soon-to-be-released 0.20.5/0.20.5rc3 version) Yes. There is a CHANGES and an archive for the commit messages at http://marc.theaimsgroup.com/?l=fop-cvs J.Pietschmann - 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: fo:leader weird output (again) ;o)
Thank you so much! I followed your recommendations and http://coolbox.seseit.com/~rob/fop.0.20.5rc2.using-index.3.html looks good to me with 0.20.5rc2 -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: 09 March 2003 11:29 To: [EMAIL PROTECTED] Subject: Re: fo:leader weird output (again) ;o) Rob Staveley (Tom) wrote: In the same vein... I'm trying to put together a catalogue index, which is dependent on fo:leader. I'm also getting a ragged right-hand margin from 0.20.5rc2 (see to GET from http://coolbox.seseit.com/~rob/fop.0.20.5rc2.html), but when I used the last of yesterday's snapshot from the CVS repository (xml-fop_20030309052748.tar.gz) the output looks worse rather than better (sorry I've not got a link for this). The problem is, the lines are correctly aligned during layout, in the PDF renderer the (912) strings have exactly the same x-position and area width. I can only guess something weird happens with the space calculation between the leader and the word on the line end. Also , the space at the block end is occasionally a problem. As a workaround: - Use leader-alignment=reference-area. This guarantees the leaders end at the same x-position if the followig word has the same length as on the line before. It also looks better. - Write your XSLT so that no extra space occurs at the end of the line, i.e. ...080)/fo:inline/fo:block instead of ...080)/fo:inline /fo:block This looks already much better. J.Pietschmann - 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: Fop Logo concept
I agree with your sentiments, though it is indeed a nice design. I'm no artist, but what about a play on the word fop/foppish (as in a dandy)? There are nice images of fops at http://www.theonion.com/onion3011/foppish.html and http://www.nadablog.com/blog/98.html which could be inspiration. -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: 04 February 2003 00:46 To: [EMAIL PROTECTED] Subject: Re: Fop Logo concept Mitchell, Lincoln L. wrote: How about this... Great design, but please, no insects anymore. If there is an animal in the logo, it should be something cute, preferably furry or at least feathered. J.Pietschmann - 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]
Using FopServlet with ISO-8859-1
I've got an XML document encoded with ISO-8859-1 for which I have an XSL-FO which also outputs ISO-8859-1. This works nicely using the command line Fop. However, using the same XML and XSL with FopServlet I find that accented characters get clobbered in the retrieved PDF. It happens with Mozilla and IE. Any ideas? PS: I've tried using UTF-8 as the output encoding in the XSL and get the same problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using FopServlet with ISO-8859-1
It was indeed the default charset. I've fixed it by explicitly setting the charset in the InputStreamReader used by the file fetcher. BufferedReader in = new BufferedReader(new InputStreamReader(url.openStream(),ISO-8859-1)); Again, apologies for going off topic, but I hope this might be of some help to somebody else doing similar things. -Original Message- From: Fabrizio Tringali [mailto:[EMAIL PROTECTED] Sent: 03 February 2003 18:08 To: [EMAIL PROTECTED] Subject: Re: Using FopServlet with ISO-8859-1 I've got the same problem on solaris 7/8 and it was not the browser but the web server. I solve it setting some locale on OS, something like: LC_COLLATE=it_IT.ISO8859-1 LC_CTYPE=it_IT.ISO8859-1 LC_MESSAGES=it LC_MOLC_COLLATE=it.ISO8859-15 LC_NUMERIC=it_IT.ISO8859-1 LC_TIME=it_IT.ISO8859-1 hi - Original Message - From: Rob Staveley (Tom) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 03, 2003 6:34 PM Subject: Using FopServlet with ISO-8859-1 I've got an XML document encoded with ISO-8859-1 for which I have an XSL-FO which also outputs ISO-8859-1. This works nicely using the command line Fop. However, using the same XML and XSL with FopServlet I find that accented characters get clobbered in the retrieved PDF. It happens with Mozilla and IE. Any ideas? PS: I've tried using UTF-8 as the output encoding in the XSL and get the same problem. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
