RE: hack to avoid memory overflow with tables
Jeremias Maerki wrote: I'm slowly getting the impression it may be better if we really totally modularize FOP (splitting it up into several independently usable subprojects) so development is only split in the layout field which is the major problem-child here. But that alone would take long enough and I can't even imagine how much it will hurt the redesign. You're on the right track, but I don't know that we need separate subprojects. I am just starting to implement an idea that I have been kicking around for several weeks. I want to create a LayoutStrategy that is either abstract or an interface, and which can be subclassed/implemented by each concrete strategy. We currently have two -- one in the redesign branch, and one in the maintenance branch. The goal would be to eventually drop the maintenance branch layout system into the redesign code as an implementation of LayoutStrategy. It will always be a deficient implementation, but right now it is the best one that we have (else we would be releasing code from the trunk). This would allow us to start releasing code from the trunk, and would unify our efforts in infrastructure, control, FO Tree, Area Tree, etc. This is something we really should do eventually anyway, and IMO it is better to do sooner than later. There are three issues: 1) Some will not like this approach as it seems to draw resources away from the redesign. I'll not reargue this issue again now unless it is needed. In short, nothing is being done on redesign now, so how can it possibly be hurt by anything? Also, eliminating thrashing between two branches will help all of us find resources to work on layout redesign. 2) Some will think that bringing the maintenance branch layout into the redesign will reintroduce the maintenance branch problems. Obviously, this should be avoided, and I think it can be. There are no doubt methods and data which will need to be moved around to get the maintenance branch layout modularized, but it seems possible. 3) It would be helpful to resolve some of our high-level control issues before starting down this path, or at least as part of this project. Moving control of when layout is started, when FO trees are destroyed, etc. up to higher-level objects will be extremely helpful in isolating these subsystems from each other and allowing multiple layout strategies. I see the sequence as follows: 1. Resolve design of, then implement the high-level control changes. This is the Session / Document / Rendering Context issue discussed on the Avalonization wiki, section entitled Startup Concepts Proposal at http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization 2. Isolate the (existing redesign) layout by forcing all contact with the layout systems to run through the LayoutStrategy. Every layout class except the Stategy implementation becomes non-public (I think). 3. Drop in the maintenance branch layout as an implementation of LayoutStrategy, keeping it isolated as well. Even if this effort is unsuccessful for some reason, or the redesign layout is completed before this can be done, steps one and two above are still needed useful. I really didn't want to mention any of this until it was done, but I wanted to encourage Jeremias' train of thought. Also, coming to an agreement on steps one and two, and completing them, makes step three much easier. If we can reach a consensus on items 1 and 2, I'll start on them right away. I don't think they are big tasks, but they are pervasive and design-oriented, and I think they require your approval. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
A couple of FAQ items
XSL FAQ: The XSL FAQ link is incorrect. It is currently: http://dpawson.co.uk/xsl/ showing the directory contents of Index of xsl/... It should be: http://dpawson.co.uk/xsl/xslfaq.html HYPHENATION INFO: 3.9. Hyphenation does not work. Set the language attribute somewhere. Check whether you use a language for which hyphenation is supported. Supported languages can be deduced from the files in the hyph directory of the FOP source distribution. Adding examples of how to add hyphenation would limit the number of questions fop-user (perhaps something like this--or whatever might work): fo:root lang=pt Also, to determine the included hyphenation patterns in FOP, one currently has to download the Source distribution and look in the hyph directory (at the very least, it would be better to indicate hyph/ directory). Even better would be to indicate which languages are included. Also, this would be a good place to indicate where one might find links to hyphenation patterns which do work (or provide a link to the Resources page where there might be links to other hyph patterns--and also info on how to convert, say TeX patterns to FOP-usable ones). (NOTE: I understand there are problems with including copyrighted hyphenation patterns in the FOP distribution, but aren't there patterns for which people may download patterns but their licenses simply do not allow them to be included in Apache stuff?). ;-p -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com PGP Public Key: https://mail.medata.com/pgp/cleeds.asc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Error printing from servlet
Hi All, I was using the attached servlet(based in example supplied with FOP) to print some reports. It was running OK with Tomcat, but when i changed my aplication server to Oracle 9IAS, it is not working anymore. The printer is already configured in the server. Does somebodyknow what is the problem? Thanks, Paulo Benfatti The error generated is: 500 Internal Server Errororg.apache.fop.apps.FOPException: Unable to print: java.awt.print.PrinterException: No printer found. at org.apache.fop.apps.Driver.render(Driver.java:462) at org.apache.fop.apps.Driver.run(Driver.java:524) at FopPrintServlet.renderFO(Unknown Source) at FopPrintServlet.doGet(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65) at oracle.security.jazn.oc4j.JAZNFilter.doFilter(JAZNFilter.java:283) at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:560) at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:306) at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:767) at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.AJPRequestHandler.run(AJPRequestHandler.java:148) at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.AJPRequestHandler.run(AJPRequestHandler.java:72) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:803) at java.lang.Thread.run(Thread.java:479) - java.io.IOException: Unable to print: java.awt.print.PrinterException: No printer found. at org.apache.fop.apps.StreamRenderer.stopRenderer(StreamRenderer.java:157) at org.apache.fop.fo.FOTreeBuilder.endDocument(FOTreeBuilder.java:200) at oracle.xml.parser.v2.NonValidatingParser.parseDocument(NonValidatingParser.java:269) at oracle.xml.parser.v2.XMLParser.parse(XMLParser.java:147) at org.apache.fop.apps.Driver.render(Driver.java:457) at org.apache.fop.apps.Driver.run(Driver.java:524) at FopPrintServlet.renderFO(Unknown Source) at FopPrintServlet.doGet(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65) at oracle.security.jazn.oc4j.JAZNFilter.doFilter(JAZNFilter.java:283) at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:560) at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:306) at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:767) at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.AJPRequestHandler.run(AJPRequestHandler.java:148) at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.AJPRequestHandler.run(AJPRequestHandler.java:72) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:803) at java.lang.Thread.run(Thread.java:479) java.io.IOException: Unable to print: java.awt.print.PrinterException: No printer found. at FopPrintServlet$PrintRenderer.stopRenderer(Unknown Source) at org.apache.fop.apps.StreamRenderer.stopRenderer(StreamRenderer.java:152) at org.apache.fop.fo.FOTreeBuilder.endDocument(FOTreeBuilder.java:200) at oracle.xml.parser.v2.NonValidatingParser.parseDocument(NonValidatingParser.java:269) at oracle.xml.parser.v2.XMLParser.parse(XMLParser.java:147) at org.apache.fop.apps.Driver.render(Driver.java:457) at org.apache.fop.apps.Driver.run(Driver.java:524) at FopPrintServlet.renderFO(Unknown Source) at FopPrintServlet.doGet(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65) at oracle.security.jazn.oc4j.JAZNFilter.doFilter(JAZNFilter.java:283) at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:560) at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:306) at com.evermind[Oracle9iAS (9.0.3.0.0) Containers for J2EE].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:767) at com.evermind[Oracle9iAS (9.0.3.0.0) Containers
cvs commit: xml-fop/src/documentation/content/xdocs configuration.xml
vmote 2003/05/27 10:55:56 Modified:src/documentation/content/xdocs configuration.xml Log: Add section ids. Revision ChangesPath 1.4 +2 -2 xml-fop/src/documentation/content/xdocs/configuration.xml Index: configuration.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/configuration.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- configuration.xml 15 Jan 2003 13:56:17 - 1.3 +++ configuration.xml 27 May 2003 17:55:55 - 1.4 @@ -8,7 +8,7 @@ /header body - section + section id=general titleHow to configure FOP/title pIn the directory xml-fop/conf you will find two configuration files. One of them, config.xml, is only intended for FOP developers, who want to add new default values @@ -23,7 +23,7 @@ or link href=embedding.htmlEmbedding FOP/link for details. /p /section - section + section id=hyphenation titleSetting up hyphenation/title pFOP comes already with some hyphenation pattern. If you need a hyphenation pattern which isn't included in the distribution, do the following: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Team page
I have been wanting for several days to publish the web site, but have hesitated because I am the only one who has put any background information on the new Team page. If we get at least two others to add some information, I'll publish it. Otherwise, I'll remove it from the menu until we get some more participation. Victor Mote (mailto:[EMAIL PROTECTED]) 2025 Eddington Way Colorado Springs, Colorado 80916 Voice +1 (719) 622-0650 Fax +1 (720) 293-0044 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/documentation/content/xdocs team.xml
jeremias2003/05/27 12:04:00 Modified:src/documentation/content/xdocs team.xml Log: Content for my entry mailto:; prefixes for all email adresses (for spam prevention) Added section Area of Expertise Revision ChangesPath 1.6 +183 -5xml-fop/src/documentation/content/xdocs/team.xml Index: team.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/team.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- team.xml 27 May 2003 18:05:12 - 1.5 +++ team.xml 27 May 2003 19:03:59 - 1.6 @@ -11,11 +11,15 @@ section id=commit-active titleActive Committers/title ul -li id=bdlink href=mailto:[EMAIL PROTECTED]Bertrand Delacretaz/link (BD)/li +li id=bdlink href=mailto:[EMAIL PROTECTED]Bertrand Delacr#x00E9;taz/link (BD)/li li id=cglink href=mailto:[EMAIL PROTECTED]Christian Geisert/link (CG)/li li id=kllink href=mailto:[EMAIL PROTECTED]Karen Lease/link (KL)/li li id=klllink href=mailto:[EMAIL PROTECTED]Keiron Liddle/link (KLL)/li -li id=jmlink href=mailto:[EMAIL PROTECTED]Jeremias M#x00E4;rki/link (JM)/li +li id=jmlink href=mailto:[EMAIL PROTECTED]Jeremias M#x00E4;rki/link (JM) + is a software engineer from Lucerne, Switzerland. He is currently enjoying a longer period of + independence and is having fun working on open source projects like Apache FOP. He's also + the creator of fork href=http://www.krysalis.org/barcode;Krysalis Barcode/fork. +/li li id=wvmlink href=mailto:[EMAIL PROTECTED]Victor Mote/link (WVM) is the founder and manager of jump href=http://www.outfitr.com;Enterprise Outfitters/jump, a business software company, and of jump href=http://www.portagepub.com;Portage Publications/jump, a republisher of old documents. Both are located in Colorado Springs, Colorado, USA./li li id=jplink href=mailto:[EMAIL PROTECTED]J#x00F6;rg Pietschmann/link (JP)/li li id=aslink href=mailto:[EMAIL PROTECTED]Arved Sandstrom/link (AS)/li @@ -26,10 +30,10 @@ section id=contribute-active titleActive Contributors/title ul -lilink href=[EMAIL PROTECTED]Marcelo Jaccoud Amaral/link/li +lilink href=mailto:[EMAIL PROTECTED]Marcelo Jaccoud Amaral/link/li lilink href=mailto:[EMAIL PROTECTED]Rhett Aultman/link/li -lilink href=[EMAIL PROTECTED]Clay Leeds/link/li -lilink href=[EMAIL PROTECTED]Glen Mazza/link/li +lilink href=mailto:[EMAIL PROTECTED]Clay Leeds/link/li +lilink href=mailto:[EMAIL PROTECTED]Glen Mazza/link/li lilink href=mailto:[EMAIL PROTECTED]Anton Tagunov/link/li lilink href=mailto:[EMAIL PROTECTED]Zhong (George) Yi/link/li /ul @@ -50,6 +54,180 @@ li id=eslink href=mailto:[EMAIL PROTECTED]Eric Schaeffer/link/li li id=awlink href=mailto:[EMAIL PROTECTED]Art Welch/link/li /ul +/section +section id=expertise + titleAreas of Expertise/title + table +tr + th/ + thBD /th + thCG /th + thKL /th + thKLL/th + thJM /th + thWVM/th + thJP /th + thAS /th + thOT /th + thPBW/th +/tr +tr + tdPMC representation/td + td/ + td/ + td/ + td/ + tdX/td + td/ + td/ + td/ + td/ + tdX/td +/tr +tr + tdRelease manager/td + td/ + tdX/td + td/ + td/ + td/ + td/ + td/ + td/ + td/ + td/ +/tr +tr + tdXSL-FO tree/td + td/ + td/ + td/ + tdX/td + td/ + td/ + td/ + td/ + td/ + tdX/td +/tr +tr + tdLayout/td + td/ + td/ + tdX/td + tdX/td + td/ + td/ + tdX/td + tdX/td + td/ + td/ +/tr +tr + tdFonts/td + td/ + td/ + td/ + td/ + tdX/td + td/ + td/ + td/ + td/ + td/ +/tr +tr + tdSVG/td + td/ + td/ + td/ + tdX/td + tdX/td + td/ + td/ + td/ + td/ + td/ +/tr +tr + tdJava2D (AWT)/td + td/ + td/ + td/
Re: Team page
I've just added something. I've also added a section Area of Expertise like the one in Batik. I already added some entries there, but please fill in some more as you find appropriate. On 27.05.2003 20:06:13 Victor Mote wrote: I have been wanting for several days to publish the web site, but have hesitated because I am the only one who has put any background information on the new Team page. If we get at least two others to add some information, I'll publish it. Otherwise, I'll remove it from the menu until we get some more participation. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Thoughts on design - FO property expressions
Peter B. West wrote: Basically, because there are three grammars at work. ... the bizarre syntax requirements of the Rec Hehe! Actually you know beforehand what kind of grammar you get, there is *no* need to have a unified parser. I was always amazed by the hoops the maintenance code goes through. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Team page
Put me down for whining about TRAX/XSLTInputHandler ;) --- Jeremias Maerki [EMAIL PROTECTED] wrote: I've just added something. I've also added a section Area of Expertise like the one in Batik. I already added some entries there, but please fill in some more as you find appropriate. __ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Team page
And perhaps me for complaints about infinite loops and general irritation? ;) Also, I'd prefer my email address be listed as [EMAIL PROTECTED], as I'll be transferring my devlist membership to that address soon. I'd make the changes myself, but I don't have that kind of CVS access. ;) -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 27, 2003 4:50 PM To: [EMAIL PROTECTED] Subject: Re: Team page Put me down for whining about TRAX/XSLTInputHandler ;) --- Jeremias Maerki [EMAIL PROTECTED] wrote: I've just added something. I've also added a section Area of Expertise like the one in Batik. I already added some entries there, but please fill in some more as you find appropriate. __ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com - 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: Team page
Victor, I have been looking forward to its appearance for several days now. I am keen to see my name in lights. I think it's a very good idea, and please don't be embarassed to have the first comprehensive entry. I'll add mine shortly. I note that Jeremias has joined in. Peter Victor Mote wrote: I have been wanting for several days to publish the web site, but have hesitated because I am the only one who has put any background information on the new Team page. If we get at least two others to add some information, I'll publish it. Otherwise, I'll remove it from the menu until we get some more participation. -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Thoughts on design - FO property expressions
J.Pietschmann wrote: Peter B. West wrote: Basically, because there are three grammars at work. ... the bizarre syntax requirements of the Rec Hehe! Actually you know beforehand what kind of grammar you get, there is *no* need to have a unified parser. I was always amazed by the hoops the maintenance code goes through. Alt.design has added hoops. -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20280] New: - text-align and text-align-last not compliant, but reported that way
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=20280. 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=20280 text-align and text-align-last not compliant, but reported that way Summary: text-align and text-align-last not compliant, but reported that way Product: Fop Version: 0.20.5 Platform: PC OS/Version: Windows 9x Status: NEW Severity: Normal Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm seeing this in trying to convert to PDF format, but I think it's a general issue. I'm using version 0.20.5rc3a. If I use any fo:block or fo:inline element with the text-align attribute set to outside, I get an error: [ERROR] Unknown enumerated value for property 'text-align': outside [ERROR] Error in text-align property value 'outside': org.apache.fop.fo.expr.PropertyException: No conversion defined Trying inside will produce a similar error. And text-align-last is even worse, failing also to allow left, right, and relative. Compliance for these is simply pass/fail, which should mean that they're either implemented to spec (allowing all 8 values for text-align, all 9 for text-align-last) or they're not. There's not even so much as a note in the compliance document to the effect that they're only partially supported. This should be an easy fix, but as a stopgap some note could be put into the compliance document to say that they're not fully implemented, and which values don't work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: hack to avoid memory overflow with tables
--- Victor Mote [EMAIL PROTECTED] wrote: The goal would be to eventually drop the maintenance branch layout system into the redesign code as an implementation of LayoutStrategy. It will always be a deficient implementation, but right now it is the best one that we have (else we would be releasing code from the trunk). FOP is ultimately a mathematical entity, so we should be able to avoid the matter-of-opinion conclusions that would lead to multiple layout strategies. I see FOP's goals as twofold: 1.) Generate multiple document types accurately. 2.) Generate a high number of very large documents in a very short amount of time, with high, very large, and very short taken to their mathematical limits. While there can be plenty of discussion of how best to obtain #1 and #2, once it is determined that solution A takes x seconds and solution B takes x + 2 seconds, you tend to go with solution A. So over the long term, multiple layout strategies may not be needed. Glen __ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: hack to avoid memory overflow with tables
Victor, Jeremias, Just a couple of notes on the discussion below. It is a mistake to say, because there is no great ferment of coding, that nothing is being done on the redesign of layout. I, for one, am currently giving the layout a great deal of thought, triggered in my case by the requirements of integrating the alt.design FO tree. I'm sure the Keiron is in the same boat, as are you, Jeremias and, I think, Jorg (my mailer may scramble this). While I don't denigrate any of these ongoing efforts, I am increasingly of the view that everything occurring between the reading of the fo xml and the layout of the area tree is interconnected in very nasty and intricate ways. The description of this process in the Rec (I resisted the obvious temptation here) has done many developers, including the FOP developers, a great disservice. It's this intertwining that makes me skeptical about pluggable layout. It may be feasible, but I don't see that it is feasible until we have a very good understanding of the way layout will be achieved, and a full picture of the flow of control in the first full implementation. Factoring out the high-level control is still a valuable and achievable step forward, but I'm not sure about control of when layout is started, when FO trees are destroyed. I assume that refers to the patient vs. eager layout discussion. At that level, certainly, control values can be factored out. I don't want to discourage your efforts, but I think you will need to keep these things in mind. Peter Victor Mote wrote: Jeremias Maerki wrote: I'm slowly getting the impression it may be better if we really totally modularize FOP (splitting it up into several independently usable subprojects) so development is only split in the layout field which is the major problem-child here. But that alone would take long enough and I can't even imagine how much it will hurt the redesign. ... In short, nothing is being done on redesign now, so how can it possibly be hurt by anything? ... It would be helpful to resolve some of our high-level control issues before starting down this path, or at least as part of this project. Moving control of when layout is started, when FO trees are destroyed, etc. up to higher-level objects will be extremely helpful in isolating these subsystems from each other and allowing multiple layout strategies. I see the sequence as follows: 1. Resolve design of, then implement the high-level control changes. This is the Session / Document / Rendering Context issue discussed on the Avalonization wiki, section entitled Startup Concepts Proposal at http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization 2. Isolate the (existing redesign) layout by forcing all contact with the layout systems to run through the LayoutStrategy. Every layout class except the Stategy implementation becomes non-public (I think). 3. Drop in the maintenance branch layout as an implementation of LayoutStrategy, keeping it isolated as well. Even if this effort is unsuccessful for some reason, or the redesign layout is completed before this can be done, steps one and two above are still needed useful. -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
