Re: Withdrawal of PMC nomination
Glen Mazza wrote: --- Peter B. West [EMAIL PROTECTED] wrote: Jeremias' ideas about factoring out useful stand-alone elements from the combination of FOP and Batik are essential to the direction I am taking with layout and rendering, aside from being a Good Thing in their own right. Yes, I've pulled about 8 methods from the Renderer interface so far, giving Renderer implementors a little more freedom in how they choose to implement one. Also, I removed direct FOTreeBuilder.addElementMapping() methods which should HEAD a little bit more FAD-friendly (FAD, of course, doesn't have element mappings). The external user sets them in FOUserAgent instead, and HEAD's FOTreeBuilder reads from the FOUserAgent object to obtain them. The FAD version of an FOTreeBuilder would simply ignore this setting. This doesn't mean I'm trying to move to FAD's pull parsing--I'm not-- Shucks. but if I can increase the number of components you can use, so much the better. (To that end, notice the one-line of code in getDefaultHandler() in Driver that initializes FOTreeBuilder. If FAD's FOTreeBuilder equivalent can work with these arguments--a render type, output stream, FOUserAgent object--great! That would mean fop.apps package can be the same between two systems.) I think there are some possibilities here. A lot of what you are doing seems kindred (in spirit, at least) with Victor's approach. I'll take whatever I can get from FOP for FAD, and the more commonality the better. But there is a fundamental difference in approach to XML events in pull parsing, which liberates application processing to a degree which I don't think is appreciated by habituated SAX users. In FAD the scope of XML parsing is entirely circumscribed by the parser thread, which runs on-demand. All of the requirements for inputs, transformations, etc, are the same, because I am using SAX under the hood. But when a native pull parser comes along, say as a result of Andy Clark's work with NekoPull http://www.apache.org/~andyc/neko/doc/pull/index.html, XmlPull http://www.xmlpull.org/, JSR173 Streaming API for XML http://jcp.org/en/jsr/detail?id=173, or the WebLogic XML Streaming API http://e-docs.bea.com/wls/docs70/xml/xml_stream.html, I will happily ditch SAX. Whether the Streaming API will be JAXP compliant is a moot point. If not, it is another wedge between FOP and FAD. In general, I'm trying to move away from supporting direct manipulation of internal objects from external users: e.g., AreaTree.setWidget(), etc. and instead am placing the customization in FOUserAgent (or the xml configuration file, perhaps) for the internal objects to read. That way if an alternative implementation has nothing to do with widgets, it can simply ignore the setting in FOUserAgent without being forced to implement an architecture-breaking setWidget(). This also gives future implementors ability to completely revamp things internally without worrying about the API. The layout engine that I'm currently working on looks as though it will have three threads - a parser thread (which will disappear in a streaming parser), a layout engine and a renderer. Press button=Repeat The Area tree is built in lockstep with the FO tree. An area may provide the context for the resolution of properties on the descendants of the FO that generated that area. The integration is that tight. Furthermore, page layout begins with the start tag of a page-sequence fo:flow, not the end-tag. It is pull parsing that makes this feasible, and makes possible the solution of FOP's most critical problem - memory. It doesn't matter how long the page sequence is in FAD. /Press An API which is to accommodate both FOP and FAD must be able to span such fundamental differences. Incidentally, IIUC, the above is not to do with eager layout. That was a property of layout strategies, concerning how much *layout* context was examined before a final layout decision was taken. In my understanding, it related to the ability to adjust layout across multiple paragraphs or pages in order to find a better quality solution, as opposed to making those decisions based only on local layout information. The same decisions must be made in FAD. However, the first order of business for FAD is to get basic layout working, then demonstrate multi-columns with footnotes, marker processing with inheritance from static-content, floats, keeps, and last-page processing, in no particular order. Peter -- Peter B. West http://cv.pbw.id.au/
Re: Withdrawal of PMC nomination
Thanks for the elaboration--also the links to the pull parsing sites. Glen --- Peter B. West [EMAIL PROTECTED] wrote: All of the requirements for inputs, transformations, etc, are the same, because I am using SAX under the hood. But when a native pull parser comes along, say as a result of Andy Clark's work with NekoPull http://www.apache.org/~andyc/neko/doc/pull/index.html, XmlPull http://www.xmlpull.org/, JSR173 Streaming API for XML http://jcp.org/en/jsr/detail?id=173, or the WebLogic XML Streaming API http://e-docs.bea.com/wls/docs70/xml/xml_stream.html, I will happily ditch SAX. Whether the Streaming API will be JAXP compliant is a moot point. If not, it is another wedge between FOP and FAD.
Re: Withdrawal of PMC nomination
--- Peter B. West [EMAIL PROTECTED] wrote: Jeremias' ideas about factoring out useful stand-alone elements from the combination of FOP and Batik are essential to the direction I am taking with layout and rendering, aside from being a Good Thing in their own right. Yes, I've pulled about 8 methods from the Renderer interface so far, giving Renderer implementors a little more freedom in how they choose to implement one. Also, I removed direct FOTreeBuilder.addElementMapping() methods which should HEAD a little bit more FAD-friendly (FAD, of course, doesn't have element mappings). The external user sets them in FOUserAgent instead, and HEAD's FOTreeBuilder reads from the FOUserAgent object to obtain them. The FAD version of an FOTreeBuilder would simply ignore this setting. This doesn't mean I'm trying to move to FAD's pull parsing--I'm not--but if I can increase the number of components you can use, so much the better. (To that end, notice the one-line of code in getDefaultHandler() in Driver that initializes FOTreeBuilder. If FAD's FOTreeBuilder equivalent can work with these arguments--a render type, output stream, FOUserAgent object--great! That would mean fop.apps package can be the same between two systems.) In general, I'm trying to move away from supporting direct manipulation of internal objects from external users: e.g., AreaTree.setWidget(), etc. and instead am placing the customization in FOUserAgent (or the xml configuration file, perhaps) for the internal objects to read. That way if an alternative implementation has nothing to do with widgets, it can simply ignore the setting in FOUserAgent without being forced to implement an architecture-breaking setWidget(). This also gives future implementors ability to completely revamp things internally without worrying about the API. Glen
Re: Withdrawal of PMC nomination
Glen, I'm pleased that you think so, bit I believe it was the best course for me at the moment. Peter Glen Mazza wrote: An unfortunate decision. Glen --- Peter B. West [EMAIL PROTECTED] wrote: Fopsters, I have been discussing with Jeremias offline the appropriateness or otherwise of my being on the XML Graphics PMC. On reflection, I had some reservations, and I have decided to withdraw my nomination for the XML Graphics PMC, on the understanding that I will continue to take a keen interest in the factoring out of the graphics components. -- Peter B. West http://cv.pbw.id.au/
Re: Withdrawal of PMC nomination
Glen is not alone in his expression of that sentiment. I too think that was an unfortunate decision, and I suspect that others share it as well. Perhaps it *might* help me and others understand why you've made this decision (then again, it might not--we might still think it's an unfortunate decision... ;-)). Web Maestro Clay On Jul 22, 2004, at 5:27 AM, Peter B. West wrote: Glen, I'm pleased that you think so, bit I believe it was the best course for me at the moment. Peter Glen Mazza wrote: An unfortunate decision. Glen --- Peter B. West [EMAIL PROTECTED] wrote: Fopsters, I have been discussing with Jeremias offline the appropriateness or otherwise of my being on the XML Graphics PMC. On reflection, I had some reservations, and I have decided to withdraw my nomination for the XML Graphics PMC, on the understanding that I will continue to take a keen interest in the factoring out of the graphics components. -- Peter B. West http://cv.pbw.id.au/
Re: Withdrawal of PMC nomination
Clay, Glen, et al, I'm thinking of moving FAD development to SourceForge. My differences in approach are much more significant than Victor's, so much so that I have nothing to contribute to the discussions about details of implementation in HEAD. Like Victor, I retain an interest in seeing my ideas incorporated into FOP, and it seems that Victor's move may have opened much clearer channels of communication, without muddying the waters day-to-day. Jeremias' ideas about factoring out useful stand-alone elements from the combination of FOP and Batik are essential to the direction I am taking with layout and rendering, aside from being a Good Thing in their own right. That interest motivated my nomination for the PMC, but disguised the underlying differences concerning FOP. However, the primary business of the XML Graphics PMC, for the immediate future, will be the development of HEAD in FOP, and while I am thinking about moving, it doesn't seem to me to be appropriate to be on the PMC. Peter Clay Leeds wrote: Glen is not alone in his expression of that sentiment. I too think that was an unfortunate decision, and I suspect that others share it as well. Perhaps it *might* help me and others understand why you've made this decision (then again, it might not--we might still think it's an unfortunate decision... ;-)). -- Peter B. West http://cv.pbw.id.au/
Re: Withdrawal of PMC nomination
Peter B. West said: Clay, Glen, et al, I'm thinking of moving FAD development to SourceForge. My differences in approach are much more significant than Victor's, so much so that I have nothing to contribute to the discussions about details of implementation in HEAD. Like Victor, I retain an interest in seeing my ideas incorporated into FOP, and it seems that Victor's move may have opened much clearer channels of communication, without muddying the waters day-to-day. Jeremias' ideas about factoring out useful stand-alone elements from the combination of FOP and Batik are essential to the direction I am taking with layout and rendering, aside from being a Good Thing in their own right. That interest motivated my nomination for the PMC, but disguised the underlying differences concerning FOP. However, the primary business of the XML Graphics PMC, for the immediate future, will be the development of HEAD in FOP, and while I am thinking about moving, it doesn't seem to me to be appropriate to be on the PMC. Peter Clay Leeds wrote: Glen is not alone in his expression of that sentiment. I too think that was an unfortunate decision, and I suspect that others share it as well. Perhaps it *might* help me and others understand why you've made this decision (then again, it might not--we might still think it's an unfortunate decision... ;-)). -- Peter B. West http://cv.pbw.id.au/ Thanks for taking the time to make this clearer. I guess I would have to say It Makes Absolutely Some Sense Whatsoever(tm). Just the same, I certainly hope to hear your eloquent, knowledgeable voice chime into the discussions. Web Maestro Clay -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
Re: Withdrawal of PMC nomination
An unfortunate decision. Glen --- Peter B. West [EMAIL PROTECTED] wrote: Fopsters, I have been discussing with Jeremias offline the appropriateness or otherwise of my being on the XML Graphics PMC. On reflection, I had some reservations, and I have decided to withdraw my nomination for the XML Graphics PMC, on the understanding that I will continue to take a keen interest in the factoring out of the graphics components. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Withdrawal of PMC nomination
Fopsters, I have been discussing with Jeremias offline the appropriateness or otherwise of my being on the XML Graphics PMC. On reflection, I had some reservations, and I have decided to withdraw my nomination for the XML Graphics PMC, on the understanding that I will continue to take a keen interest in the factoring out of the graphics components. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
