RE: Sun XSL Formatter
On Sat, 2002-12-14 at 20:01, Victor Mote wrote: Peter S. Housel wrote: Looks like they want to donate it to Gnome, not Apache. AFAIR, the BSD license is pretty incompatible with the Apache license. One of the reasons that the xmlroff announcement doesn't change my commitment to FOP is that, for my interests anyway, the Apache license is superior. Others are that it is not written in Java, and only runs on Sun-supported operating systems. It almost seems like Java was bypassed because it runs on Microsoft operating systems. There are other deficiencies that I think are probable, but we won't know until we get to play with it. Personally I also consider the integration with xerces, xalan, cocoon, forrest, batik, avalon to be quite important. I definitely intend to keep plugging away at FOP. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
FOP and AreaTree serialization
Hi! I've been using FOP for Inventory reporting in PDF format. It works great with documents less that 200 pages when we have enough memory in server. We need to produce reports with pages up to 1000 pages and within one pagesequence. I would like to serialize AreaTree to filesystem to prevent server running out of memory. What is best place to start from? I've notice that sources in CVS have AreaTree subclasses: AreaTree.AreaTreeModel AreaTree.RenderPagesModel AreaTree.StorePagesModel Does these classes already provide support for areatree to-filesystem-caching during pagesequence rendering? How about latest 0.20.5rc release. Didn't find those classes there. Any help appreciated. Aki Salonen Wincor Nixdorf Oy Systems Analyst PL 160, 02601 ESPOO, Finland Visiting adress: Majurinkatu 6 (Perkkaa) ( Phone, direct: +358 10 511 5183, Switch board: +358 10 511 4040 2 Fax: +358 10 511 5502 * e-mail: mailto:[EMAIL PROTECTED] web: http://www.wincor-nixdorf.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP and AreaTree serialization
On Mon, 2002-12-16 at 14:32, Salonen, Aki wrote: Hi! I've been using FOP for Inventory reporting in PDF format. It works great with documents less that 200 pages when we have enough memory in server. We need to produce reports with pages up to 1000 pages and within one pagesequence. I would like to serialize AreaTree to filesystem to prevent server running out of memory. What is best place to start from? I've notice that sources in CVS have AreaTree subclasses: AreaTree.AreaTreeModel AreaTree.RenderPagesModel AreaTree.StorePagesModel Does these classes already provide support for areatree to-filesystem-caching during pagesequence rendering? Yes this is implemented, the CachedRenderPagesModel does it. Caching only really helps when there are forward references. All other pages are rendered and streamed out straight away. How about latest 0.20.5rc release. Didn't find those classes there. It is not implemented in the releases, this functionality is only in the development in cvs. Your help with the development would be appreciated. Any help appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP and AreaTree serialization
I am not using any forward references. I've debugged memory allocation and noticed that FOP allocates about 700Kb of memory for each page processed. This remains allocated to the end of pagesequence. If I've understood right, it's AreaTree that grows bigger and bigger. Is there any way or is it possible with current design to implement explicit clearing of already handled/rendered objects/pages from AreaTree to enable GC to collect objects that are needed no more? I am intrested for donating work for FOP to make possible processing very long pagesequences. Aki -Original Message- From: Keiron Liddle [mailto:[EMAIL PROTECTED]] Sent: 16. joulukuuta 2002 16:12 To: FOP Subject: Re: FOP and AreaTree serialization On Mon, 2002-12-16 at 14:32, Salonen, Aki wrote: Hi! I've been using FOP for Inventory reporting in PDF format. It works great with documents less that 200 pages when we have enough memory in server. We need to produce reports with pages up to 1000 pages and within one pagesequence. I would like to serialize AreaTree to filesystem to prevent server running out of memory. What is best place to start from? I've notice that sources in CVS have AreaTree subclasses: AreaTree.AreaTreeModel AreaTree.RenderPagesModel AreaTree.StorePagesModel Does these classes already provide support for areatree to-filesystem-caching during pagesequence rendering? Yes this is implemented, the CachedRenderPagesModel does it. Caching only really helps when there are forward references. All other pages are rendered and streamed out straight away. How about latest 0.20.5rc release. Didn't find those classes there. It is not implemented in the releases, this functionality is only in the development in cvs. Your help with the development would be appreciated. Any help appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP and AreaTree serialization
On Mon, 2002-12-16 at 15:52, Salonen, Aki wrote: I am not using any forward references. I've debugged memory allocation and noticed that FOP allocates about 700Kb of memory for each page processed. This remains allocated to the end of pagesequence. If I've understood right, it's AreaTree that grows bigger and bigger. I think it is more likely a combination of the area tree, renderer and things in the fo tree. Is there any way or is it possible with current design to implement explicit clearing of already handled/rendered objects/pages from AreaTree to enable GC to collect objects that are needed no more? Not really. That is the whole idea of the current development, to make these sort of things work better. I am intrested for donating work for FOP to make possible processing very long pagesequences. That would be great. Aki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Sun XSL Formatter
Arved Sandstrom wrote at 14 Dec 2002 15:05:05 -0400: No bitterness at all, actually, Peter. It takes a bit of wind out of my sails, sure, since xmlroff is so similar to the project that Eric Bischoff and myself were working on. Tony has certainly been aware of that for quite a long time - I don't understand why the secrecy, myself, seeing as how we are now looking at an OSS donation anyway. Sun policy, not personal policy. I assure you that there are many steps, and many signatures, required when a large corporation makes an open source donation. Purely because it is a large corporation making the donation and not an individual contributor, there is a lot of due diligence to be done. If a project can't pass all the criteria, it won't be made public. Since a project intended for open souce may not make it to open source, it is perhaps better to say nothing until the due diligence is completed (or, in this case, very nearly completed). The alternative -- announcing an intention to make a public source donation -- risks the project not passing the criteria and risks later accusations of vapourware or accusations of lack of commitment to open source when the project can't be made public. That's why I couldn't say anything about the formatter in the lead up to XML 2002: any of a number of people -- not just engineers and engineering managers -- could have vetoed the donation for any of a number of reasons, and I would have just had to withdraw from the conference without another word being said. I'd be bitter if I were so arrogant as to think of myself as being upstaged. :-) That's not the case. I am quite familiar with the spec, and there are now a number of competing efforts. None of which are quite accurate. So there is room for more competition. Alternatively, I may talk to Tony and Eric and see if we can assist. Part of why it is written in C is so it doesn't compete with FOP for developers. Arved took the wind out of my sails for a while when he announced his SourceForge project, so wind taking runs both ways. I would be pleased if Arved and/or Eric would consider assisting with the project. Frankly, I would be pleased if *anybody* assisted with the project, but Arved and Eric would be a bonus. Regards, Tony Graham XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3x(70)19708 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15409] New: - bitmap images appear with vertical displacement in PS renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15409. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15409 bitmap images appear with vertical displacement in PS renderer Summary: bitmap images appear with vertical displacement in PS renderer Product: Fop Version: 0.20.5 Platform: All OS/Version: Other Status: NEW Severity: Major Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In the PostScript renderer, bitmap images such as GIFs appear vertically displaced. The offset is identical to the image's height. Here's the fix (subtracting the height is the main thing, but I think adjusting the current position is also necessary according to the renderer's logic): diff ./PSRenderer.java /local/archive/apache/fop/orig/fop-0.20.5rc/src/org/apache/fop/render/ps/PSRenderer.java 638a638 int y = this.currentYPosition + ploffset; 641,642c641,642 int y = this.currentYPosition + ploffset - h; this.currentYPosition -= h; --- //this.currentYPosition -= h; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Comment on Bug#15409 regarding 0.20.5 ship
Hi folks, I just sent a bugreport including a fix for the PostScript renderer. The reason for commenting it here is that I think the fix should go into the 0.20.5 release (the fix is for 0.20.5RC download, not CVS). I was using the PDF renderer so far but am now using the PS renderer in addition because I needed some job option stuff that could not be done with PDF. All of my production files didn't work without the fix and now render correctly. Still, I find it somewhat dubious that the code in there uses area.getContentWidth() for the width but area.getHeight() (instead of getContentHeight()) for the height. I don't know the FOP area stuff well enough to decide whether that's a problem. Thanks for any idea on this, Arnd Beissner -- Cappelino Informationstechnologie GmbH Arnd Beißner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/apps InputHandler.java
olegt 2002/12/16 14:01:43
Modified:src/org/apache/fop/apps InputHandler.java
Log:
Modified to use SAXParserFactory instead of loading class by name.
Revision ChangesPath
1.9 +17 -26xml-fop/src/org/apache/fop/apps/InputHandler.java
Index: InputHandler.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/apps/InputHandler.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- InputHandler.java 25 Oct 2002 09:29:39 - 1.8
+++ InputHandler.java 16 Dec 2002 22:01:43 - 1.9
@@ -10,27 +10,27 @@
// SAX
import org.xml.sax.InputSource;
import org.xml.sax.XMLReader;
+import org.xml.sax.SAXException;
// Java
+import javax.xml.parsers.SAXParserFactory;
+import javax.xml.parsers.ParserConfigurationException;
import java.net.URL;
import java.io.File;
public abstract class InputHandler {
-
public abstract InputSource getInputSource();
public abstract XMLReader getParser() throws FOPException;
-
public static InputSource urlInputSource(URL url) {
return new InputSource(url.toString());
}
/**
- * create an InputSource from a File
- *
- * @param file the File
- * @return the InputSource created
+ * Creates an codeInputSource/code from a codeFile/code
+ * @param file the codeFile/code
+ * @return the codeInputSource/code created
*/
public static InputSource fileInputSource(File file) {
/* this code adapted from James Clark's in XT */
@@ -50,29 +50,20 @@
}
/**
- * creates a SAX parser, using the value of org.xml.sax.parser
- * defaulting to org.apache.xerces.parsers.SAXParser
- *
- * @return the created SAX parser
+ * Creates codeXMLReader/code object using default
+ * codeSAXParserFactory/code
+ * @return the created codeXMLReader/code
*/
protected static XMLReader createParser() throws FOPException {
-String parserClassName = Driver.getParserClassName();
-//log.debug(using SAX parser + parserClassName);
-
try {
-return (XMLReader)Class.forName(parserClassName).newInstance();
-} catch (ClassNotFoundException e) {
-throw new FOPException(e);
-} catch (InstantiationException e) {
-throw new FOPException(Could not instantiate
- + parserClassName, e);
-} catch (IllegalAccessException e) {
-throw new FOPException(Could not access + parserClassName, e);
-} catch (ClassCastException e) {
-throw new FOPException(parserClassName + is not a SAX driver,
- e);
+SAXParserFactory factory = SAXParserFactory.newInstance();
+factory.setNamespaceAware(true);
+return factory.newSAXParser().getXMLReader();
+} catch (SAXException se) {
+throw new FOPException(Coudn't create XMLReader, se);
+} catch (ParserConfigurationException pce) {
+throw new FOPException(Coudn't create XMLReader, pce);
}
}
-
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo FOTreeBuilder.java
olegt 2002/12/16 15:27:15
Modified:src/org/apache/fop/fo FOTreeBuilder.java
Log:
Removed unused imports, cleaned up style, logging and javadoc. Removed redundant
unknown fo collection.
Revision ChangesPath
1.41 +26 -39xml-fop/src/org/apache/fop/fo/FOTreeBuilder.java
Index: FOTreeBuilder.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/FOTreeBuilder.java,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- FOTreeBuilder.java14 Aug 2002 14:25:18 - 1.40
+++ FOTreeBuilder.java16 Dec 2002 23:27:15 - 1.41
@@ -10,9 +10,6 @@
// FOP
import org.apache.fop.apps.FOPException;
import org.apache.fop.apps.StructureHandler;
-import org.apache.fop.fo.pagination.Root;
-import org.apache.fop.fo.pagination.PageSequence;
-import org.apache.fop.extensions.ExtensionObj;
// Avalon
import org.apache.avalon.framework.logger.Logger;
@@ -20,13 +17,10 @@
// SAX
import org.xml.sax.helpers.DefaultHandler;
import org.xml.sax.SAXException;
-import org.xml.sax.InputSource;
import org.xml.sax.Attributes;
// Java
-import java.util.HashMap;
-import java.util.ArrayList;
-import java.io.IOException;
+import java.util.*;
/**
* SAX Handler that builds the formatting object tree.
@@ -42,34 +36,32 @@
public class FOTreeBuilder extends DefaultHandler {
/**
- * table mapping element names to the makers of objects
- * representing formatting objects
+ * Table mapping element names to the makers of objects
+ * representing formatting objects.
*/
-protected HashMap fobjTable = new HashMap();
-
-protected ArrayList namespaces = new ArrayList();
+protected Map fobjTable = new HashMap();
/**
- * current formatting object being handled
+ * Set of mapped namespaces.
*/
-protected FONode currentFObj = null;
+protected Set namespaces = new HashSet();
/**
- * the root of the formatting object tree
+ * Current formatting object being handled
*/
-protected FObj rootFObj = null;
+protected FONode currentFObj = null;
/**
- * set of names of formatting objects encountered but unknown
+ * The root of the formatting object tree
*/
-protected HashMap unknownFOs = new HashMap();
+protected FONode rootFObj = null;
/**
- *
* The class that handles formatting and rendering to a stream
* ([EMAIL PROTECTED])
*/
private StructureHandler structHandler;
+
private FOUserAgent userAgent;
public FOTreeBuilder() {}
@@ -86,17 +78,15 @@
return userAgent;
}
-
public void setStructHandler(StructureHandler sh) {
this.structHandler = sh;
}
/**
- * add a mapping from element name to maker.
+ * Adds a mapping from a namespace to a table of makers.
*
- * @param namespaceURI namespace URI of formatting object element
- * @param localName local name of formatting object element
- * @param maker Maker for class representing formatting object
+ * @param namespaceURI namespace URI of formatting object elements
+ * @param table table of makers
*/
public void addMapping(String namespaceURI, HashMap table) {
this.fobjTable.put(namespaceURI, table);
@@ -118,7 +108,6 @@
public void endElement(String uri, String localName, String rawName)
throws SAXException {
currentFObj.end();
-
currentFObj = currentFObj.getParent();
}
@@ -128,13 +117,18 @@
public void startDocument()
throws SAXException {
rootFObj = null;// allows FOTreeBuilder to be reused
-getLogger().debug(building formatting object tree);
+if (getLogger().isDebugEnabled())
+getLogger().debug(Building formatting object tree);
structHandler.startDocument();
}
+/**
+ * SAX Handler for the end of the document
+ */
public void endDocument()
throws SAXException {
-getLogger().debug(Parsing of document complete);
+if (getLogger().isDebugEnabled())
+getLogger().debug(Parsing of document complete);
structHandler.endDocument();
}
@@ -149,7 +143,7 @@
/* the maker for the formatting object started */
ElementMapping.Maker fobjMaker = null;
-HashMap table = (HashMap)fobjTable.get(uri);
+Map table = (Map)fobjTable.get(uri);
if(table != null) {
fobjMaker = (ElementMapping.Maker)table.get(localName);
// try default
@@ -158,20 +152,14 @@
}
}
-boolean foreignXML
