Re: XMLFilterImpl producing SVG instream-foreign-object
Andreas, Thanks for confirming! Yes indeed i found out i had to bypass the startDocument method - still smells a bit, but then again fish is tasty What i am making is a possibility to include PlantUML ( http://plantuml.sourceforge.net/) UML diagrams in the FOP rendering uml-diagram format=svg ... @startuml Alice - Bob: Authentication Request Bob -- Alice: Authentication Response Alice - Bob: Another authentication Request Alice -- Bob: another authentication Response @enduml /uml-diagram I get the basic UML diagram, just need to work a bit on the size (hopefully next weekend ). What would be a way to make it a more structural solution (like barcode etc) so perhaps other people can use it as well? tx., On Tue, Mar 16, 2010 at 7:44 PM, Andreas Delmelle andreas.delme...@telenet.be wrote: On 15 Mar 2010, at 07:35, Raphael Parree wrote: Hi Raphael I have meanwhiel found a way of making it work - i am sure there must be a better way; what i'm doing below smells pretty bad... I SAX parse the SVG and propagate its SAX events to the XmlFilter's parent content handler: The key reason, I think, the chosen approach is working (where your original cited approach wasn't), is simply because it does not propagate the startDocument() and endDocument() events to the parent. (Interesting to note that FOP needs to do the exact opposite at parse-time: the embedded SVG comes in as just another startElement(), and the child events are then routed to a delegate ContentHandler, precisely because raising startDocument() more than once on the same ContentHandler would lead to an exception.) Maybe it would be slightly better to define an explicit DefaultHandler subclass, as opposed to using anonymous overrides, but the net effect would be the same. IMO, it would look nicer, and would definitely be preferable over your current solution if you need the same approach in multiple places, but the bottom line is that your solution is correct. It smells a bit fishy maybe, but using an intermediate DefaultHandler that swallows startDocument() and endDocument() definitely seems like the most straightforward way to tackle this issue. HTH! Regards, Andreas Delmelle --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org -- Raphael Parree CTO SOA Evangelist phone +33 673 75 34 62 Disclaimer... The information contained in this message may be confidential and is intended to be exclusively for the addressee. Sender's written permission is needed prior to forwarding or otherwise using the content of the message, whether completely or partially. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. Please rely on your own virus checking, no responsibility is taken by the sender for any damage rising out of any bug or virus infection.
Re: XMLFilterImpl producing SVG instream-foreign-object
I am still struggling with this one...anybody might have a answer or direction? On Tue, Feb 9, 2010 at 10:40 AM, Raphael Parree rpar...@gmail.com wrote: Hi, I wrote an XMLFilterImpl which produces a instream-foreign-object. In another filter i was able to call the super methods to push the result in the FO tree: In this case i can not use that because the XML of the SVG needs to be parsed String svgText = umlDiagramProducer.produceSVGText(s); super.startElement(FONS, instream-foreign-object, fo:instream-foreign-object, attributes); //what am i going to put here??? super.endElement(FONS, instream-foreign-object, fo:instream-foreign-object); I tried super.parse(new InputSource(new StringReader(svgText))); and a new SAXParser passing the parent contenthandler, but all results in exceptions. Thanks! -- Raphael Parree -- Raphael Parree CTO SOA Evangelist phone +33 673 75 34 62 Disclaimer... The information contained in this message may be confidential and is intended to be exclusively for the addressee. Sender's written permission is needed prior to forwarding or otherwise using the content of the message, whether completely or partially. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. Please rely on your own virus checking, no responsibility is taken by the sender for any damage rising out of any bug or virus infection.
XMLFilterImpl producing SVG instream-foreign-object
Hi, I wrote an XMLFilterImpl which produces a instream-foreign-object. In another filter i was able to call the super methods to push the result in the FO tree: In this case i can use that because the SVG needs to be parsed String svgText = umlDiagramProducer.produceSVGText(s); super.startElement(FONS, instream-foreign-object, fo:instream-foreign-object, attributes); //what am i going to put here??? super.endElement(FONS, instream-foreign-object, fo:instream-foreign-object); I tried super.parse(new InputSource(new StringReader(svgText))); and a new SAXParser passing the parent contenthandler, but all results in exceptions. Thanks! -- Raphael Parree
Handsout
Hi, Perhaps someone can send me in the right direction with the following. We use XSL-FO to create slideshows. I would now like to also create slide handouts. I would like to levearge the existing XSL-FO that creates the presentation slides. The easiest would be if i can somehow shrink the pages and place 1,2 or 3 shrunken pages on one page. Is that somehow possible. Is there perhaps another way of achieving the same? tx., -- Raphael
Break PDF into 2
Hi, Is there a way using FOP to break a PDF into two after x number of pages...using XSL 2.0? getting the page number? The problem is that we need to break a book after 600 pages into two books with the book number on the front cover. The other problem is that we would need to before hand how many pages there will be when processing the front cover. I guess it is not possible...Anybody has experience with this? tx., -- Raphael
Re: Break PDF into 2
Georg, Thanks for this i will experiment with your suggestion...looks like a way forward. Tx(!) Raphael On Fri, Nov 21, 2008 at 11:08 AM, Georg Datterl [EMAIL PROTECTED]wrote: Hi Raphael, Is there a way using FOP to break a PDF into two after x number of pages...using XSL 2.0? getting the page number? The problem is that we need to break a book after 600 pages into two books with the book number on the front cover. The other problem is that we would need to before hand how many pages there will be when processing the front cover. I guess it is not possible...Anybody has experience with this? Do you really want to break after exactly 600 pages, no matter if you are for example in the middle of a text block or so? If yes, I'd guess it would be possible to define a page-master-sequence consisting of the front page, 599 times the data page (with a data region), the second front page containing only static content (no data region) and 599 times the data page again. Then a flow into the data region should fill 599 pages, the generate the second front page without filling in data from the flow, the go on filling data pages. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH:www.irs-nbg.de Willmy PrintMedia GmbH:www.willmy.de Willmy Consult Content GmbH: www.willmycc.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Raphael Parree CTO SOA Evangelist phone +33 683 468663 Disclaimer... The information contained in this message may be confidential and is intended to be exclusively for the addressee. Sender's written permission is needed prior to forwarding or otherwise using the content of the message, whether completely or partially. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. Please rely on your own virus checking, no responsibility is taken by the sender for any damage rising out of any bug or virus infection.
Re: Break PDF into 2
Sean , Thanks i will look into that as well, as it might allow me to make a cleaner cut... tx., On Fri, Nov 21, 2008 at 10:14 PM, Griffin,Sean [EMAIL PROTECTED] wrote: Another option may be to use iText to split the entire PDF into multiple PDFs and then insert your own page at the split. I don't know if it's possible or not, but iText can do some pretty powerful things. Sean Griffin *From:* Raphael Parree [mailto:[EMAIL PROTECTED] *Sent:* Friday, November 21, 2008 4:57 AM *To:* fop-users@xmlgraphics.apache.org *Subject:* Re: Break PDF into 2 Georg, Thanks for this i will experiment with your suggestion...looks like a way forward. Tx(!) Raphael On Fri, Nov 21, 2008 at 11:08 AM, Georg Datterl [EMAIL PROTECTED] wrote: Hi Raphael, Is there a way using FOP to break a PDF into two after x number of pages...using XSL 2.0? getting the page number? The problem is that we need to break a book after 600 pages into two books with the book number on the front cover. The other problem is that we would need to before hand how many pages there will be when processing the front cover. I guess it is not possible...Anybody has experience with this? Do you really want to break after exactly 600 pages, no matter if you are for example in the middle of a text block or so? If yes, I'd guess it would be possible to define a page-master-sequence consisting of the front page, 599 times the data page (with a data region), the second front page containing only static content (no data region) and 599 times the data page again. Then a flow into the data region should fill 599 pages, the generate the second front page without filling in data from the flow, the go on filling data pages. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH:www.irs-nbg.de Willmy PrintMedia GmbH:www.willmy.de Willmy Consult Content GmbH: www.willmycc.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Raphael Parree CTO SOA Evangelist phone +33 683 468663 Disclaimer... The information contained in this message may be confidential and is intended to be exclusively for the addressee. Sender's written permission is needed prior to forwarding or otherwise using the content of the message, whether completely or partially. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. Please rely on your own virus checking, no responsibility is taken by the sender for any damage rising out of any bug or virus infection. -- CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024. -- Raphael Parree CTO SOA Evangelist phone +33 683 468663 Disclaimer... The information contained in this message may be confidential and is intended to be exclusively for the addressee. Sender's written permission is needed prior to forwarding or otherwise using the content of the message, whether completely or partially. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. Please rely on your own virus checking, no responsibility is taken by the sender for any damage rising out of any bug or virus infection.
Re: Auto dectect font and embedding
Vincent, Thanks for clearing that up. All true type fonts are embedded, only the Type 1 fonts Helvetica and Courier are not embedded. I will try substituting these with Arial and Courier new resp. tx! On Tue, Sep 9, 2008 at 11:24 AM, Vincent Hennebert [EMAIL PROTECTED]wrote: Hi Raphael, Raphael Parree wrote: Hi, On the fop web site i found the following ( http://xmlgraphics.apache.org/fop/trunk/fonts.html#autodetect) By default, all fonts are embedded if an output format supports font embedding (I am using auto detect font).. Later on that same page: When FOP embeds a font, it adds a prefix to the fontname... When i look at the Fonts tab in Adobe Acrobat (Document Properties) I don't see these prefixes. Does that mean my fonts are not embedded. No: usually PDF viewers will skip the prefix when displaying the names of embedded fonts. You should see 'embedded subset' in the properties dialog box next to the font name. If the font is not embedded you will see an 'Actual Font:' below the name of the font. (I am using today's most recent version from the trunk) If they are not embedded, how can i embed them? tx., Raphael HTH, Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Raphael Parree CTO SOA Evangelist Trivera Technologies Global J2EE Education, Mentoring, Courseware Consulting Services phone:+31 152600 448 phone +33 683 468663 Disclaimer... The information contained in this message may be confidential and is intended to be exclusively for the addressee. Sender's written permission is needed prior to forwarding or otherwise using the content of the message, whether completely or partially. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. Please rely on your own virus checking, no responsibility is taken by the sender for any damage rising out of any bug or virus infection.
Auto dectect font and embedding
Hi, On the fop web site i found the following ( http://xmlgraphics.apache.org/fop/trunk/fonts.html#autodetect) By default, all fonts are embedded if an output format supports font embedding (I am using auto detect font).. Later on that same page: When FOP embeds a font, it adds a prefix to the fontname... When i look at the Fonts tab in Adobe Acrobat (Document Properties) I don't see these prefixes. Does that mean my fonts are not embedded. (I am using today's most recent version from the trunk) If they are not embedded, how can i embed them? tx., Raphael
RE: FOP Trunk build failed
Hi, I had the same problem a few days back please check: http://www.nabble.com/IOException-during-build-td16725132.html I also tried JJDK1.5 Update 15 and it has the same problem. Using another Transformer implementation does the trick for me: set ANT_OPTS=-Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor .TransformerFactoryImpl (adding lib\xalan-2.7.0.jar;lib\serializer-2.7.0.jar to the classpath when running Ant.) Raphael -Original Message- From: Pascal Sancho [mailto:[EMAIL PROTECTED] Sent: 22 April 2008 17:31 To: fop-users@xmlgraphics.apache.org Subject: FOP Trunk build failed Hi, I cannot build FOP TRUNK since the merge of new processing feedback. Rev 645104 is OK for me. Rev 647770 (until HEAD) is broken for me Ant gives me the following message: BUILD FAILED D:\java\fop_trunk\build.xml:430: java.io.IOException: Failed to delete D:\java\fop_trunk\src\java\org\apache\fop\events\ EventFormatter.xml while trying to rename C:\DOCUME~1\sanchop\LOCALS~1\Temp\fixcrlf1374453230 My system: WinXP SP2 + Sun JDK 1.6.0_03 Locale: french Any Idea? Pascal - 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]
Bug in PrintRendererConfigurator addFontInfoListFromFileList (with patch)
Hi, In the PrintRendererConfigurator. addFontInfoListFromFileList is a bug. When no EmbedFontInfo is found the method returns neglecting the other found fonts in the fontFileList. This way I had no support for Verdana and some other fonts. When no embedFontInfos is found, the loop should continue as apposed to returning from the method. The attached patch changes the return into a continue Cheers, Raphael font patch.patch Description: Binary data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IOException during build
Hi, I am getting an IOException while building the latest trunk version. It occurs on the first fixcrlf (line 430) for the EventFormatter.xml. The EventFormatter.xml is writable; I can delete it manually, so there should be no IOException. Is the build process somehow locking it? Anu clues?
RE: IOException during build
Jeremias, I guess it has to do with the TransformerImpl implementation in the JVM. In JDK jdk1.5.0_11 (Sun) (the one I was using) the internal _osstream is not closed; in java 6 it is closed (hence it works with Java 6) (see line 726 in the JDK 1.6 b4) com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl). The transform is used in the EventProducerCollectorTask, it leaves the stream open and the next ant task tries to delete the file and fails. So it works with Java 6 update 4 not with JDK 1.5 b11 (both from SUN). -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 16 April 2008 18:05 To: fop-users@xmlgraphics.apache.org Subject: Re: IOException during build Works for me. Does this IOException have an error message associated with it? An IOException can be anything. On 16.04.2008 16:24:37 Raphael Parree wrote: Hi, I am getting an IOException while building the latest trunk version. It occurs on the first fixcrlf (line 430) for the EventFormatter.xml. The EventFormatter.xml is writable; I can delete it manually, so there should be no IOException. Is the build process somehow locking it? Anu clues? Jeremias Maerki - 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: IOException during build
Jeremias, I also tried JJDK1.5 Update 15 and it has the same problem. Using another Transformer implementation does the trick for me: set ANT_OPTS=-Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor .TransformerFactoryImpl (adding lib\xalan-2.7.0.jar;lib\serializer-2.7.0.jar to the classpath when running Ant.) -Original Message- From: Raphael Parree [mailto:[EMAIL PROTECTED] Sent: 16 April 2008 18:19 To: 'fop-users@xmlgraphics.apache.org' Subject: RE: IOException during build Jeremias, I guess it has to do with the TransformerImpl implementation in the JVM. In JDK jdk1.5.0_11 (Sun) (the one I was using) the internal _osstream is not closed; in java 6 it is closed (hence it works with Java 6) (see line 726 in the JDK 1.6 b4) com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl). The transform is used in the EventProducerCollectorTask, it leaves the stream open and the next ant task tries to delete the file and fails. So it works with Java 6 update 4 not with JDK 1.5 b11 (both from SUN). -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 16 April 2008 18:05 To: fop-users@xmlgraphics.apache.org Subject: Re: IOException during build Works for me. Does this IOException have an error message associated with it? An IOException can be anything. On 16.04.2008 16:24:37 Raphael Parree wrote: Hi, I am getting an IOException while building the latest trunk version. It occurs on the first fixcrlf (line 430) for the EventFormatter.xml. The EventFormatter.xml is writable; I can delete it manually, so there should be no IOException. Is the build process somehow locking it? Anu clues? Jeremias Maerki - 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: linefeed-treatment in cell problem
Andreas, Thanks for your reply.. Indeed putting keep-together.within-page=always on the fo:block for which I want to preserve the linefeed does the trick. Does not seem logical however...this behavior has been introduced in recent updates to the trunk (somewhere between jan 20 and yesterday morning). Attached is an FO: -First example block linefeed is preserved (outside table) -Second block, linefeed is not preserved (inside table) -third block, linefeed is preserved (inside table and using the suggestion from Andreas, adding the keep-together.within-page=always) Is this the correct behavior? Tx., Raphael -Original Message- From: Andreas Delmelle [mailto:[EMAIL PROTECTED] Sent: 25 January 2008 18:50 To: fop-users@xmlgraphics.apache.org Subject: Re: linefeed-treatment in cell problem On Jan 25, 2008, at 16:38, Raphael Parree wrote: Hi With the current version from the trunk the linefeed-treatment preserve on a block in a table cell does not seem to work. The enclosed fo file illustrates this. There was a recent post about this, IIRC... Try substituting 'keep-together=always' with 'keep-together.within- page=always'. The explanation keep-together=always is semantically equivalent to keep-together.within-page=always, keep-together.within- column=always *and* keep-together.within-line=always I'm not sure whether it is compliant behavior that a keep.within-line overrules preserved linefeeds, but that is what happens right now. HTH! Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] linefeed-treatment.fo Description: Binary data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: linefeed-treatment in cell problem
Hi Vincent, Thanks for the response. In fact the linefeed was preserved until the update I made yesterday and it worked that way for many years now..,the last version for which I know for sure the linefeed was preserved was January 20. Ok I understand it is expected behavior. Thanks, Have a great weekend all, Raphael -Original Message- From: Vincent Hennebert [mailto:[EMAIL PROTECTED] Sent: 26 January 2008 14:46 To: fop-users@xmlgraphics.apache.org Subject: Re: linefeed-treatment in cell problem Hi Raphael, Apart from Andreas question about whether keep-with-next.within-line should override linefeed-treatment or not (Id say no), the behaviour looks correct to me. If you put a keep-together=always on the first block you will get the same result as for the second one. I dont see what could have affected that in the commits from the 20th of January. However, I did commit a fix on the 9th, changing the inheritability of the keep-together property to true, as required by the XSL-FO spec. Thats probably what started to trigger such a behaviour. HTH, Vincent Raphael Parree a écrit : Andreas, Thanks for your reply.. Indeed putting keep-together.within-page=always on the fo:block for which I want to preserve the linefeed does the trick. Does not seem logical however...this behavior has been introduced in recent updates to the trunk (somewhere between jan 20 and yesterday morning). Attached is an FO: -First example block linefeed is preserved (outside table) -Second block, linefeed is not preserved (inside table) -third block, linefeed is preserved (inside table and using the suggestion from Andreas, adding the keep-together.within-page=always) Is this the correct behavior? Tx., Raphael -Original Message- From: Andreas Delmelle [mailto:[EMAIL PROTECTED] Sent: 25 January 2008 18:50 To: fop-users@xmlgraphics.apache.org Subject: Re: linefeed-treatment in cell problem On Jan 25, 2008, at 16:38, Raphael Parree wrote: Hi With the current version from the trunk the linefeed-treatment preserve on a block in a table cell does not seem to work. The enclosed fo file illustrates this. There was a recent post about this, IIRC... Try substituting 'keep-together=always' with 'keep-together.within- page=always'. The explanation keep-together=always is semantically equivalent to keep-together.within-page=always, keep-together.within- column=always *and* keep-together.within-line=always I'm not sure whether it is compliant behavior that a keep.within-line overrules preserved linefeeds, but that is what happens right now. HTH! Cheers Andreas -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting - 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: SVG XML Access
Jeremias,
Thanks for the quick reply and commit ;)
I am getting the following Exception: java.lang.IllegalArgumentException:
Source not supported: javax.xml.transform.dom.DOMSource.
I have attached my code in the code.txt file. The whole stacktrace is in the
stacktrace.txt file.
I updated my FOP working copy to 615144.
Tx.,
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: 25 January 2008 09:31
To: fop-users@xmlgraphics.apache.org
Subject: Re: SVG XML Access
Raphael,
I hadn't implemented support for a DOMSource but have done so now:
http://svn.apache.org/viewvc?rev=615144view=rev
Take a look at the test case that I've added. It demonstrates how you
can write a URIResolver that returns an SVG DOM. That way you can do all
the SVG manipulation you want. But you have to make sure the DOM
Document is a org.w3c.dom.svg.SVGDocument.
On 25.01.2008 08:03:38 Raphael Parree wrote:
Hi Jeremias,
End o last year I wrote a custom URI resolver to augment SVG files with a
style entry. This has drastically influenced the PDF generation time. I
recall that during that time you mentioned you were updating the Image
part
and that it would be easier when that was completed, because the update
gives access to the SVG XML. I noticed many updates in the Image classes
(in
the trunk).
Does this mean that there is an alternative to filtering the SVG files
now?
Tx.,
Raphael
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
public class SVGFilterURIResolver implements URIResolver {
public Source resolve(String href, String base) throws TransformerException {
if (href.endsWith(.svg)) {
String parser = XMLResourceDescriptor.getXMLParserClassName();
SAXSVGDocumentFactory f = new SAXSVGDocumentFactory(parser);
try {
Document document = f.createDocument(href);
NodeList styleNodeList =
document.getElementsByTagNameNS(http://www.w3.org/2000/svg;, style);
if (styleNodeList.getLength() 0) {
Element e = (Element) styleNodeList.item(1);
e.insertBefore(document.createTextNode(marker { overflow:visible;
}), e.getFirstChild());
}
DOMSource src = new DOMSource(document);
return src;
} catch (IOException e) {
throw new TransformerException(IOException while loading SVG, e);
}
} else
return null;
}
}
java.lang.IllegalArgumentException: Source not supported:
javax.xml.transform.dom.DOMSource
at
org.apache.xmlgraphics.image.loader.util.ImageUtil.closeQuietly(ImageUtil.java:195)
at
org.apache.xmlgraphics.image.loader.ImageManager.getImage(ImageManager.java:252)
at org.apache.fop.render.pdf.PDFRenderer.putImage(PDFRenderer.java:1717)
at
org.apache.fop.render.pdf.PDFRenderer.renderImage(PDFRenderer.java:1663)
at
org.apache.fop.render.AbstractRenderer.renderViewport(AbstractRenderer.java:748)
at
org.apache.fop.render.AbstractPathOrientedRenderer.renderViewport(AbstractPathOrientedRenderer.java:556)
at
org.apache.fop.render.AbstractRenderer.renderInlineArea(AbstractRenderer.java:631)
at
org.apache.fop.render.pdf.PDFRenderer.renderInlineArea(PDFRenderer.java:1329)
at
org.apache.fop.render.AbstractRenderer.renderLineArea(AbstractRenderer.java:606)
at
org.apache.fop.render.pdf.PDFRenderer.renderLineArea(PDFRenderer.java:1320)
at
org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:532)
at
org.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:582)
at
org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1313)
at
org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:522)
at
org.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:582)
at
org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1313)
at
org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:522)
at
org.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:568)
at
org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1313)
at
org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:522)
at
org.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:582)
at
org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1313)
at
org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:522)
at
org.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:582)
at
org.apache.fop.render.pdf.PDFRenderer.renderBlock(PDFRenderer.java:1313)
at
org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:522
RE: SVG XML Access
Vincent, The rev of my local copy is the latest: 615171. When looking at http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/java/org/apache/fo p/layoutmgr/table/RowPainter.java I still see the computeSpanHeight, does that make sense? I will try to make a simple FO (due to copyright issues I cannot send the FO file I am using, sorry...) Attached is the stacktrace. I will submit a bug after I created an FO file that resolves to the same error. Tx., Raphael -Original Message- From: Vincent Hennebert [mailto:[EMAIL PROTECTED] Sent: 25 January 2008 11:52 To: fop-users@xmlgraphics.apache.org Subject: Re: SVG XML Access Hi, Jeremias Maerki wrote: Please post the stacktrace and possibly an FO so Vincent can fix the table layout code. He's currently working on it and I'm sure he'll appreciate the feedback. Indeed, although the computeSpanHeight method no longer exists in the Trunk. Raphael, would you mind upgrading your copy to the latest version and test again? Please report any problem on Bugzilla [1], attaching the FO sample triggering the error. Thanks, Vincent [1] http://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop On 25.01.2008 11:30:17 Raphael Parree wrote: Jeremias, Thanks I have updated, but can't tell if it works yet. I am getting anoher problem (that does mean the source not supported was not thrown). But probably other changes in the trunk are giving me a problem. I will look into recent posts if this problem is known (something about an index out of bounds in the computeSpanHeight of the RowPainter). Will let you know if it works... snip/ Jeremias Maerki -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] java.lang.IndexOutOfBoundsException: Index: -1, Size: 5 at java.util.LinkedList.entry(LinkedList.java:368) at java.util.LinkedList.get(LinkedList.java:313) at org.apache.fop.layoutmgr.table.RowPainter.computeContentLength(RowPainter.java:246) at org.apache.fop.layoutmgr.table.RowPainter.addAreasForCell(RowPainter.java:290) at org.apache.fop.layoutmgr.table.RowPainter.addAreasAndFlushRow(RowPainter.java:198) at org.apache.fop.layoutmgr.table.TableContentLayoutManager.iterateAndPaintPositions(TableContentLayoutManager.java:427) at org.apache.fop.layoutmgr.table.TableContentLayoutManager.addAreas(TableContentLayoutManager.java:364) at org.apache.fop.layoutmgr.table.TableLayoutManager.addAreas(TableLayoutManager.java:334) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManager.java:394) at org.apache.fop.layoutmgr.BlockLayoutManager.addAreas(BlockLayoutManager.java:394) at org.apache.fop.layoutmgr.AreaAdditionUtil.addAreas(AreaAdditionUtil.java:121) at org.apache.fop.layoutmgr.FlowLayoutManager.addAreas(FlowLayoutManager.java:305) at org.apache.fop.layoutmgr.PageBreaker.addAreas(PageBreaker.java:241) at org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.java:507) at org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.java:370) at org.apache.fop.layoutmgr.PageBreaker.doPhase3(PageBreaker.java:262) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:345) at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:263) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:100) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:234) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:123) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:374) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:196) at org.xml.sax.helpers.XMLFilterImpl.endElement(XMLFilterImpl.java:546) at eu.trivera.cw.producer.content.producers.documents.extensions.codehighlighting.CodeBlockXMLFilter.endElement(CodeBlockXMLFilter.java:85) at net.sf.saxon.event.ContentHandlerProxy.endElement(ContentHandlerProxy.java:391) at net.sf.saxon.event.ProxyReceiver.endElement(ProxyReceiver.java:174) at net.sf.saxon.event.NamespaceReducer.endElement(NamespaceReducer.java:213) at net.sf.saxon.event.ComplexContentOutputter.endElement(ComplexContentOutputter.java:417) at net.sf.saxon.instruct.ElementCreator.processLeavingTail(ElementCreator.java:301) at net.sf.saxon.instruct.Instruction.process(Instruction.java:94) at net.sf.saxon.instruct.ForEach.processLeavingTail(ForEach.java:300
RE: SVG XML Access
Jeremias, Thanks I have updated, but can't tell if it works yet. I am getting anoher problem (that does mean the source not supported was not thrown). But probably other changes in the trunk are giving me a problem. I will look into recent posts if this problem is known (something about an index out of bounds in the computeSpanHeight of the RowPainter). Will let you know if it works... -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 25 January 2008 11:02 To: fop-users@xmlgraphics.apache.org Subject: Re: SVG XML Access Sorry, I've only tested the isolated case of preloading the image so I missed the other call to closeQuietly(). I've now fixed this in the right place. Please try again. I hope it works now. http://svn.apache.org/viewvc?rev=615164view=rev On 25.01.2008 10:36:24 Raphael Parree wrote: Jeremias, Thanks for the quick reply and commit ;) I am getting the following Exception: java.lang.IllegalArgumentException: Source not supported: javax.xml.transform.dom.DOMSource. I have attached my code in the code.txt file. The whole stacktrace is in the stacktrace.txt file. I updated my FOP working copy to 615144. Tx., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 25 January 2008 09:31 To: fop-users@xmlgraphics.apache.org Subject: Re: SVG XML Access Raphael, I hadn't implemented support for a DOMSource but have done so now: http://svn.apache.org/viewvc?rev=615144view=rev Take a look at the test case that I've added. It demonstrates how you can write a URIResolver that returns an SVG DOM. That way you can do all the SVG manipulation you want. But you have to make sure the DOM Document is a org.w3c.dom.svg.SVGDocument. On 25.01.2008 08:03:38 Raphael Parree wrote: Hi Jeremias, End o last year I wrote a custom URI resolver to augment SVG files with a style entry. This has drastically influenced the PDF generation time. I recall that during that time you mentioned you were updating the Image part and that it would be easier when that was completed, because the update gives access to the SVG XML. I noticed many updates in the Image classes (in the trunk). Does this mean that there is an alternative to filtering the SVG files now? Tx., Raphael Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jeremias Maerki - 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: SVG XML Access
Jeremias, I was able to test the SVN filter, and that one works! This is a much faster way to filter the SVN (I filtering to solve the arrow head problem in exported Visio diagrams). Hopfully the IndexOutOfBounds exception can be tackled too soon... I noticed another difference/error(?)...i will send that in a separate mail not to blur the subject too much.. Thanks, Raphael -Original Message- From: Raphael Parree [mailto:[EMAIL PROTECTED] Sent: 25 January 2008 11:30 To: 'fop-users@xmlgraphics.apache.org' Subject: RE: SVG XML Access Jeremias, Thanks I have updated, but can't tell if it works yet. I am getting anoher problem (that does mean the source not supported was not thrown). But probably other changes in the trunk are giving me a problem. I will look into recent posts if this problem is known (something about an index out of bounds in the computeSpanHeight of the RowPainter). Will let you know if it works... -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 25 January 2008 11:02 To: fop-users@xmlgraphics.apache.org Subject: Re: SVG XML Access Sorry, I've only tested the isolated case of preloading the image so I missed the other call to closeQuietly(). I've now fixed this in the right place. Please try again. I hope it works now. http://svn.apache.org/viewvc?rev=615164view=rev On 25.01.2008 10:36:24 Raphael Parree wrote: Jeremias, Thanks for the quick reply and commit ;) I am getting the following Exception: java.lang.IllegalArgumentException: Source not supported: javax.xml.transform.dom.DOMSource. I have attached my code in the code.txt file. The whole stacktrace is in the stacktrace.txt file. I updated my FOP working copy to 615144. Tx., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 25 January 2008 09:31 To: fop-users@xmlgraphics.apache.org Subject: Re: SVG XML Access Raphael, I hadn't implemented support for a DOMSource but have done so now: http://svn.apache.org/viewvc?rev=615144view=rev Take a look at the test case that I've added. It demonstrates how you can write a URIResolver that returns an SVG DOM. That way you can do all the SVG manipulation you want. But you have to make sure the DOM Document is a org.w3c.dom.svg.SVGDocument. On 25.01.2008 08:03:38 Raphael Parree wrote: Hi Jeremias, End o last year I wrote a custom URI resolver to augment SVG files with a style entry. This has drastically influenced the PDF generation time. I recall that during that time you mentioned you were updating the Image part and that it would be easier when that was completed, because the update gives access to the SVG XML. I noticed many updates in the Image classes (in the trunk). Does this mean that there is an alternative to filtering the SVG files now? Tx., Raphael Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jeremias Maerki - 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]
linefeed-treatment in cell problem
Hi, With the current version from the trunk the linefeed-treatment preserve on a block in a table cell does not seem to work. The enclosed fo file illustrates this. Tx., Raphael linefeed-treatment.fo Description: Binary data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SVG XML Access
Vincent, I checked it and it works again. Tx! p.s. is the other problem I sent this afternoon related to the rework on tables? (Subj linefeed-treatment in cell problem) have a good one, -Original Message- From: Vincent Hennebert [mailto:[EMAIL PROTECTED] Sent: 25 January 2008 16:58 To: fop-users@xmlgraphics.apache.org Subject: Re: SVG XML Access Raphael sent me a sample FO file offline, which allowed me to spot a bug that appeared during my last refactoring of tables. The bug is now fixed in the Trunk. Thanks for the sample file, Raphael! And to the community: any feedback on the last table changes will be highly appreciated. Thanks, Vincent Raphael Parree wrote: Vincent, The rev of my local copy is the latest: 615171. When looking at http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/java/org/apache/fo p/layoutmgr/table/RowPainter.java I still see the computeSpanHeight, does that make sense? I will try to make a simple FO (due to copyright issues I cannot send the FO file I am using, sorry...) Attached is the stacktrace. I will submit a bug after I created an FO file that resolves to the same error. Tx., Raphael -- Vincent HennebertAnyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting - 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]
SVG XML Access
Hi Jeremias, End o last year I wrote a custom URI resolver to augment SVG files with a style entry. This has drastically influenced the PDF generation time. I recall that during that time you mentioned you were updating the Image part and that it would be easier when that was completed, because the update gives access to the SVG XML. I noticed many updates in the Image classes (in the trunk). Does this mean that there is an alternative to filtering the SVG files now? Tx., Raphael
RE: Mac Font problem
Andreas, That solved it for now... tx. When I have time I will try to find out the cause... Ch., -Original Message- From: Andreas L Delmelle [mailto:[EMAIL PROTECTED] Sent: 20 November 2007 08:13 To: fop-users@xmlgraphics.apache.org Subject: Re: Mac Font problem On Nov 20, 2007, at 07:56, Raphael Parree wrote: Hi I have a problem with a font on a Mac.on my PC everything seems to work but on the Macs uses by our publishing department the Courier New font does not work. It is installed on the Mac (True Type font). I am working with rev 592554 (6 nov) and use the auto detect feature. I have tried deleting the cache file as that often helps on ,my PC after using new fonts or updating FOP. I saw some posts about true type fonts on a Mac posted in feb 2006 (http:// www.nabble.com/TTFReader-and-MacOsX-.ttf-fonts- tf1139715.html#a2986169) I'm also on Mac, and noticed the same effect. Haven't looked into the exact cause, though... One possible workaround, until someone decides to get to the bottom of this: Mac OS X also supports Windows TTFs, so in the worst case, you could maybe try to replace the native Mac TTF with the Windows TTF. Untested though, can't say for sure it will work. HTH! Andreas - 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]
Mac Font problem
Hi, I have a problem with a font on a Mac.on my PC everything seems to work but on the Macs uses by our publishing department the Courier New font does not work. It is installed on the Mac (True Type font). I am working with rev 592554 (6 nov) and use the auto detect feature. I have tried deleting the cache file as that often helps on ,my PC after using new fonts or updating FOP. I saw some posts about true type fonts on a Mac posted in feb 2006 (http://www.nabble.com/TTFReader-and-MacOsX-.ttf-fonts-tf1139715.html#a29861 69) Anybody any clues? Tx., Raphael
RE: filtering SVG
Jeremias,
I might have to resolve to that...i am having difficulties inserting text
into an existing element...
So far I have, but I still need the first template to apply template so I
can get to the second template...
xsl:apply-templates select=document(...uri to svg...)/
xsl:template match=svg:*
xsl:copy-of select=. /
/xsl:template
xsl:template match=svg:style
svg:style type=text/css
xsl:textmarker { overflow:visible; }
/xsl:text
xsl:apply-templates/ /svg:style
/xsl:template
Tx (also Pascal).. I will probably try the URI Resolver..
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: 16 November 2007 10:40
To: fop-users@xmlgraphics.apache.org
Subject: Re: filtering SVG
In addition to what Pascal suggested: You can plug in a custom
URIResolver. When the image package redesign is completed you should
also be able to return a DOMSource as the result of URI resolution. At
the moment you have to return an InputStream.
Jeremias Maerki
On 16.11.2007 09:55:05 Raphael Parree wrote:
Hi,
I was wondering if the following is possible and what would be the best
approach. We use a lot of SVG (exported from Visio). These SVG always need
a
manual fix to make line ends (arrow etc) visible:
style type=text/css
![CDATA[marker { overflow:visible; }]]
/style
I would like to insert this style element to each svg during generation.
The
SVGs are added as external images. So I would need some sort of image
filter
to add this to the DOM tree of the SVG.
Is this possible, and what would be the best approach.?
Tx.,
Raphael
-
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]
filtering SVG
Hi,
I was wondering if the following is possible and what would be the best
approach. We use a lot of SVG (exported from Visio). These SVG always need a
manual fix to make line ends (arrow etc) visible:
style type=text/css
![CDATA[marker { overflow:visible; }]]
/style
I would like to insert this style element to each svg during generation. The
SVGs are added as external images. So I would need some sort of image filter
to add this to the DOM tree of the SVG.
Is this possible, and what would be the best approach.?
Tx.,
Raphael
RE: Font autodetect
Adrian, Thanks..i have applied the patch and it works! Great.. -Original Message- From: Adrian Cumiskey [mailto:[EMAIL PROTECTED] Sent: 09 October 2007 10:52 To: fop-users@xmlgraphics.apache.org Subject: Re: Font autodetect Hi Raphael, There is already a bug reported and patches provided (http://issues.apache.org/bugzilla/show_bug.cgi?id=42861) to fix this but unfortunately I don't believe that they made it into the 0.94 release. Adrian. Raphael Parree wrote: Hi, I am very happy to see the auto-detect font feature!...However, it does not seem to work correctly with me. On any first run (in my case first in a JVM instance ) it runs smoothly and as excepted. Any second run (with me in the same JVM) it fails and it can not find the Font 'Verdana, normal,400' and it is substituted with 'any,normal,400'. I get the same for some others: Verdana , 700 and Verdana, 400 italic. (note that Verdana is the only font I am using). Also note that I am not referring to the first time FOP runs and the cache file is created complaining about certaint fonts not being recognized. I am running: Java SE 5, FOP 0.94, Windows XP, my userconfig: renderer mime=application/pdf fonts auto-detect/ /fonts /renderer Any clues? Raphael - 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]
resolving Font metric file in Jar
Hi, I am quite sure (but not 100%-perhaps there was somewhere a side effect I am not seeing right now) that I was able to load the font metrics file from my classpath, where the font metrics files reside inside a jar file. The Base url is set: fopFactory.setFontBaseURL(getClass().getResource(/com/foo/).toExternalForm ()); During newFop() in the org.apache.fop.render.PrintRendererConfigurator#getFontInfoFromConfiguration the Source is created for the metrics file (the URL in the FOURIReolver is jar:file:/c:/myjar.jar!/com/foo/verdana.xml). Then later on org.apache.fop.fonts.LazyFont#load the Source remains null (the URL in the FOURIReolver is now file:/c:/myjar.jar!/com/foo/verdana.xml (no jar: prefix (!) ). Consequently the connection.connect() throws a FileNotFoundException Is this changed feature for which I need to update my code, or a bug, or am I missing something? Tx., Raphael
RE: resolving Font metric file in Jar
Adrian, Done... http://issues.apache.org/bugzilla/show_bug.cgi?id=43571 Tx., -Original Message- From: Adrian Cumiskey [mailto:[EMAIL PROTECTED] Sent: 08 October 2007 11:54 To: fop-users@xmlgraphics.apache.org Subject: Re: resolving Font metric file in Jar Hi Raphael, Could you tell me which FOP version you were originally using and which version you have upgraded to. It very much sounds like a bug, please file it at http://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop and I will investigate it. Adrian. Raphael Parree wrote: Hi, I am quite sure (but not 100%-perhaps there was somewhere a side effect I am not seeing right now) that I was able to load the font metrics file from my classpath, where the font metrics files reside inside a jar file. The Base url is set: fopFactory.setFontBaseURL(getClass().getResource(/com/foo/).toExternalForm ()); During newFop() in the org.apache.fop.render.PrintRendererConfigurator#getFontInfoFromConfiguration the Source is created for the metrics file (the URL in the FOURIReolver is jar:file:/c:/myjar.jar!/com/foo/verdana.xml). Then later on org.apache.fop.fonts.LazyFont#load the Source remains null (the URL in the FOURIReolver is now file:/c:/myjar.jar!/com/foo/verdana.xml (no jar: prefix (!) ). Consequently the connection.connect() throws a FileNotFoundException Is this changed feature for which I need to update my code, or a bug, or am I missing something? Tx., Raphael - 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: unparsed-text
Abel,
...i did not change the use of unparsed-text {blush} and replaced it with
document as per you suggestion in your original email . My Sunday has a much
brighter start, as it works as expected now. Thanks for you assistance much
appreciated!
Have a good one,
Raphael
-Original Message-
From: Abel Braaksma [mailto:[EMAIL PROTECTED]
Sent: 06 October 2007 23:43
To: fop-users@xmlgraphics.apache.org
Subject: Re: unparsed-text
Hmm, this is the moment that in a comic book all kinds of question marks
in balloons are floating above my head
I build most of my FO documents joining and knitting together snippets
etc. It doesn't (shouldn't) matter the least whether you have an XML
declaration or not. The xml namespace *is* important though if it
incorrect it will not be recognized and your FO processor will spawn errors.
But I'm curious about the way it is used or what is happening... Do you
really have an XSLT file like the following:
xsl:stylesheet
xmlns:fo=http://www.w3.org/1999/XSL/Format;
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
version=2.0
xsl:output method=xml indent=yes/
xsl:template match=/
fo:root writing-mode=lr-tb hyphenate=false
text-align=start role=xhtml:html
fo:layout-master-set
fo:simple-page-master page-width=auto
page-height=auto master-name=all-pages
your thing ...
/
/
fo:page-sequence master-reference=all-pages
etc
fo:flow flow-name=xsl-region-body
fo:block
xsl:copy-of
select=document('my-other-fo-document.fo') /
/
/
/
/
/xsl:template
xsl:template match=otherthings
... other things here ...
/
/xsl:stylesheet
Or, in other words, where does your stylesheet go different than this?
If you view the intermediate output, i.e., before it gets to the FO
processor (FOP), how does it look? Do the problem-elements look like
lt;fo:blockgt; or do you see them as fo:block? And I mean: in a
text editor of course, don't view it in a browser or somewhere else
where the XML gets interpreted.
But I have the feeling we're on the wrong track here, because what it
seems that you are describing seems as being impossible. You have to
pull quite some tricks to read a genuine XML document using the
document() function and output it as stringized XML (with stringized I
mean node becomes lt;nodegt;).
Can you post a (minimal) example of a source document, the main XSLT you
are using, the about.fo you are including? Can you also try to run it
with Saxon and then run it with FOP.bat on the commandline, see if the
effect is equal?
Sorry if I can't (yet) be of more help.
Cheers,
-- Abel Braaksma
Raphael Parree wrote:
Abel,
Even the snippet from below echoes into the PDF as listed:
about.fo:
?xml version=1.0 encoding=UTF-8?
fo:block id=one xmlns:fo=http://www.w3.org/1999/XSL/Format;
fo:block font-weight=boldtest/fo:block
/fo:block
I have tried with and without xml declaration, and with/without the
namespace declaration.
-
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]
unparsed-text
Hi,
I am in the midst of upgrading to XSLT 2.0. One of the reasons moving is to
be able to use the XSLT function unparsed-text.
I am using it like:
fo:page-sequence master-reference=somref
fo:flow flow-name=xsl-region-body
fo:block
xsl:value-of select=unparsed-text('about.fo'),'utf-8')
disable-output-escaping=yes/
/fo:block
/fo:flow
/fo:page-sequence
The about.fo is an fo file.
The resulting PDF however has a page full of FO instructions (the literal
contents of the about.fo file) not rendered by the FOP engine. When I run
with an XSLT engine (Saxon in oXygen), the resulting fo file looks ok (with
the about.fo nicely in it)
I am using my transformer like: transformer.transform(xmlSource, new
SAXResult(fop.getDefaultHandler()));
I am using Saxon8, the fop version I am not 100% (my build id is Build-Id in
the manifest is: 20061120-085325-CET, so I probably have a version from end
of last year.)
Any clues?
Tx.,
Raphael
RE: unparsed-text
Abel,
Thanks for you reply. Indeed there are many other reasons why I am moving to
XSLT2.0...
I was thinking along the same lines as you...I also came to the conclusion
that the receiving SAXResult cannot parse the text I added. Using copy-of
escapes my fo file, so it unfortunately comes out the same way. Perhaps the
xsl:character-map might solve this, I however do not see yet how I would use
that in conjunction with the copy-of...something to look into. What
obviously works is to save the result of the transformation as text (to a
StreamResult), and then use a SAXParser to parse the whole thing again to
FOP's SAX handler.
Again, thanks...
Raphael
-Original Message-
From: Abel Braaksma [mailto:[EMAIL PROTECTED]
Sent: 06 October 2007 20:12
To: fop-users@xmlgraphics.apache.org
Subject: Re: unparsed-text
Hi Raphael,
There are many good reasons to move to XSLT 2.0, and one of them could
very well be to use unparsed-text. But in your case, you don't want
unparsed text, you want parsed text (that is, you want the content of
the about.fo file to be interpreted as a literal result element, or you
may want to process it further). To doe that, you should change the
below xsl:value-of code (which takes the *value* of a node, which is a
string) to an xsl:copy-of instruction (which copies the content of the
select statement to the output without modification, which is what you
are after).
In lieu of this: using disable-output-escaping is strongly discouraged
and in general not a good idea. Processors are not required to support
it and even if they do, the output is not guaranteed to be the same
across processors, even worse, the the d-o-e instruction may be ignored
if the processors thinks that is better (i.e., to create a valid
outputstream it may think it is wise to ignore the d-o-e instruction).
Since you are using the fabulous and widely extended XSLT 2.0, if you
ever feel the need to go beyond its output encoding capabilities, use
the xsl:character-map declaration, which gives you a much better control
over the output than d-o-e ever would. Besides, it is very well defined
and will guarantee the same output between processors.
Back to your problem. Simply replace the xsl:value-of line as follows
and all should work:
xsl:copy-of select=document('about.fo') /
If you have questions about XSL in general (not specific to FOP) you may
find the XSL list on Mulberry Technologies an excellent resource. It is
well maintained and one of its chief posters is the creator of XSLT 2.0
himself: http://www.mulberrytech.com/xsl/xsl-list/
HTH,
Cheers,
Abel
PS: hopefully someone else will follow-up on the configuration problem
with FOP to get it to use the transformer from Saxon. I should know
how-to, but it's too long ago... ;)
Raphael Parree wrote:
Hi,
I am in the midst of upgrading to XSLT 2.0. One of the reasons moving
is to be able to use the XSLT function unparsed-text.
I am using it like:
fo:page-sequence master-reference=somref
fo:flow flow-name=xsl-region-body
fo:block
xsl:value-of select=unparsed-text('about.fo'),'utf-8')
disable-output-escaping=yes/
/fo:block
/fo:flow
/fo:page-sequence
The about.fo is an fo file.
The resulting PDF however has a page full of FO instructions (the
literal contents of the about.fo file) not rendered by the FOP engine.
When I run with an XSLT engine (Saxon in oXygen), the resulting fo
file looks ok (with the about.fo nicely in it)
I am using my transformer like: transformer.transform(xmlSource, new
SAXResult(fop.getDefaultHandler()));
I am using Saxon8, the fop version I am not 100% (my build id is
Build-Id in the manifest is: 20061120-085325-CET, so I probably have a
version from end of last year.)
Any clues?
Tx.,
Raphael
-
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: unparsed-text
Abel, Even the snippet from below echoes into the PDF as listed: about.fo: ?xml version=1.0 encoding=UTF-8? fo:block id=one xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:block font-weight=boldtest/fo:block /fo:block I have tried with and without xml declaration, and with/without the namespace declaration. -Original Message- From: Abel Braaksma [mailto:[EMAIL PROTECTED] Sent: 06 October 2007 23:16 To: fop-users@xmlgraphics.apache.org Subject: Re: unparsed-text Raphael Parree wrote: Abel, Thanks for you reply. Indeed there are many other reasons why I am moving to XSLT2.0... I was thinking along the same lines as you...I also came to the conclusion that the receiving SAXResult cannot parse the text I added. Using copy-of escapes my fo file, so it unfortunately comes out the same way. Very weird, to say the least. Any FO file is an XML file. The document() function can only handle XML documents. Using xsl:copy-of will copy exactly what is input. Can you give a snippet of how this about.fo file looks like? If it isn't XML the document() function will choke, but if it is XML and it contains, say, some CDATA element with content that looks like XML, than it is stringized XML, which cannot (straightforwardly) be interpreted as XML. To find out, simply paste a part (or whole) of your about.fo file here and we'll have a look Perhaps the xsl:character-map might solve this, I however do not see yet how I would use that in conjunction with the copy-of...something to look into. What obviously works is to save the result of the transformation as text (to a StreamResult), and then use a SAXParser to parse the whole thing again to FOP's SAX handler. That wouldn't be the 'XML' or 'XSLT' way to do things and it will become awkward in the long run and with maintenance. Just paste your whole about.fo here and we'll see what can be done. Cheers, -- Abel Braaksma - 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]
Maven repo
Hi, FOP 0.94 has not been added to a public maven repository yet? (could for example not find it at http://repo1.maven.org/maven2/org/apache/xmlgraphics/fop/) Tx., Raphael
RE: keep-together always
Hi, What I would except in such a case is that the content is transferred to the next page if there is not enough space on the current page. Is that not how it is intended (like for example in word-processing programs such as MS Word) Tx., Raphael -Original Message- From: Vincent Hennebert [mailto:[EMAIL PROTECTED] Sent: 13 June 2007 08:52 To: fop-users@xmlgraphics.apache.org Subject: Re: keep-together always Hi, Kamal Bhatt a écrit : Hi I noticed a feature of keep-together=always. Basically it does exactly that, even when it doesn't make sense. That is, it will overflow a block instead of breaking across a page. Now, I have looked at the standard, and it is fairly airy fairy about what keep-together=always actually does: *always* Imposes a keep-together condition with strength always in the appropriate context. What appropriate context means is anyone's guess. From what I have read, The context here is the line, column or page, depending on whether the keep has a .within-line, .within-column of .within-page component. some have interpreted this to mean that always is the highest possible strength. Seems to me that makes sense. So is this bit of functionality a bug? That's where I think there is room for interpretation and where I got confused last time. The common interpretation seems to be that always is more than just the highest possible strength: it prevents the content to be broken even if it overflows the context (line, column, page). Whereas even a very high integer value wouldn't prevent that. After all this makes sense: we can imagine situations where the user prefers the content to be clipped rather than broken over two, e.g., pages. always allows for that. If the user simply wants the content to be broken only if it doesn't fit, they would choose an integer value. While not being explicitely described by the spec, the last paragraph of section 4.8, Keeps and Breaks, seems to imply that when saying If not all of a set of keep conditions [...] can be satisfied Vincent - 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]
Fireworks PNG
Hi, I am in process of moving to Fireworks CS3 for imaging and when saving in the PNG from Fireworks (Fireworks PNG), FOP (trunk version from around 20061120) throws an exception. (java.io.EOFException see whole stacktrace below. When saving from Firworks in Flattened PNG FOP is able to show. I understand this is a Fireworks problem and not a FOP problem. But is there any change that FOP would support this type? What would need to be done to support this Firworks Image type? (The reason, when saving in Flattened mode you loose the objects/layers etc in your drawing, editing it then later is difficult) Tx., Raphael java.io.EOFException at javax.imageio.stream.ImageInputStreamImpl.readFully(ImageInputStreamImpl.jav a:330) at java.io.DataInputStream.readUTF(DataInputStream.java:565) at javax.imageio.stream.ImageInputStreamImpl.readUTF(ImageInputStreamImpl.java: 309) at com.sun.imageio.plugins.png.PNGImageReader.parse_iTXt_chunk(PNGImageReader.j ava:443) at com.sun.imageio.plugins.png.PNGImageReader.readMetadata(PNGImageReader.java: 647) at com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.java:130 9) at com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1579) at org.apache.fop.image.ImageIOImage.loadBitmap(ImageIOImage.java:96) at org.apache.fop.image.ImageIOImage.loadDimensions(ImageIOImage.java:66) at org.apache.fop.image.AbstractFopImage.load(AbstractFopImage.java:160) at org.apache.fop.fo.flow.ExternalGraphic.bind(ExternalGraphic.java:73) at org.apache.fop.fo.FObj.processNode(FObj.java:118) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.jav a:321) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:185) at org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Logging per generation process
Jeremias, I totally agree with you, the information level for an end-user should be different from the logging information. I am certainly looking forward to a solution with a Future like approach where the information from the process can be obtained after processing has taken place using the FormattingResults object. In the meantime I have a solution for our multithreaded application using a ThreadLocal...iow the pressure is off and the app can go into production. I would love to help, but know that I can't give that commitment. Tx., Raphael -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 28 February 2007 16:19 To: fop-users@xmlgraphics.apache.org Subject: Re: Logging per generation process Hi Raphael If that works for you that's great. A ThreadLocal is certainly a possibility especially as long as we don't do multi-threaded processing. However, my ideas go in a different direction as described on the Wiki. The important thing for me is to differentiate between feedback for developers (logging as we have today) and for users (specific feedback per processing run). I'm not so much interested in log output during production. I can still catch configuration or runtime errors and such using the log but for that I don't need per-document logging. Rather I want precise information on certain events (like an area overflow or a missing image) during processing that can be presented to a not-so-technical user possibly even in his native language. In the meantime the priority of this has gone up a little although I still can't tell when exactly we'll have something in this area. On 21.02.2007 18:51:31 Raphael Parree wrote: Jeremias, I replying a bit late (this reply is to an email dating back to November last year) see messages below. I have solved it using a ThreadLocal object and a custom log4j Appender, which might be something that leads to an easy solution. It worked for me, but don't know how to make it more structural. Have other people experimented with using this approach for logging per process using a static logger? A threadlocal object can be placed at the start of the transformation process, and perhaps store information in the FormattingResults object? What do you think? Sorry the original thread was missing: The status is the same as when I wrote that text. At some point this will be done but at this time it's only on my wish list. My notes on the issue are on the Wiki: http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback See also: http://wiki.apache.org/xmlgraphics-fop/ApiRequirements You're welcome to dive in yourself, of course. On 27.11.2006 10:17:49 Raphael Parree wrote: Hi, What is the status on We are planning to add an additional feedback facility to FOP which can be used to obtain all sorts of specific feedback (validation messages, layout problems etc.)!? I need per generation process logging...if the above has not been implemented is there a way of doing this? Tx., Raphael Jeremias Maerki - 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: Re: Logging per generation process
Jeremias, I replying a bit late (this reply is to an email dating back to November last year) see messages below. I have solved it using a ThreadLocal object and a custom log4j Appender, which might be something that leads to an easy solution. It worked for me, but don't know how to make it more structural. Have other people experimented with using this approach for logging per process using a static logger? A threadlocal object can be placed at the start of the transformation process, and perhaps store information in the FormattingResults object? What do you think? Sorry the original thread was missing: The status is the same as when I wrote that text. At some point this will be done but at this time it's only on my wish list. My notes on the issue are on the Wiki: http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback See also: http://wiki.apache.org/xmlgraphics-fop/ApiRequirements You're welcome to dive in yourself, of course. On 27.11.2006 10:17:49 Raphael Parree wrote: Hi, What is the status on We are planning to add an additional feedback facility to FOP which can be used to obtain all sorts of specific feedback (validation messages, layout problems etc.)!? I need per generation process logging...if the above has not been implemented is there a way of doing this? Tx., Raphael
Logging per generation process
Hi, What is the status on We are planning to add an additional feedback facility to FOP which can be used to obtain all sorts of specific feedback (validation messages, layout problems etc.)!? I need per generation process logging...if the above has not been implemented is there a way of doing this? Tx., Raphael
RE: Illegalstate
Hi, I was doing some additional checks this morning, and found out the problem is an IndexOutOfBoundsException inside the org.apache.fop.fo.StaticPropertyList. The get function gets called with propId 252, whereas the length of the values array is 252. The calling object is org.apache.fop.fo.flow.Table which calls the get method of the PropertyList with a static value of PR_X_WIDOW_CONTENT_LIMIT, which is 252. Is this helpful? Tx., Raphael -Original Message- From: Raphael Parree [mailto:[EMAIL PROTECTED] Sent: 19 November 2006 14:16 To: 'fop-users@xmlgraphics.apache.org' Subject: RE: Illegalstate Jeremias, Ok, I was kind of hoping someone would know why this occurs as it has to do with recent changes in FOP (my previous build did not have this problem). I will need to isolate the problem, so that I don't have to send everything (copyright issues). It will take me some time to strip until I keep what is producing the problem. Tx., Raphael -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 17 November 2006 17:39 To: fop-users@xmlgraphics.apache.org Subject: Re: Illegalstate Please send an FO file (not XSLT!) that illustrates the problem. Then we can track it down. On 17.11.2006 15:54:47 Raphael Parree wrote: Hi, I just update to the latest trunk (my previous version was from the trunk somewhere around 2006-09-08; that's when I built the fop.jar) I get the following error. The error is an illegal state exception stating that endElement is called for fo:root where there is no current element. Below is the log in my console window. What direction should I be looking to solve this? 17-Nov-2006 15:41:40 org.apache.fop.fo.FOTreeBuilder$MainFOHandler endElement WARNING: Mismatch: block (http://www.w3.org/1999/XSL/Format) vs. table (http://w ww.w3.org/1999/XSL/Format) 17-Nov-2006 15:41:40 org.apache.fop.fo.FOTreeBuilder$MainFOHandler endElement WARNING: Mismatch: flow (http://www.w3.org/1999/XSL/Format) vs. block (http://ww w.w3.org/1999/XSL/Format) 17-Nov-2006 15:41:40 org.apache.fop.fo.FOTreeBuilder$MainFOHandler endElement WARNING: Mismatch: page-sequence (http://www.w3.org/1999/XSL/Format) vs. flow (h ttp://www.w3.org/1999/XSL/Format) 17-Nov-2006 15:41:40 org.apache.fop.fo.FOTreeBuilder$MainFOHandler endElement WARNING: Mismatch: root (http://www.w3.org/1999/XSL/Format) vs. page-sequence (h ttp://www.w3.org/1999/XSL/Format) Jeremias Maerki - 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: Illegalstate
Jeremias, Ok, I was kind of hoping someone would know why this occurs as it has to do with recent changes in FOP (my previous build did not have this problem). I will need to isolate the problem, so that I don't have to send everything (copyright issues). It will take me some time to strip until I keep what is producing the problem. Tx., Raphael -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 17 November 2006 17:39 To: fop-users@xmlgraphics.apache.org Subject: Re: Illegalstate Please send an FO file (not XSLT!) that illustrates the problem. Then we can track it down. On 17.11.2006 15:54:47 Raphael Parree wrote: Hi, I just update to the latest trunk (my previous version was from the trunk somewhere around 2006-09-08; that's when I built the fop.jar) I get the following error. The error is an illegal state exception stating that endElement is called for fo:root where there is no current element. Below is the log in my console window. What direction should I be looking to solve this? 17-Nov-2006 15:41:40 org.apache.fop.fo.FOTreeBuilder$MainFOHandler endElement WARNING: Mismatch: block (http://www.w3.org/1999/XSL/Format) vs. table (http://w ww.w3.org/1999/XSL/Format) 17-Nov-2006 15:41:40 org.apache.fop.fo.FOTreeBuilder$MainFOHandler endElement WARNING: Mismatch: flow (http://www.w3.org/1999/XSL/Format) vs. block (http://ww w.w3.org/1999/XSL/Format) 17-Nov-2006 15:41:40 org.apache.fop.fo.FOTreeBuilder$MainFOHandler endElement WARNING: Mismatch: page-sequence (http://www.w3.org/1999/XSL/Format) vs. flow (h ttp://www.w3.org/1999/XSL/Format) 17-Nov-2006 15:41:40 org.apache.fop.fo.FOTreeBuilder$MainFOHandler endElement WARNING: Mismatch: root (http://www.w3.org/1999/XSL/Format) vs. page-sequence (h ttp://www.w3.org/1999/XSL/Format) Jeremias Maerki - 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]
Illegalstate
Hi, I just update to the latest trunk (my previous version was from the trunk somewhere around 2006-09-08; that's when I built the fop.jar) I get the following error. The error is an illegal state exception stating that endElement is called for fo:root where there is no current element. Below is the log in my console window. What direction should I be looking to solve this? 17-Nov-2006 15:41:40 org.apache.fop.fo.FOTreeBuilder$MainFOHandler endElement WARNING: Mismatch: block (http://www.w3.org/1999/XSL/Format) vs. table (http://w ww.w3.org/1999/XSL/Format) 17-Nov-2006 15:41:40 org.apache.fop.fo.FOTreeBuilder$MainFOHandler endElement WARNING: Mismatch: flow (http://www.w3.org/1999/XSL/Format) vs. block (http://ww w.w3.org/1999/XSL/Format) 17-Nov-2006 15:41:40 org.apache.fop.fo.FOTreeBuilder$MainFOHandler endElement WARNING: Mismatch: page-sequence (http://www.w3.org/1999/XSL/Format) vs. flow (h ttp://www.w3.org/1999/XSL/Format) 17-Nov-2006 15:41:40 org.apache.fop.fo.FOTreeBuilder$MainFOHandler endElement WARNING: Mismatch: root (http://www.w3.org/1999/XSL/Format) vs. page-sequence (h ttp://www.w3.org/1999/XSL/Format)
Image overflow
Hi, This might have been answered, but could only find something on this in the archive of 2003. I believe in the 0.20.5 release images that where to wide were scaled down. Many of my the content that used to end up in a successful transformed PDF, now break on not being able to fit the text on a page. Is my assumption right that in the 0.20.5 release it worked as described here, and is this something that can be turned on in the latest release? Tx., Raphael
RE: SVG Font quality
Jeremias, You are right when zooming in the text looks better, and indeed the printing quality is good. However we also generate a PDF which is used as a presentation and is therefore not printed. Having both a presentation and a book was actually the reason to move to SVG as they scale well in printed form as on screen. :( Will the code be refined in the near future :) Tx., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 13 June 2006 08:52 To: fop-users@xmlgraphics.apache.org Subject: Re: SVG Font quality As I suspected. The SVG contains tspan elements which are rendered as shapes by 0.92beta to be on the safe side. What you're seeing is only the effect of painting vector graphics (as opposed to painting text). If you zoom in on the text the quality will get better. It doesn't look bad if you print it, does it? Some SVG text elements are difficult to be painted using text operators in PDF so that's when we fall back to painting as shapes (prime example: text on a path). The tspan element in your case are pretty simple which could actually allow painting as text but the code is not that refined, yet. The regression from 0.20.5 can be explained that 0.20.5 didn't care much about tspan elements which could lead to poor output. 0.92 is more careful. On 12.06.2006 18:03:49 Raphael Parree wrote: Jeremias, Attached is the SVG. The PDF viewer I'm using is Adobe Acrobat (7.something). The quality used to be great with the FOP 0.20.5 bundle. I would assume it is a batik problem, if the batik-1.6-squiggle viewer would not show the rendered SVG in the appropriate quality. Cheers., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 07 June 2006 09:59 To: fop-users@xmlgraphics.apache.org Subject: Re: SVG Font quality The GIF helps showing the symptom but not the reason for the problem. Fonts can generally be rendered in two ways: text operations and vector graphics. In your case, I assume the text was rendered as vector graphics. If smooth line art is disabled (or not supported) in your PDF viewer, it could explain the poorer quality. It could help to see your SVG file. But also note that some text elements cannot be painted as text operations, yet. The choice which kind is used depends on the SVG content. On 06.06.2006 13:11:41 Raphael Parree wrote: Hi, I noticed the quality of my fonts in the SVG is noticeably less in 0.92b than in was with 0.20.5. Attached is an example (left is the PDF, right is batik-1.6-squiggle). I am embedding the fonts (Verdana) in my PDF. The SVG is included using defaults (with 72 as the resolution). Any clues? Jeremias Maerki - 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]
TOC problem (text-align-last)
Title: TOC problem (text-align-last)
Hi,
I have seen some posts on this earlier this year (e.g, http://www.nabble.com/TOC-problem-with-text-align-last-t1432522.html#a3864138), but no solution that works for me
The problem is quite simple; in my TOC the page numbers are not correctly aligned. In FOP 0.20.5 it worked, but with 0.92b (or the latest trunk) version it doesnt.
I believe my code is straightforward:
fo:block text-align-last=justify font-family=Verdana font-size=12pt font-weight=bold
space-before=12pt space-after=6pt
xsl:apply-templates select=cws:title/
fo:leader leader-pattern=dots/
fo:page-number-citation ref-id={generate-id()}/
/fo:block
fo:block text-align-last=justify start-indent=0.76cm font-family=Verdana font-size=12pt
space-before=6pt space-after=3pt space-after.conditionality=retain
space-before.conditionality=retain
xsl:choose
xsl:when test=cws:lesson
xsl:apply-templates select=cws:title/
/xsl:when
xsl:when test=cwe:exercise
xsl:apply-templates select=cwe:info/cwe:title/
/xsl:when
/xsl:choose
fo:leader leader-pattern=dots/
fo:page-number-citation ref-id={generate-id()}/
/fo:block
fo:block space-before.conditionality=retain space-after.conditionality=retain
space-after=3pt space-before=6pt font-size=12pt font-family=Verdana
start-indent=0.76cm text-align-last=justifyDefine the System Requirements (Creating the
PIM)fo:leader leader-pattern=dots/fo:page-number-citation ref-id=N10A17
//fo:block
Any clues?
Tx.,
Raphael
RE: LazyFont NullPointerException
Jeremias, FYI I was eventually able to test the new version on a Mac today, and I can tell you that indeed the font problem does not occur on the 0.92b version (latest trunk version of this afternoon). Tx., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 09:51 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException I guessed that you're using 0.20.5 from the stack trace but yes, it's always good to state the FOP version. I don't have access to a MacOSX system that would allow me to track this down. You should find out if there are any apparent differences in the setup between the operating systems. It may necessary to run a debugger. If it's possible I'd suggest you try to see if you can use FOP 0.92beta instead. It may well be that the problem doesn't exist in that version. Otherwise, it's where the fun happens and where problems are much more likely to be solved. 0.20.5 is not maintained anymore. On 29.05.2006 17:59:44 Raphael Parree wrote: Hi, No there is no such message. I should probably also say that I am still using version 0.20.5 and not the latest from SVN. Tx., Raphael -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 29 May 2006 16:42 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException Was there a message Failed to read font metrics file... just before the exception? If yes, the NullPointerException is a consequence of that error. Maybe it's just a path which is not correct. On 29.05.2006 08:43:16 Raphael Parree wrote: Hi, I get the following error when trying to run an app on Mac X. I have successfully ran this app on Linux and Windows. I did see a posting back in 2003 with the same problem, but no apparent solution. The fonts I use are Verdana and Arial (bold, italic etc). The TTF files originate from a Windows XP machine (which do work on Redhat). snip/ Jeremias Maerki - 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: SVG Font quality
Jeremias, Attached is the SVG. The PDF viewer I'm using is Adobe Acrobat (7.something). The quality used to be great with the FOP 0.20.5 bundle. I would assume it is a batik problem, if the batik-1.6-squiggle viewer would not show the rendered SVG in the appropriate quality. Cheers., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 07 June 2006 09:59 To: fop-users@xmlgraphics.apache.org Subject: Re: SVG Font quality The GIF helps showing the symptom but not the reason for the problem. Fonts can generally be rendered in two ways: text operations and vector graphics. In your case, I assume the text was rendered as vector graphics. If smooth line art is disabled (or not supported) in your PDF viewer, it could explain the poorer quality. It could help to see your SVG file. But also note that some text elements cannot be painted as text operations, yet. The choice which kind is used depends on the SVG content. On 06.06.2006 13:11:41 Raphael Parree wrote: Hi, I noticed the quality of my fonts in the SVG is noticeably less in 0.92b than in was with 0.20.5. Attached is an example (left is the PDF, right is batik-1.6-squiggle). I am embedding the fonts (Verdana) in my PDF. The SVG is included using defaults (with 72 as the resolution). Any clues? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] table with generator types.svg Description: Binary data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Original ValidationException disappears
Hi, I will get back on this friday and let you know. I will test if it is the filter using a test filter that I can then share with you. tx., On 6/7/06, Andreas L Delmelle [EMAIL PROTECTED] wrote: On Jun 7, 2006, at 11:34, Jeremias Maerki wrote: I don't manage to reproduce the problem with your description. I've put a list-item as direct child of a block and FOP fails properly with a ValidationException. Would you please post an FO file that I can use to reproduce it? Thanks.FWIW: I was a bit puzzled too about this. Purely looking at the FOP code, I don't see how this could happen.I'm not sure, but IIRC, Raphael was working on placing an XMLFilterin between, and that may be causing the misleading error messages...Tried myself too, and without any customization, FOP halts as expected. A possible cause is that FOTreeBuilder$MainFOHandler.startElement()fails with a ValidationException that the custom code catches andrecovers from, instead of rethrowing. If this happens, thenFOTreeBuilder.delegate.endElement () could be called for an elementthat doesn't exist, or some other weirdness could take place, likethe 'depth' member variable being incremented in startElement(), butmissing one decrement in endElement() (?) Remote guesses, but IMO we have to assume it's the custom code here(unless Raphael has evidence to prove otherwise).Later,Andreas- To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]
RE: Preprocessing
Thanks, I have most stuff working again However, ... My SAXFilter does not work anymore (the one that performs syntax highlighting). It might be due to some ordering problem. The filter is injected using: CodeBlockXMLFilter filter = new CodeBlockXMLFilter(); filter.setContentHandler(fop.getDefaultHandler()); transformer.transform(xmlSource, new SAXResult(filter)); When the filter reaches my element, it writes all characters to a buffer, which is than processed in the endElement. The last step in the processing is inserting multiple fo:inline element (with the color of a specific keyword). I insert these elements using the methods of super (i.e., XMLFilterImpl): startElement, characters and endElement. It did work under 0.20.5... Any clues? -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 05 June 2006 11:30 To: fop-users@xmlgraphics.apache.org Subject: Re: Preprocessing On 05.06.2006 11:12:22 Raphael Parree wrote: Thanks yes I know the reason for the error, it is just that I didn't had so many with the 0.20.5 release. Probably has to do with the fact that 0.92 is more strict. Also many of my indentations have changed, and text seems to be more compressed. A few changes I see so far in the produced PDF: -Indentations (start-indent) is much larger. Is this because the start-indent from parent blocks are accumulated now? 0.20.5 had an awful compliance level in this area. The new codebase is a 100% compliant implementation for start-indent and friends. start-indent can accumulate if you cross reference-area boundaries (block-containers or tables in between. That is due to indent inheritance which is described in detail in: http://wiki.apache.org/xmlgraphics-fop/IndentInheritance -space-before seems to be ignored? No, no. 0.20.5 always behaved as if space-before.conditionality=retain were specified. The new codebase does full space resolution (XSL 1.0, 4.3) except in footnote areas. That's what you're seeing. Just set space-before.conditionality=retain and your spaces will miraculously appear again. :-) -Some (all?) images seem to be bigger than before (SVG, I use the external-graphic element default) Hmm, depends on your SVGs. If they have absolute width and height (not specified in pixels) attributes and a viewbox (which is preferred in the first place), they will be the same as 0.20.5 or even better. Try setting source-resolution96/source-resolution (default is 72) in the user configuration file or use FopFactory.setSourceResolution(96). This changes the way the size of images only made up by a number of pixels are determined. Most SVG editors seem to use 96dpi, but that's not a hard value. Therefore, it is best practice to specify the size of SVG images in centimeters or inches or whatever. (-Bookmarks don't work (I saw the note on the website)) Where? XSL 1.1 bookmarks are fully implemented for PDF output. You simple have to change from fox:outline to XSL 1.1 bookmarks. See: http://xmlgraphics.apache.org/fop/0.92/upgrading.html For the rest it looks promising. snip/ Jeremias Maerki - 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: Preprocessing
Found it... The namespace on fo:inline's attributes must be NULL and not http://www.w3.org/1999/XSL/Format. -Original Message- From: Raphael Parree [mailto:[EMAIL PROTECTED] Sent: 05 June 2006 16:31 To: 'fop-users@xmlgraphics.apache.org' Subject: RE: Preprocessing Thanks, I have most stuff working again However, ... My SAXFilter does not work anymore (the one that performs syntax highlighting). It might be due to some ordering problem. The filter is injected using: CodeBlockXMLFilter filter = new CodeBlockXMLFilter(); filter.setContentHandler(fop.getDefaultHandler()); transformer.transform(xmlSource, new SAXResult(filter)); When the filter reaches my element, it writes all characters to a buffer, which is than processed in the endElement. The last step in the processing is inserting multiple fo:inline element (with the color of a specific keyword). I insert these elements using the methods of super (i.e., XMLFilterImpl): startElement, characters and endElement. It did work under 0.20.5... Any clues? -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 05 June 2006 11:30 To: fop-users@xmlgraphics.apache.org Subject: Re: Preprocessing On 05.06.2006 11:12:22 Raphael Parree wrote: Thanks yes I know the reason for the error, it is just that I didn't had so many with the 0.20.5 release. Probably has to do with the fact that 0.92 is more strict. Also many of my indentations have changed, and text seems to be more compressed. A few changes I see so far in the produced PDF: -Indentations (start-indent) is much larger. Is this because the start-indent from parent blocks are accumulated now? 0.20.5 had an awful compliance level in this area. The new codebase is a 100% compliant implementation for start-indent and friends. start-indent can accumulate if you cross reference-area boundaries (block-containers or tables in between. That is due to indent inheritance which is described in detail in: http://wiki.apache.org/xmlgraphics-fop/IndentInheritance -space-before seems to be ignored? No, no. 0.20.5 always behaved as if space-before.conditionality=retain were specified. The new codebase does full space resolution (XSL 1.0, 4.3) except in footnote areas. That's what you're seeing. Just set space-before.conditionality=retain and your spaces will miraculously appear again. :-) -Some (all?) images seem to be bigger than before (SVG, I use the external-graphic element default) Hmm, depends on your SVGs. If they have absolute width and height (not specified in pixels) attributes and a viewbox (which is preferred in the first place), they will be the same as 0.20.5 or even better. Try setting source-resolution96/source-resolution (default is 72) in the user configuration file or use FopFactory.setSourceResolution(96). This changes the way the size of images only made up by a number of pixels are determined. Most SVG editors seem to use 96dpi, but that's not a hard value. Therefore, it is best practice to specify the size of SVG images in centimeters or inches or whatever. (-Bookmarks don't work (I saw the note on the website)) Where? XSL 1.1 bookmarks are fully implemented for PDF output. You simple have to change from fox:outline to XSL 1.1 bookmarks. See: http://xmlgraphics.apache.org/fop/0.92/upgrading.html For the rest it looks promising. snip/ Jeremias Maerki - 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]
Preprocessing
Hi, Would you perhaps have a demo/example showing the best way of postprocessing the FO after XSL transformation before it is fed to FOP? Tx., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 13:27 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException Frankly, migrating this kind of extension could be a problem. But I'm not sure. At any rate, there's no layout() method anymore and the FO tree itself had a few changes, too. If I were you I wouldn't implement something like that as a FOP extension but as a generic, SAX-based pre-processor which is independent of the FO processor. That would make the thing much more versatile. On 30.05.2006 13:13:16 Raphael Parree wrote: The extension performs syntax checking and color highlighting of various languages (JAVA, JSP, HTML, XML, SQL, HQL, EJBQL etc). It does not generate SVG, but produces FO where it changes the font attributes. It extends the FObj and relies on the layout method to call an addText method for each token. I can't recall from which example I obtained the skeleton code (especially the addText method). Do you think it will be an easy transition? I have been postponing the move, but am aware that one day I will have to make it ;) -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 12:40 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException The extension API has been stable for a while. A few months ago I've added some additional gadgets I needed for Barcode4J. I don't expect any major changes anymore. Backwards-incompatible changes are highly unlikely, but no guarantees. So far, there's no documentation for writing extensions. I usually point people at Barcode4J as the prime example. :-) The examples directory in the distribution (MathML and plan extensions) can also help. The migration shouldn't be too difficult. A few things have changed but most of your custom code can stay the same. I'm pretty confident that you can do the migration in 2 or 3 hours max if your extension simply generates SVG. Now, I'm curious: What kind of extensions did you implement? On 30.05.2006 11:57:13 Raphael Parree wrote: Hi, I would like to move to 0.92beta, but have so far been reluctant to make the move due to the FOP extension we have written. Is it safe to start porting the extensions (IOW is the extension API stable?). Is there documentation available on writing extensions for the new release (or even better on how to migrate your extensions?) Jeremias Maerki - 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] Jeremias Maerki - 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: Preprocessing
Thanks got the highlighter working again using an XMLFilter (working on 0.20.5). Trying now to move to 0.92, but that is giving many headaches...many Some content could not fit into a line/page after 50 attempts. Giving up to avoid an endless loop occur...(I am now moving first without the extension/filter) -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 02 June 2006 09:50 To: fop-users@xmlgraphics.apache.org Subject: Re: Preprocessing I don't have a working example ready to pass over but I can give you some pointers. Essentially, I think you'd best implement an org.xml.sax.XMLFilter (you can case XMLFilterImpl as a base class). That's the recommended way. You can get some hints to the approach from: http://www.javalobby.org/java/forums/m91825016.html http://www.javalobby.org/forums/thread.jspa?threadID=16216tstart=0 In FOP we also have code that operates similarly although it's not a filter/conversion operation on the XML level. Since we're on the receiving end of the SAX chain and thus have to operate purely on the passive side, we can't use XMLFilter. Everything is implemented as a passive ContentHandler (active would mean it would be an XMLReader with parse() methods). This is all code used to build the FO tree and foreign elements. Building blocks are: - org.apache.fop.fo.FOTreeBuilder and it's nested MainFOHandler. - org.apache.fop.util.DelegatingContentHandler - org.apache.fop.util.ContentHandlerFactory - org.apache.fop.util.ContentHandlerFactoryRegistry But don't look too much at FOP. I'd use the XMLFilter approach. Good luck! On 02.06.2006 08:56:25 Raphael Parree wrote: Hi, Would you perhaps have a demo/example showing the best way of postprocessing the FO after XSL transformation before it is fed to FOP? Tx., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 13:27 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException Frankly, migrating this kind of extension could be a problem. But I'm not sure. At any rate, there's no layout() method anymore and the FO tree itself had a few changes, too. If I were you I wouldn't implement something like that as a FOP extension but as a generic, SAX-based pre-processor which is independent of the FO processor. That would make the thing much more versatile. On 30.05.2006 13:13:16 Raphael Parree wrote: The extension performs syntax checking and color highlighting of various languages (JAVA, JSP, HTML, XML, SQL, HQL, EJBQL etc). It does not generate SVG, but produces FO where it changes the font attributes. It extends the FObj and relies on the layout method to call an addText method for each token. I can't recall from which example I obtained the skeleton code (especially the addText method). Do you think it will be an easy transition? I have been postponing the move, but am aware that one day I will have to make it ;) -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 12:40 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException The extension API has been stable for a while. A few months ago I've added some additional gadgets I needed for Barcode4J. I don't expect any major changes anymore. Backwards-incompatible changes are highly unlikely, but no guarantees. So far, there's no documentation for writing extensions. I usually point people at Barcode4J as the prime example. :-) The examples directory in the distribution (MathML and plan extensions) can also help. The migration shouldn't be too difficult. A few things have changed but most of your custom code can stay the same. I'm pretty confident that you can do the migration in 2 or 3 hours max if your extension simply generates SVG. Now, I'm curious: What kind of extensions did you implement? On 30.05.2006 11:57:13 Raphael Parree wrote: Hi, I would like to move to 0.92beta, but have so far been reluctant to make the move due to the FOP extension we have written. Is it safe to start porting the extensions (IOW is the extension API stable?). Is there documentation available on writing extensions for the new release (or even better on how to migrate your extensions?) Jeremias Maerki - 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: LazyFont NullPointerException
Hi, I would like to move to 0.92beta, but have so far been reluctant to make the move due to the FOP extension we have written. Is it safe to start porting the extensions (IOW is the extension API stable?). Is there documentation available on writing extensions for the new release (or even better on how to migrate your extensions?) Tx., -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 09:51 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException I guessed that you're using 0.20.5 from the stack trace but yes, it's always good to state the FOP version. I don't have access to a MacOSX system that would allow me to track this down. You should find out if there are any apparent differences in the setup between the operating systems. It may necessary to run a debugger. If it's possible I'd suggest you try to see if you can use FOP 0.92beta instead. It may well be that the problem doesn't exist in that version. Otherwise, it's where the fun happens and where problems are much more likely to be solved. 0.20.5 is not maintained anymore. On 29.05.2006 17:59:44 Raphael Parree wrote: Hi, No there is no such message. I should probably also say that I am still using version 0.20.5 and not the latest from SVN. Tx., Raphael -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 29 May 2006 16:42 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException Was there a message Failed to read font metrics file... just before the exception? If yes, the NullPointerException is a consequence of that error. Maybe it's just a path which is not correct. On 29.05.2006 08:43:16 Raphael Parree wrote: Hi, I get the following error when trying to run an app on Mac X. I have successfully ran this app on Linux and Windows. I did see a posting back in 2003 with the same problem, but no apparent solution. The fonts I use are Verdana and Arial (bold, italic etc). The TTF files originate from a Windows XP machine (which do work on Redhat). snip/ Jeremias Maerki - 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: LazyFont NullPointerException
The extension performs syntax checking and color highlighting of various languages (JAVA, JSP, HTML, XML, SQL, HQL, EJBQL etc). It does not generate SVG, but produces FO where it changes the font attributes. It extends the FObj and relies on the layout method to call an addText method for each token. I can't recall from which example I obtained the skeleton code (especially the addText method). Do you think it will be an easy transition? I have been postponing the move, but am aware that one day I will have to make it ;) -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 12:40 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException The extension API has been stable for a while. A few months ago I've added some additional gadgets I needed for Barcode4J. I don't expect any major changes anymore. Backwards-incompatible changes are highly unlikely, but no guarantees. So far, there's no documentation for writing extensions. I usually point people at Barcode4J as the prime example. :-) The examples directory in the distribution (MathML and plan extensions) can also help. The migration shouldn't be too difficult. A few things have changed but most of your custom code can stay the same. I'm pretty confident that you can do the migration in 2 or 3 hours max if your extension simply generates SVG. Now, I'm curious: What kind of extensions did you implement? On 30.05.2006 11:57:13 Raphael Parree wrote: Hi, I would like to move to 0.92beta, but have so far been reluctant to make the move due to the FOP extension we have written. Is it safe to start porting the extensions (IOW is the extension API stable?). Is there documentation available on writing extensions for the new release (or even better on how to migrate your extensions?) Jeremias Maerki - 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: LazyFont NullPointerException
That sounds almost too easy to be true... I am hitting my head on the table why I never thought of leaving the FOP extension path and thought of pre processing with a SAX parser... I guess at the time (which is a long time ago) we had restricting requirements (just trying to convince myself). Tx for the eye opener!! My XML has -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 13:27 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException Frankly, migrating this kind of extension could be a problem. But I'm not sure. At any rate, there's no layout() method anymore and the FO tree itself had a few changes, too. If I were you I wouldn't implement something like that as a FOP extension but as a generic, SAX-based pre-processor which is independent of the FO processor. That would make the thing much more versatile. On 30.05.2006 13:13:16 Raphael Parree wrote: The extension performs syntax checking and color highlighting of various languages (JAVA, JSP, HTML, XML, SQL, HQL, EJBQL etc). It does not generate SVG, but produces FO where it changes the font attributes. It extends the FObj and relies on the layout method to call an addText method for each token. I can't recall from which example I obtained the skeleton code (especially the addText method). Do you think it will be an easy transition? I have been postponing the move, but am aware that one day I will have to make it ;) -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 30 May 2006 12:40 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException The extension API has been stable for a while. A few months ago I've added some additional gadgets I needed for Barcode4J. I don't expect any major changes anymore. Backwards-incompatible changes are highly unlikely, but no guarantees. So far, there's no documentation for writing extensions. I usually point people at Barcode4J as the prime example. :-) The examples directory in the distribution (MathML and plan extensions) can also help. The migration shouldn't be too difficult. A few things have changed but most of your custom code can stay the same. I'm pretty confident that you can do the migration in 2 or 3 hours max if your extension simply generates SVG. Now, I'm curious: What kind of extensions did you implement? On 30.05.2006 11:57:13 Raphael Parree wrote: Hi, I would like to move to 0.92beta, but have so far been reluctant to make the move due to the FOP extension we have written. Is it safe to start porting the extensions (IOW is the extension API stable?). Is there documentation available on writing extensions for the new release (or even better on how to migrate your extensions?) Jeremias Maerki - 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] Jeremias Maerki - 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]
LazyFont NullPointerException
Hi, I get the following error when trying to run an app on Mac X. I have successfully ran this app on Linux and Windows. I did see a posting back in 2003 with the same problem, but no apparent solution. The fonts I use are Verdana and Arial (bold, italic etc). The TTF files originate from a Windows XP machine (which do work on Redhat). Tx., Raphael javax.xml.transform.TransformerException: java.lang.NullPointerException at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Transform erImpl.java:2341) at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Transformer Impl.java:2202) at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.j ava:1276) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java: 673) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java: 1192) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java: 1170) at trivera.xmlcw.tools.dao.transformation.file.TransformationImpl.transForm(Tra nsformationImpl.java:88) at trivera.xmlcw.swing.controller.TransformationController.transformPart(Transf ormationController.java:135) at trivera.xmlcw.swing.controller.TransformationController.makePart(Transformat ionController.java:115) at trivera.xmlcw.swing.controller.TransformationController.transform(Transforma tionController.java:93) at trivera.xmlcw.swing.controller.TransformationController.run(TransformationCo ntroller.java:82) Caused by: java.lang.NullPointerException at org.apache.fop.render.pdf.fonts.LazyFont.getAscender(LazyFont.java:127) at org.apache.fop.layout.FontState.getAscender(FontState.java:143) at org.apache.fop.layout.LineArea.init(LineArea.java:326) at org.apache.fop.layout.BlockArea.getCurrentLineArea(BlockArea.java:164) at org.apache.fop.fo.FOText.addRealText(FOText.java:263) at org.apache.fop.fo.FOText.addText(FOText.java:252) at org.apache.fop.fo.FOText.layout(FOText.java:161) at org.apache.fop.fo.flow.Block.layout(Block.java:257) at org.apache.fop.fo.flow.Block.layout(Block.java:257) at org.apache.fop.fo.flow.AbstractFlow.layout(AbstractFlow.java:154) at org.apache.fop.fo.flow.AbstractFlow.layout(AbstractFlow.java:110) at org.apache.fop.fo.pagination.PageSequence.makePage(PageSequence.java:400) at org.apache.fop.fo.pagination.PageSequence.format(PageSequence.java:338) at org.apache.fop.apps.StreamRenderer.render(StreamRenderer.java:262) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:223) at org.apache.xml.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:26 2) at org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java: 707) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Transform erImpl.java:2336) ... 10 more - java.lang.NullPointerException at org.apache.fop.render.pdf.fonts.LazyFont.getAscender(LazyFont.java:127) at org.apache.fop.layout.FontState.getAscender(FontState.java:143) at org.apache.fop.layout.LineArea.init(LineArea.java:326) at org.apache.fop.layout.BlockArea.getCurrentLineArea(BlockArea.java:164) at org.apache.fop.fo.FOText.addRealText(FOText.java:263) at org.apache.fop.fo.FOText.addText(FOText.java:252) at org.apache.fop.fo.FOText.layout(FOText.java:161) at org.apache.fop.fo.flow.Block.layout(Block.java:257) at org.apache.fop.fo.flow.Block.layout(Block.java:257) at org.apache.fop.fo.flow.AbstractFlow.layout(AbstractFlow.java:154) at org.apache.fop.fo.flow.AbstractFlow.layout(AbstractFlow.java:110) at org.apache.fop.fo.pagination.PageSequence.makePage(PageSequence.java:400) at org.apache.fop.fo.pagination.PageSequence.format(PageSequence.java:338) at org.apache.fop.apps.StreamRenderer.render(StreamRenderer.java:262) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:223) at org.apache.xml.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:26 2) at org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java: 707) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Transform erImpl.java:2336) at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Transformer Impl.java:2202) at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.j ava:1276) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java: 673) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java: 1192) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java: 1170) at
RE: LazyFont NullPointerException
Hi, No there is no such message. I should probably also say that I am still using version 0.20.5 and not the latest from SVN. Tx., Raphael -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 29 May 2006 16:42 To: fop-users@xmlgraphics.apache.org Subject: Re: LazyFont NullPointerException Was there a message Failed to read font metrics file... just before the exception? If yes, the NullPointerException is a consequence of that error. Maybe it's just a path which is not correct. On 29.05.2006 08:43:16 Raphael Parree wrote: Hi, I get the following error when trying to run an app on Mac X. I have successfully ran this app on Linux and Windows. I did see a posting back in 2003 with the same problem, but no apparent solution. The fonts I use are Verdana and Arial (bold, italic etc). The TTF files originate from a Windows XP machine (which do work on Redhat). Tx., Raphael javax.xml.transform.TransformerException: java.lang.NullPointerException at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Transform erImpl.java:2341) at org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(Transformer Impl.java:2202) at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.j ava:1276) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java: 673) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java: 1192) at org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java: 1170) at trivera.xmlcw.tools.dao.transformation.file.TransformationImpl.transForm(Tra nsformationImpl.java:88) at trivera.xmlcw.swing.controller.TransformationController.transformPart(Transf ormationController.java:135) at trivera.xmlcw.swing.controller.TransformationController.makePart(Transformat ionController.java:115) at trivera.xmlcw.swing.controller.TransformationController.transform(Transforma tionController.java:93) at trivera.xmlcw.swing.controller.TransformationController.run(TransformationCo ntroller.java:82) Caused by: java.lang.NullPointerException at org.apache.fop.render.pdf.fonts.LazyFont.getAscender(LazyFont.java:127) at org.apache.fop.layout.FontState.getAscender(FontState.java:143) at org.apache.fop.layout.LineArea.init(LineArea.java:326) at org.apache.fop.layout.BlockArea.getCurrentLineArea(BlockArea.java:164) at org.apache.fop.fo.FOText.addRealText(FOText.java:263) at org.apache.fop.fo.FOText.addText(FOText.java:252) at org.apache.fop.fo.FOText.layout(FOText.java:161) at org.apache.fop.fo.flow.Block.layout(Block.java:257) at org.apache.fop.fo.flow.Block.layout(Block.java:257) at org.apache.fop.fo.flow.AbstractFlow.layout(AbstractFlow.java:154) at org.apache.fop.fo.flow.AbstractFlow.layout(AbstractFlow.java:110) at org.apache.fop.fo.pagination.PageSequence.makePage(PageSequence.java:400) at org.apache.fop.fo.pagination.PageSequence.format(PageSequence.java:338) at org.apache.fop.apps.StreamRenderer.render(StreamRenderer.java:262) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:223) at org.apache.xml.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:26 2) at org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java: 707) at org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(Transform erImpl.java:2336) ... 10 more - java.lang.NullPointerException at org.apache.fop.render.pdf.fonts.LazyFont.getAscender(LazyFont.java:127) at org.apache.fop.layout.FontState.getAscender(FontState.java:143) at org.apache.fop.layout.LineArea.init(LineArea.java:326) at org.apache.fop.layout.BlockArea.getCurrentLineArea(BlockArea.java:164) at org.apache.fop.fo.FOText.addRealText(FOText.java:263) at org.apache.fop.fo.FOText.addText(FOText.java:252) at org.apache.fop.fo.FOText.layout(FOText.java:161) at org.apache.fop.fo.flow.Block.layout(Block.java:257) at org.apache.fop.fo.flow.Block.layout(Block.java:257) at org.apache.fop.fo.flow.AbstractFlow.layout(AbstractFlow.java:154) at org.apache.fop.fo.flow.AbstractFlow.layout(AbstractFlow.java:110) at org.apache.fop.fo.pagination.PageSequence.makePage(PageSequence.java:400) at org.apache.fop.fo.pagination.PageSequence.format(PageSequence.java:338) at org.apache.fop.apps.StreamRenderer.render(StreamRenderer.java:262) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:223) at org.apache.xml.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:26 2) at org.apache.xalan.templates.ElemLiteralResult.execute
