Re: development status
Peter B. West wrote: Convergence problems like your page 99 scenario occur in other contexts; notably the last page problem. The last page in a sequence is allowed a different page-master, but the only way to discover the last page is to lay it out. Oops, last page. Lay it out again, using the last-page-master. Oops, we now have something left over, so it's not the last page any more. These cases will have to be catalogued as discovered, and circuit-breaker heuristics provided for them. Yes, and the only way around the performance and memory issues this raises is to write FOP in a way where any forward-reference related handling is only executed if forward-references really occur. Then, if someone has large documents and doesn't care about forward references, the solution is either to: 1. manually remove the forward references in the document 2. remove the forward references using an XSLT stylesheet if the users want to toggle between a fast and a slow version. 3. implement a FOP option that ignores forward references and replaces them by a * - or whatever. Anyhow, in my opinion this is worth doing right. From my experience (which is from large-volume printing, between 5.000 and 50.000 docs per job), if someone wants forward references in a doc (even if it's only page x of y in a contract or invoice) he or she usually really wants it and doesn't care about performance or memory. If, for example, I am printing an invoice and absolute need to have page counts (like page 1 of 2) for legal reasons, then - if this gives me performance problems - I can still try to help the formatter by introducing fixed page breaks or other things that at least avoid formatting cycles after the second. Arnd Beissner -- Arnd Beißner IT-Engineering Bahnhofstr. 3, 71063 Sindelfingen, Germany Email: [EMAIL PROTECTED] Phone: +49-7031-463458 Mobile: +49-173-3016917
Re: development status
Nicola Ken Barozzi [EMAIL PROTECTED] wrote: Anyway, these forward references are a pain in the ass :-/ Very true. Imagine the worst case: Someone puts a (See page fo:page-number-citation ref-id=blurble/) into the text at page 1. The formatter has to allocate some space for the unknown number, lets say a n space. The referenced block happens to end up on page 99. The preallocated space is not sufficient, extending this space could cause reformatting of all pages, which is already bad. Furthermore, the reformatting could push the referenced block to page 100, thereby providing another problem. I have no idea how an interface able to deal with the problem above could look like. Have fun J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: development status
Joerg, You have highlighted one of the nastinesses of page formatting. A QD solution often suggested is to allow a fixed width for the page numbers, but I don't see how this can stand as a final solution. The gaps are going to be obvious in something purporting to be a high-quality rendering system, and what if you don't allow for enough digits? The spec allows a lot of local adjustment, so I think that in the vast majority of cases local re-formatting will fix the problem, and keep the adjustments within the page. However, I think also that spill effects will have to be accommodated. Convergence problems like your page 99 scenario occur in other contexts; notably the last page problem. The last page in a sequence is allowed a different page-master, but the only way to discover the last page is to lay it out. Oops, last page. Lay it out again, using the last-page-master. Oops, we now have something left over, so it's not the last page any more. These cases will have to be catalogued as discovered, and circuit-breaker heuristics provided for them. Peter Joerg Pietschmann wrote: Nicola Ken Barozzi wrote: Anyway, these forward references are a pain in the ass :-/ Very true. Imagine the worst case: Someone puts a (See page ) into the text at page 1. The formatter has to allocate some space for the unknown number, lets say a n space. The referenced block happens to end up on page 99. The preallocated space is not sufficient, extending this space could cause reformatting of all pages, which is already bad. Furthermore, the reformatting could push the referenced block to page 100, thereby providing another problem. I have no idea how an interface able to deal with the problem above could look like. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: development status
I agree with the configuration in general but not with the cocoon concept. The parts like configuration, logging, etc. could help us with the functionality and the architecture. To serialize between the Area Tree and the Renderers there are some serious problems that would get in the way: - in many cases the area tree will need to be complete before sending anything across, this defeats the whole purpose and will use a lot of memory - embedded xml will need to be parsed twice and saxified - how do we handle area tree extensions - forward references for some renderers will mean that the renderer may also need to store the whole area tree (or part thereof) on the other side of the sax events - the layout depends on the output target, for font information On 2002.03.15 16:32 Nicola Ken Barozzi wrote: What bugs me in FOP currently (the famous itch to scratch ;-) , is what drives the whole process itself. Configuration, URI resolving, logging, and so on. The infrastructure. snip When this is in place, all the infrastructure is there, and we can concentrate on the real FOP code. The problem is that the *real* FOP code significantly effects the way that the processing and caching works. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: development status
Keiron Liddle wrote: ... To serialize between the Area Tree and the Renderers there are some serious problems that would get in the way: - in many cases the area tree will need to be complete before sending anything across, this defeats the whole purpose and will use a lot of memory - embedded xml will need to be parsed twice and saxified - how do we handle area tree extensions - forward references for some renderers will mean that the renderer may also need to store the whole area tree (or part thereof) on the other side of the sax events - the layout depends on the output target, for font information Keiron, Could you sketch out the way font information is communicated to layout? I had the vague notion that the renderers were obliged to provide font information at the configuration stage. I hoped this would obviate any further communication between the layout process and the renderer. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: development status
On 2002.03.19 14:45 Nicola Ken Barozzi wrote: I would consider the possibility (configurable) of having FOP make just sensible assumptions to continue processing and sacrifice some things it should do later. That sounds very vague. So what will you do if someone has a table of contents as the second page. Will you pass across a whole lot of to be resolved things for the page numbers to the renderer, so the renderer needs to do the resolving from some further information. Will the renderer go until it reaches a to be resolved thing then need to do some awkward processing of all the following pages. It all sounds like an extra level of complexity that we really don't need. Rather than helping us it will simply make things more difficult. - embedded xml will need to be parsed twice and saxified Why twice? May need to read it to get the width and height and do some pre-processing with a DOM. ATM, I don't have a clear list of all the things that need to be held back before resolution. Is there a list somewhere? It would be of great help for me. Page references. Internal links. Retrieve Markers? Extensions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: development status
Hi Peter, The font information is obtained from the renderer at the start before building any of the area tree. There should be no further need for communication except of course in the case when handling dynamic effects (but lets not get into that right now). On 2002.03.19 13:37 Peter B. West wrote: Keiron Liddle wrote: ... To serialize between the Area Tree and the Renderers there are some serious problems that would get in the way: - in many cases the area tree will need to be complete before sending anything across, this defeats the whole purpose and will use a lot of memory - embedded xml will need to be parsed twice and saxified - how do we handle area tree extensions - forward references for some renderers will mean that the renderer may also need to store the whole area tree (or part thereof) on the other side of the sax events - the layout depends on the output target, for font information Keiron, Could you sketch out the way font information is communicated to layout? I had the vague notion that the renderers were obliged to provide font information at the configuration stage. I hoped this would obviate any further communication between the layout process and the renderer. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: development status
From: Keiron Liddle [EMAIL PROTECTED] On 2002.03.19 14:45 Nicola Ken Barozzi wrote: I would consider the possibility (configurable) of having FOP make just sensible assumptions to continue processing and sacrifice some things it should do later. That sounds very vague. So what will you do if someone has a table of contents as the second page. Will you pass across a whole lot of to be resolved things for the page numbers to the renderer, so the renderer needs to do the resolving from some further information. Will the renderer go until it reaches a to be resolved thing then need to do some awkward processing of all the following pages. I would output a ? instead of the real pages. While this is not generally acceptable, in reports, for example, these references are usually not needed. High memory consumption is *the*killer*, and it's a burden that is not needed in these cases. It all sounds like an extra level of complexity that we really don't need. Rather than helping us it will simply make things more difficult. Good point. I will keep this in mind. - embedded xml will need to be parsed twice and saxified Why twice? May need to read it to get the width and height and do some pre-processing with a DOM. It can be equally done by a sub-pipeline with SAX. But I understand that Batik is still DOM based :-( ATM, I don't have a clear list of all the things that need to be held back before resolution. Is there a list somewhere? It would be of great help for me. Since propertiy resolution is basically inherited AFAIK, it seems that what you specify is in fact what really breaks the nice SAX stuff. Page references. Yes. Internal links. May be. In HTML it's not needed since I can write an internal link (#myref) before specifying it. Retrieve Markers? IMHO yes, since you can make a forward reference with it. Extensions. Let's bypass extensions for now. So we absolutely need to stop output and cache events if there is a forward reference. If we find it at the end, all the pages must remain in memory, and now I see that this can make FOP behave no better than it does now. There are three possibilities I see: 1. Start storing the SAX events as soon as a forward reference is caught, and flush them after the resolved reference. 2. Ignore the forward references (speed property); if someone doesn't use any of the above features, there is no difference in output anyway. 3. Do the FOP processing in 2 steps. 1- Process all the stuff without the references writing to disk 2- resolve them by rereading the file This resolves memory issues but not speed. I would go for 1 and 2. If we store the SAX events before firing them, they are smaller than DOM and can be saved to a Store that can also be a disk in case of low memory. This is how Cocoon caches pages, and this is how we could cache SAX fragments that are there just to wait for a forward reference. We can also give a clear indication to users to how to optimize pages: no forward references = much less memory = higher speed. Anyway, these forward references are a pain in the ass :-/ -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: development status
On 2002.03.19 16:47 Nicola Ken Barozzi wrote: So we absolutely need to stop output and cache events if there is a forward reference. If we find it at the end, all the pages must remain in memory, and now I see that this can make FOP behave no better than it does now. Thats not true. We can do better and the current development is developing towards a way that will do better. The key is that there is a definite API between the Area Tree and the Renderers. This means that we can prepare a page and later render its contents. All following pages can be rendered if they are finished. The forward reference resolution can be done in the area tree with the help of the layout managers and then the completed page can be rendered (depends if the renderer supports out of order which pdf does). If the memory gets low then a page can be stored to disk and retrieved when forward references are resolved. Without needing to handle this on two sides of the fence it is more straight forward and flexible. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: development status
From: Keiron Liddle [EMAIL PROTECTED] On 2002.03.19 16:47 Nicola Ken Barozzi wrote: So we absolutely need to stop output and cache events if there is a forward reference. If we find it at the end, all the pages must remain in memory, and now I see that this can make FOP behave no better than it does now. Thats not true. We can do better and the current development is developing towards a way that will do better. The key is that there is a definite API between the Area Tree and the Renderers. This means that we can prepare a page and later render its contents. All following pages can be rendered if they are finished. The forward reference resolution can be done in the area tree with the help of the layout managers and then the completed page can be rendered (depends if the renderer supports out of order which pdf does). If the memory gets low then a page can be stored to disk and retrieved when forward references are resolved. Ah, so it's done with pages. But with some renderers pages could not be defined (as the spec allows), like in HTML rendering. Anyway, I didn't come up with this possibility, since I don't usually deal with them, but it's a really neat solution to the problem, but still useless if every page has forward references. Without needing to handle this on two sides of the fence it is more straight forward and flexible. Two sides of the fence? Never thought so. Ok, so I see that there is agreement on the fact that using SAX events as intermediate steps of the FOP processing pipeline is not the best solution ATM. I will focus now on implementing Avalon stuff in FOP, starting from Configuration (non static) and URI resolving (for images). Thank you all for the wonderful feedback on my Random Thoughts :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: development status
-Original Message- From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] Sent: March 19, 2002 11:48 AM To: [EMAIL PROTECTED] Subject: Re: development status From: Keiron Liddle [EMAIL PROTECTED] Retrieve Markers? IMHO yes, since you can make a forward reference with it. -Original Message- The section on retrieve-marker is not well written, but I would assert with a high degree of confidence that for any retrieve-marker, the only qualifying markers have already been seen. Supporting analysis: Spec Statement 1 - The term 'containing page' is used here to mean the page that contains the first area generated or returned by the children of the retrieved fo:marker. Spec Statement 2 - [ qualifying ] areas do not have a position in the hierarchy if they are within pages that follow the containing page. Statement 1 tells me that the page containing the fo:retrieve-marker is the containing page. Statement 2 tells me that markers, which otherwise qualify on the basis of class-name and retrieve-boundary, are ruled out. This is pretty unambiguous, although other parts of the relevant discussion are not. I am open to counter-arguments. The reason I am open to counter-arguments is I read stuff like this, for example: A) If the value of the retrieve-position property is last-starting-within-page, then the last qualifying area in the containing page whose is-first trait has a value of true is better than any other area. If there is no such area, then the last qualifying area in the containing page is better than any other area. AND B1) Every area in the hierarchy is considered preferential to, or better than, any area below it in the hierarchy. When comparing two areas to determine which one is better, the terms first and last refer to the preorder traversal order of the area tree. COUPLED WITH B2) A qualifying area within a page is better than any qualifying area within a preceding page. and my brain starts to implode. What does this mean? That _if_ there are NO areas on the containing page that have is-first = true, and in fact, there are no qualifying areas on the containing page at all, then Rule A kicks in and a qualifying area on page 11 is better than a qualifying area on page 18? In fact the entire question of what qualifying areas should be selected of nothing is found on the containing page is up in the air - apparently one always selects the first qualifying area (pre-order traversal of the area tree) subject to class-name and retrieve-boundary. Better to select nothing at all. Anyway, that's my little rant on markers. I raised the issue last year but never got an answer. But in terms of forward references fortunately the spec is very clear. Regards, AHS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: development status
Nicola Ken Barozzi wrote: From: Peter B. West [EMAIL PROTECTED] There is very active development on FO Tree building, property resolution and layout models. A lot of that development is desisn speculation, such as the design notes I have been posting, and there is also a fair bit of code, all of which resides with my ISP, references to which I post every now and then. I don't like what I think is happening. The FOP community is here, what does your ISP have to do with it? You have the *right* to branch and continue parallel development here. This is how it should be done. If not, it's not a FOP effort, it's your personal game. ... IMHO it's not necessary, but you have more experience than me on this. The fact that I didn't even know of your effort, and still don't know where the code is disturbes me somewhat. We are talking about having to depend on iText, but it seems to me that your effort is not different in this regard. Don't get me wrong, maybe I don't understand something, but still I'm very puzzled. Nicola, Your criticism here distresses me somewhat. How is anyone without commit access able to branch the code? I have been active on this list for twelve months or more, so your not knowing of my effort reflects the fact that you have recently joined. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: development status
From: Peter B. West [EMAIL PROTECTED] Nicola Ken Barozzi wrote: Don't get me wrong, maybe I don't understand something, but still I'm very puzzled. Nicola, Your criticism here distresses me somewhat. How is anyone without commit access able to branch the code? I have been active on this list for twelve months or more, so your not knowing of my effort reflects the fact that you have recently joined. Sorry, I didn't know. I still think that it's strange that the redesign effort is done outside of FOP CVS, but now it's clear to me that you didn't have another possibility. It's some month's I've been on this list, and my longer experience on other lists made me wonder about the current status of FOP. I thank you for taking your time to explain. Since I would like to give a hand if possible, could you please give me insight on how you've redesigned the framework, or some reference to available material? It would be great. Thank you :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: development status
On 2002.03.15 08:27 Nicola Ken Barozzi wrote: I think that the FOP community needs an explanation of my intrusion. I am a committer on the POI, Cocoon and Forrest projects, and a happy user of FOP for work. I wrote an XML semantic WYSIWYG editor in java that uses Avalon and specifies style with formatting objects, so I read the FO spec fully at least 3 times ;-) I've been following the FOP evolution with great interest, and now I would like to actively partecipate to this new FOP redesign. Expect a RT from me very soon on a the FOP-NG architecture based on Avalon I have in mind :-) I welcome your help (and I am sure others do too). The are certainly a number areas that need improvement such as the configuration. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: development status
From: Keiron Liddle [EMAIL PROTECTED]
At this stage of the design very few core problems can be solved in
isolation. So if someone wants to implement for example keeps or a colour
property, it has an impact on almost everything else in the layout.
So what is needed and what will make all the difference right now is more
involvement on things like the website, FAQ, configuration, external
interfaces, image handling etc.
Ok, I think I get the picture :-)
Thanks Keiron, you are clear as always.
For the website, as I already outlined, there is an effort going on called
Forrest ([EMAIL PROTECTED]) that will make the xml.apache.org site
easier to maintain and full of new features.
I'm keeping a build system that uses Ant and Cocoon on
http://www.krysalis.org, that is currently used by Forrest itself, Jakarta
POI and others. Maybe it could help a bit with the build and the
documentation generation process, but it's just a hint. If you have a spare
minute, take a look at it and see if it can help. Its force comes from tha
fact that all the projects that use it enhance their build and tools one
another.
What bugs me in FOP currently (the famous itch to scratch ;-) , is what
drives the whole process itself. Configuration, URI resolving, logging, and
so on. The infrastructure.
I'm not so much into FOP mechanics to help the DOM2SAX transition right now,
but as for the contour, I have a couple of ideas.
As I've hinted in past mails, I think that the fastest, I repeat *fastest*,
not necessarily the best, way of doing this transition is to use Cocoon.
Cocoon2 is bigger than is needed by FOP, but with some minor changes, IMO
it's just the right container for FOP.
FOP + Cocoon = FOPoon
Why Cocoon?
Well, I start all the reasoning by acknowledging that the FOP community
wants to reuse stuff done by other projects, and that Avalon is generally
regarded as a good solution.
Avalon is like an _onion_:
the framework
the simple implementation (Excalibur)
the full fledged server (Phoenix with Cornerstone blocks)
If we want to reuse as much as possible, and advance automatically in speed
and features with the advancements of Avalon, we need to use more than the
mere framework, which is basically a collection of interfaces and hints for
good programming practices. Since Phoenix is plainly overkill, what remains
is Excalibur.
This places Avalon between Excalibur and Phoenix, and it makes it clear that
in the future FOP could be packaged as a Block.
Now, what features of Avalon framework+Excalibur does FOP need?
- URI resolving
- xml processing
- pipelining
- component managers
- pools
- lifecycle handling
- configuration
- generic storage
- other things I don't think of ATM
There is a project on Apache that uses these Excalibur parts to make a
pipeline, and that project is Cocoon.
There are some drawbacks though:
- overkill?
- difficult to use?
As for Cocoon being overkill, it may stand if we use Cocoon as-is.
It has parts that FOP doesn't need, but they can be removed.
A cleaned Cocoon can give FOP only what it needs, and basically all that it
needs as infrastructure.
One thing that should be changed is the sitemap; Fop needs a very simple
sitemap, and pligging in a simple new version is easy, once the system is
working. For those who don't know, a sitemap is an xml file that specifies
how to handle the XML steps of the pipeline.
If you don't know Cocoon yet, please take a look at the Cocoon site at
http://xml.apache.org/cocoon/ , and I'll be glad to answer your questions.
FOP can be made as a Cocoon pipeline:
Generation
Transformation
Serialization
The Generation is already present in Cocoon: it parses the xml and spits out
SAX events. Total reuse here.
The Serialization is the Rendering phase: it accepts the SAX events and
spits out the resulting stream: this is easy to do: we just need to make a
DOM out of it and use one of the FOP renderers or even iText.
The middle part is what happens in between. There are transformations of the
XML that are the meat of FOP, and for now we can use the DOM code there is.
Here are the interfaces for a Transformer and a Serializer:
public interface Transformer extends XMLPipe, SitemapModelComponent {
}
public interface Serializer extends XMLConsumer, SitemapOutputComponent {
String ROLE = org.apache.cocoon.serialization.Serializer;
}
where:
public interface SitemapModelComponent extends Component {
/**
* Set the codeSourceResolver/code, objectModel codeMap/code,
* the source and sitemap codeParameters/code used to process the
request.
*/
void setup(SourceResolver resolver, Map objectModel, String src,
Parameters par) throws ProcessingException,
SAXException, IOException;
}
public interface SitemapOutputComponent extends Component {
/**
* Set the codeOutputStream/code where the requested resource should
* be serialized.
*/
Re: development status
From: Keiron Liddle [EMAIL PROTECTED] (as a guess I would say you haven't beed subscribed long enough :) ;-) There was a notice of this a number of months ago. Admittedly we have it the other way around. Maintenance releases are made from a branch. So the main branch is where the active development is happening. Ok. Makes sense since the community has common views. So where are we: I am going to great lengths to describe how it all works so others will have the knowledge to help out. I've seen it and it's very very well done. My sincere compliments :-) Many others are helping with ideas and requirements. Not much code is getting done because people are busy and the issues are complex (many of the side issues are being dealt with) The maintenance branch is being updated for bugs etc. Ok. I am hoping people will get to a point where they feel ready to jump in. So what needs to be done: Finish the implementation of the line layout do the page layout then do all fo's handle other issues then hopefully we will be ready for a developers release (version number yet to be decided) Ok, nice. This seems more like evolution than revolution, am I right? Are there any projects underway to change the processing model? How about the new property resolving proposal. Sorry if I keep asking, but I got a bit confused reading some mails on the list. Thank you :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: development status
On 2002.03.14 10:55 Nicola Ken Barozzi wrote: Ok, nice. This seems more like evolution than revolution, am I right? You could say that. The code is forming a revolution, not the people. We needed to go back a bit and approach things from a different angle. Are there any projects underway to change the processing model? I'm not sure exactly what you mean but there are probably no projects as such. Peter is looking at alternatives. How about the new property resolving proposal. No active development that I am aware of. Maybe Peter can elaborate. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: development status
Nicola, Comments interspersed. Nicola Ken Barozzi wrote: From: Keiron Liddle [EMAIL PROTECTED] There was a notice of this a number of months ago. Admittedly we have it the other way around. Maintenance releases are made from a branch. So the main branch is where the active development is happening. Ok. Makes sense since the community has common views. I suppose that depends on how you define community. So where are we: I am going to great lengths to describe how it all works so others will have the knowledge to help out. I've seen it and it's very very well done. My sincere compliments :-) Yes, that was a good idea. Many others are helping with ideas and requirements. Not much code is getting done because people are busy and the issues are complex (many of the side issues are being dealt with) The maintenance branch is being updated for bugs etc. I am hoping people will get to a point where they feel ready to jump in. So what needs to be done: Finish the implementation of the line layout do the page layout then do all fo's handle other issues then hopefully we will be ready for a developers release (version number yet to be decided) Ok, nice. This seems more like evolution than revolution, am I right? Are there any projects underway to change the processing model? How about the new property resolving proposal. Sorry if I keep asking, but I got a bit confused reading some mails on the list. I made an attempt to explain this recently. Maybe Keiron can try. Keiron? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: development status
Comments below. -Original Message- From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] Sent: March 14, 2002 11:07 AM To: [EMAIL PROTECTED] Subject: Re: development status From: Peter B. West [EMAIL PROTECTED] [ SNIP ] Arved is, as you know, engaged in a C/C++ project for a fast, small footprint FO Processor over at SourceForge, and I copy all of my design discussions to him. He has just committed another set of perl modules to his prototype. Why not put it here, in FOP. Hey, xml.apache is not only Java. Has this been tried? -End of Original Message- I've had the urge to try a SAX-based approach that uses C/C++ for quite a while. The main motivation behind C/C++ is so that SWIG can be used and therefore open the door at one fell swoop for Perl, Python, Tcl, Ruby etc etc. The main motivation behind SAX is to radically reduce memory consumption. I've only really gotten started on a prototype after the New Year. Prior to that I had too much other stuff going on - job switching (one employer going bust, working on a contract, and now fulltime again with a new employer), personal affairs (nothing bad, just that real life intrudes from time to time :-)), and quite frankly, a certain amount of FOP burnout - I was fed up with the codebase and needed to take a break. In the interim Keiron and Karen have really stepped up to the plate. They are doing great stuff. As it stands you can only have so many people doing what they are doing - 2 is about the limit - so I, like others, am waiting for the right moment to get involved in the redesign coding again. You may have noted that I volunteered to look at image support for the redesign and I am devoting time to that this weekend, so I haven't forsaken FOP in the least. Why is xslfo-proc (the Sourceforge project) not in Apache XML? Because the tide has turned for people wishing to make donations of unsupported codebases. A SAX-based, non-Java XSL formatter is basically an entirely different project - the rule of thumb these days is that you incubate the project somewhere else, like Sourceforge, develop a user and developer community, and then and only then do you look at bringing it into the Apache fold. And I completely agree with this. You're 100% right - Apache XML is not just about Java. But programming language is not the reason xslfo-proc is not a sideproject to FOP. It is all about community. If this codebase was side-by-side with FOP right now it would be a distraction at best. It would (possibly) divert resources from FOP rather than independently develop its own. That's not just my opinion; there have been discussions about alternate implementations before and I think there is a consensus that we don't diffuse the FOP effort at this time. But there is also no rule that any of us XSL enthusiasts cannot pursue parallel experiments, and that is what xslfo-proc is for me. I hope that answers a few questions. Regards, Arved Sandstrom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
