Re: [vote] Merging JFor with FOP
I think, it's a very good idea. jf - Original Message - From: Stefano Mazzocchi [EMAIL PROTECTED] To: FOP [EMAIL PROTECTED] Cc: Bertrand Delacretaz [EMAIL PROTECTED] Sent: Thursday, October 18, 2001 2:58 PM Subject: [vote] Merging JFor with FOP Hi people, recently, some code was donated to the Apache Cocoon project in order to connect it with JFor (www.jfor.org) which is a FO-RTF processor. It appeared evident to me (and to others, as I discovered later) that jfor and FOP are doing different things but could be an advantage for both jfor developers, jfor users, FOP users and FO visibility in general to join forces. Bertrand, here attached, is the main developer behind the project and he already agreed on donating the code to the ASF. IMO, rather than creating another project, it would be best to merge jfor code with FOP to allow yet another (and widely used) binary format to render FO in. Technical details are not that important at the moment, but Bertrand already stated his flexibility in reshaping jfor code in order to make it easier/cleaner/more-manageable the merging. This said, in order for the donation to take place, I'm officially requesting a vote from the FOP developers community. The Apache XML PMC is already informed and will accept any position taken by the community. So, here it is, please vote on the following question: would you like to accept jfor code and give Bertand Delacretaz committer status in order to perform the merging on the FOP code following the technical directions that the FOP dev community will find more appropriate? I remind that only people with committer status are entitled to place a binding vote, but I suggest everybody on this list to express their vote and, in case of negative vote, explain their reasons so that we can properly deal with them. Thanks to all. Stefano. P.S. Sorry for the formality, people but this is legal stuff so I'm required to wear my ASF member hat :) - 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: [vote] Merging JFor with FOP
On Thu, 18 Oct 2001 14:58:17 Stefano Mazzocchi wrote: would you like to accept jfor code and give Bertand Delacretaz committer status in order to perform the merging on the FOP code following the technical directions that the FOP dev community will find more appropriate? +1 Yes I think this would be a good contribution and be a good addition to the FOP project. As I am rewriting the area tree and renderers (which will make fop useless for a while) it would be a good idea to get things going together so that we can aim for a common target. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Merging JFor with FOP
On Thu, 18 Oct 2001 19:45:09 Alistair Hopkins wrote: With a little guidance, I will attempt some decoupling, especially from Batik. Any pointers? I've looked, and it seems fairly embroiled to me. Alistair This is something best done in the redesign, rather than doing it then needing to change it again. I will probably put in the new stuff and break everything sometime next week. For this particular problem the approach I think will work is to use the user agent (this can be implemented bits at a time). The renderer will then ask the user agent to handle the requested type of xml (in this case svg) and render to the output given the render context information (ie. pdf page. stream etc.). This way the user agent can handle any problems and separate external class loading from the renderers. There is one other small issue but it is fairly minor. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Merging JFor with FOP
At 09:20 AM 10/19/01 +0200, Keiron Liddle wrote: On Thu, 18 Oct 2001 14:58:17 Stefano Mazzocchi wrote: would you like to accept jfor code and give Bertand Delacretaz committer status in order to perform the merging on the FOP code following the technical directions that the FOP dev community will find more appropriate? +1 Yes I think this would be a good contribution and be a good addition to the FOP project. As I am rewriting the area tree and renderers (which will make fop useless for a while) it would be a good idea to get things going together so that we can aim for a common target. Speaking of common targets, let me know if I am safe to work on markers, or is that going to be hosed for a while? Arved Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [vote] Merging JFor with FOP
+1. Positive list contribution combined with a big code contribution makes it an easy call. -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 18, 2001 8:58 AM To: FOP Cc: Bertrand Delacretaz Subject: [vote] Merging JFor with FOP Hi people, recently, some code was donated to the Apache Cocoon project in order to connect it with JFor (www.jfor.org) which is a FO-RTF processor. It appeared evident to me (and to others, as I discovered later) that jfor and FOP are doing different things but could be an advantage for both jfor developers, jfor users, FOP users and FO visibility in general to join forces. Bertrand, here attached, is the main developer behind the project and he already agreed on donating the code to the ASF. IMO, rather than creating another project, it would be best to merge jfor code with FOP to allow yet another (and widely used) binary format to render FO in. Technical details are not that important at the moment, but Bertrand already stated his flexibility in reshaping jfor code in order to make it easier/cleaner/more-manageable the merging. This said, in order for the donation to take place, I'm officially requesting a vote from the FOP developers community. The Apache XML PMC is already informed and will accept any position taken by the community. So, here it is, please vote on the following question: would you like to accept jfor code and give Bertand Delacretaz committer status in order to perform the merging on the FOP code following the technical directions that the FOP dev community will find more appropriate? I remind that only people with committer status are entitled to place a binding vote, but I suggest everybody on this list to express their vote and, in case of negative vote, explain their reasons so that we can properly deal with them. Thanks to all. Stefano. P.S. Sorry for the formality, people but this is legal stuff so I'm required to wear my ASF member hat :) - 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: [vote] Merging JFor with FOP
With a little guidance, I will attempt some decoupling, especially from Batik. Any pointers? I've looked, and it seems fairly embroiled to me. Alistair -Original Message- From: Shkuro, Yuri [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 18, 2001 5:30 PM To: '[EMAIL PROTECTED]' Subject: RE: [vote] Merging JFor with FOP With proper care it is always possible to restructure the distribution so that unnecessary classes are not included. There are Ascii, PCL and PDF renderers in FOP - each can be in a separate jar file with no compile-time dependencies from the main jar, so if you don't use some format, drop the jar and be happy. Same applies to other included jars, like batik and logkit - they are not necessarily needed for everybody. Unfortunately, I don't have free time to volunteer to do this sort of decoupling of FOP subsystems, nor do I have a pressing need for it. My unofficial vote for merging JFor with FOP is: +1 YS -Original Message- From: Alistair Hopkins [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 18, 2001 11:46 AM To: [EMAIL PROTECTED] Subject: RE: [vote] Merging JFor with FOP Can I just appeal for some limitation on the size of the JAR files required? Not all java is server side and downloads sizes matter a lot! Alistair [still thinks Swing is a good idea] [but so is rtf] -Original Message- From: Beer, Christian [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 18, 2001 3:54 PM To: '[EMAIL PROTECTED]' Subject: AW: [vote] Merging JFor with FOP Although I am not a committer, I would like to give following unofficial vote: 1+; [...snip...] So, here it is, please vote on the following question: would you like to accept jfor code and give Bertand Delacretaz committer status in order to perform the merging on the FOP code following the technical directions that the FOP dev community will find more appropriate? I remind that only people with committer status are entitled to place a binding vote, but I suggest everybody on this list to express their vote and, in case of negative vote, explain their reasons so that we can properly deal with them. Thanks to all. Stefano. P.S. Sorry for the formality, people but this is legal stuff so I'm required to wear my ASF member hat :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - 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: [vote] Merging JFor with FOP
At 02:58 PM 10/18/01 +0200, Stefano Mazzocchi wrote: would you like to accept jfor code and give Bertand Delacretaz committer status in order to perform the merging on the FOP code following the technical directions that the FOP dev community will find more appropriate? Despite my recent lack of contributions, occasioned by real life, I haven't lost any enthusiasm for FOP, and hope to get back on track. Certainly I've kept an eye on JFOR and I'm pleased to see that we have a chance to join that functionality with FOP...I think it can only help both existing communities. A big +1 from me...a code contribution of this nature merits committer status, IMHO, plus Bertrand has been active on this list in any case. And we can always use more committers. Regards, Arved Sandstrom Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [vote] Merging JFor with FOP
-Original Message- From: Jim Wright [mailto:[EMAIL PROTECTED]] Sent: donderdag 18 oktober 2001 21:06 To: [EMAIL PROTECTED] Subject: RE: [vote] Merging JFor with FOP I don't officially count as these things go, but merging jfor and fop would solve several issues I currently have. Yes combinune fop and jfor would make life easier. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Merging JFor with FOP
+1 it would make JFOR and FOP richer John Kattestaart (Freeler) wrote: -Original Message- From: Jim Wright [mailto:[EMAIL PROTECTED]] Sent: donderdag 18 oktober 2001 21:06 To: [EMAIL PROTECTED] Subject: RE: [vote] Merging JFor with FOP I don't officially count as these things go, but merging jfor and fop would solve several issues I currently have. Yes combinune fop and jfor would make life easier. - 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: [vote] Merging JFor with FOP
I think anything we can do to encourage the use of XSL-FO is a good thing, especially now that XSL is finally a W3C Recommendation. +1 Regards, Karen Lease Stefano Mazzocchi wrote: Hi people, recently, some code was donated to the Apache Cocoon project in order to connect it with JFor (www.jfor.org) which is a FO-RTF processor. It appeared evident to me (and to others, as I discovered later) that jfor and FOP are doing different things but could be an advantage for both jfor developers, jfor users, FOP users and FO visibility in general to join forces. Bertrand, here attached, is the main developer behind the project and he already agreed on donating the code to the ASF. IMO, rather than creating another project, it would be best to merge jfor code with FOP to allow yet another (and widely used) binary format to render FO in. Technical details are not that important at the moment, but Bertrand already stated his flexibility in reshaping jfor code in order to make it easier/cleaner/more-manageable the merging. This said, in order for the donation to take place, I'm officially requesting a vote from the FOP developers community. The Apache XML PMC is already informed and will accept any position taken by the community. So, here it is, please vote on the following question: would you like to accept jfor code and give Bertand Delacretaz committer status in order to perform the merging on the FOP code following the technical directions that the FOP dev community will find more appropriate? I remind that only people with committer status are entitled to place a binding vote, but I suggest everybody on this list to express their vote and, in case of negative vote, explain their reasons so that we can properly deal with them. Thanks to all. Stefano. P.S. Sorry for the formality, people but this is legal stuff so I'm required to wear my ASF member hat :) - 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: [vote] Merging JFor with FOP
I am not a comiter, but I had to deal with FOP once (versions 0.19 and 0.20) and it is very probable that I have to deal with JFor, and I think this thing that is being proposed is a good one +1 -- Emmanuel Cuevas Senior Developer [EMAIL PROTECTED] Stefano Mazzocchi wrote: > > Hi people, > > recently, some code was donated to the Apache Cocoon project in order to > connect it with JFor (www.jfor.org) which is a FO->RTF processor. > > It appeared evident to me (and to others, as I discovered later) that > jfor and FOP are doing different things but could be an advantage for > both jfor developers, jfor users, FOP users and FO visibility in general > to join forces. > > Bertrand, here attached, is the main developer behind the project and he > already agreed on donating the code to the ASF. > > IMO, rather than creating another project, it would be best to merge > jfor code with FOP to allow yet another (and widely used) binary format > to render FO in. > Technical details are not that important at the moment, but Bertrand > already stated his flexibility in reshaping jfor code in order to make > it easier/cleaner/more-manageable the merging. > > This said, in order for the donation to take place, I'm officially > requesting a vote from the FOP developers community. The Apache XML PMC > is already informed and will accept any position taken by the community. > > So, here it is, please vote on the following question: > > would you like to accept jfor code and give Bertand Delacretaz committer > status in order to perform the merging on the FOP code following the > technical directions that the FOP dev community will find more > appropriate? > > I remind that only people with committer status are entitled to place a > binding vote, but I suggest everybody on this list to express their vote > and, in case of negative vote, explain their reasons so that we can > properly deal with them. > > Thanks to all. > > Stefano. > > P.S. Sorry for the formality, people but this is legal stuff so I'm > required to wear my ASF member hat :) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] begin:vcard n:Cuevas;Emmanuel x-mozilla-html:FALSE org:Internet de Alta Calidad;Desarrollo adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Ingeniero x-mozilla-cpt:;0 fn:Emamnuel Cuevas end:vcard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Merging JFor with FOP
I am not a committer but here is my unofficial vote: +1 It's a great advantage for everyone. Am Donnerstag, 18. Oktober 2001 14:58 schrieben Sie: Hi people, recently, some code was donated to the Apache Cocoon project in order to connect it with JFor (www.jfor.org) which is a FO-RTF processor. It appeared evident to me (and to others, as I discovered later) that jfor and FOP are doing different things but could be an advantage for both jfor developers, jfor users, FOP users and FO visibility in general to join forces. Bertrand, here attached, is the main developer behind the project and he already agreed on donating the code to the ASF. IMO, rather than creating another project, it would be best to merge jfor code with FOP to allow yet another (and widely used) binary format to render FO in. Technical details are not that important at the moment, but Bertrand already stated his flexibility in reshaping jfor code in order to make it easier/cleaner/more-manageable the merging. This said, in order for the donation to take place, I'm officially requesting a vote from the FOP developers community. The Apache XML PMC is already informed and will accept any position taken by the community. So, here it is, please vote on the following question: would you like to accept jfor code and give Bertand Delacretaz committer status in order to perform the merging on the FOP code following the technical directions that the FOP dev community will find more appropriate? I remind that only people with committer status are entitled to place a binding vote, but I suggest everybody on this list to express their vote and, in case of negative vote, explain their reasons so that we can properly deal with them. Thanks to all. Stefano. P.S. Sorry for the formality, people but this is legal stuff so I'm required to wear my ASF member hat :) - 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: [vote] Merging JFor with FOP
OK, I did this backwards... Does not change my vote, but I just took a look at the jfor site. I saw a couple of phrases that concerned me a bit. These are: jfor uses a simple mapping from XSL-FO to RTF without any layout computations, which means that the conversion is much faster than with FOP, for example (because jfor has much less to do - there's no magic here) and jfor attempts to preserve the structure of the document (a table is a table, a list is a list, etc.), which can cause some loss of presentation information (distances between elements, etc.) My concerns are that if jfor excels at speed at the expense of presentation. 1. Are jfor users going to be happy with jfor integrated with FOP which seems to favor presentation over speed? 2. Would FOP users be happy with the RTF generated if it loses presentation information? Of course hopefully when they are merged the whole will be greater than the sum of the parts. I do not know though. Assuming that the FOP architecture does not change significantly - my experience with the renderers is that they account for something like maybe 5 - 10 percent of the processing time (maybe less, don't have the numbers in front of me right now). Still I think that it is a good idea (especially for FOP users). Inexact presentation should not necessarily invalidate a renderer - after all - I am to blame for the TXTRenderer (talk about loss of presentation information). Just thought that I would mention it. Art -Original Message- From: Art Welch Sent: Thursday, October 18, 2001 4:44 PM To: '[EMAIL PROTECTED]' Subject: RE: [vote] Merging JFor with FOP Sounds like a good idea to me. The more renderers the better. +1 Art -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 18, 2001 8:58 AM To: FOP Cc: Bertrand Delacretaz Subject: [vote] Merging JFor with FOP Hi people, recently, some code was donated to the Apache Cocoon project in order to connect it with JFor (www.jfor.org) which is a FO-RTF processor. It appeared evident to me (and to others, as I discovered later) that jfor and FOP are doing different things but could be an advantage for both jfor developers, jfor users, FOP users and FO visibility in general to join forces. ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Merging JFor with FOP
Strong Yes! __ For the latest news, go to http://www.asia1.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Merging JFor with FOP
On Thu, 2001-10-18 at 15:42, Enrico Schnepel wrote: I am not a committer but here is my unofficial vote: +1 It's a great advantage for everyone. I'm not a committer. I'm just a user of FOP. I haven't heard of jfor before today. I urge FOP committers to examine the proposal to merge and vote yes only if the merge does not adversely affect the already strained performance of FOP in both space and time. -- Weiqi Gao [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Merging JFor with FOP (jfor speed/presentation)
On Thursday 18 October 2001 23:06, Art Welch wrote: snip My concerns are that if jfor excels at speed at the expense of presentation. 1. Are jfor users going to be happy with jfor integrated with FOP which seems to favor presentation over speed? 2. Would FOP users be happy with the RTF generated if it loses presentation information? snip Thanks for putting this up - the thing with RTF is that there is a fairly strong similarity between XSL-FO and RTF constructs, that does not need any layout work in the FO-RTF transformation (we had a good discussion about this earlier this year on this list). The layout is done later by the wordprocessor when the RTF file is opened. Hence jfor being called an XSL-FO to RTF *converter* and not *formatter*. jfor does a fairly simple mapping of XSL-FO elements to RTF constructs, hence the speed and small code size. So, technically I think the initial merging might see jfor sharing only some infrastructure with FOP (command-line and Cocoon invocation mechanisms, configuration, logging, parser, etc.), with a -rtf option that would more or less switch between jfor and FOP for processing of the XSL-FO elements. This is of course going to be discussed with the FOP community, I'm only thinking outloud here. As Stefano rightly mentioned in the private discussion that lead to this merging proposal, such a side-by-side merging would already be a big advantage for *users* of FOP who would get RTF output for free, without needing separate downloads and configuration. Not to mention increased visibility for both projects. Later on, we will have to refactor the jfor code to use more of the the FOP codebase where it makes sense. This might lead to new interfaces between FOP and its renderers (post-processors?), where a renderer could be plugged in at an earlier stage of the FOP formatting chain, not necessarily after the layout stage. So, IMHO jfor would not be a FOP renderer per se initially, but might become one later in the integration process. -- -- Bertrand Delacrétaz, www.codeconsult.ch -- jfor.org lead developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
