You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by "New, Cecil (GEAE)" <ce...@ae.ge.com> on 2002/03/12 14:28:56 UTC
FW: [iText-questions] Re: merging two libraries
My suggestion was *not* to merge the two!
iText is a Java API with a document creation focus. In this day and age,
XSL:FO can be viewed as just another document type - in the same way that
more proprietary or older formats are (that is, PDF, RTF, etc.).
Now XSL:FO is different in that you can't just double click on one and see
something. But the FOP project comes close.
Making iText (optionally) output xsl:fo would greatly extend its potential
applications and make it squarely standards based.
I would like to think that someday, StarOffice, Wordperfect, etc. would
either natively use xsl:fo as their file storage format or at least be able
to import it.
Having something like iText that *programatically* create documents is very
exciting!
-----Original Message-----
From: Keiron Liddle [mailto:keiron@aftexsw.com]
Sent: Tuesday, March 12, 2002 3:53 AM
To: fop-user@xml.apache.org
Cc: fop-dev@xml.apache.org; itext-questions@lists.sourceforge.net
Subject: [iText-questions] Re: merging two libraries
Hi,
From the archives it appears that the discussion on the fop-dev list was
about 2 years ago (no apparent refusal though). It is certainly time to
revisit.
From the small amount of information I know about iText it would appear
to be a more advanced pdf library.
I don't know what the license issues might be.
What sort of joining forces are you proposing?
Please send to the fop-dev list for further discussion.
Regards,
Keiron.
On 2002.03.12 09:27 bruno@lowagie.com wrote:
> Hello all,
>
> I'm not familiar with FOP, but I can't help noticing
> that people are moving from FOP to iText and vice versa. As original
> developer of iText, a JAVA-PDF library, I already
> proposed you guys at Apache twice to join forces and to combine
> both libraries. I now subscribe to this mailing list only to
> ask you a third time to reconsider your refusal. Please read these mails
> from some iText/FOP users:
> http://www.geocrawler.com/lists/3/SourceForge/8175/0/8071577/
>
http://www.mail-archive.com/itext-questions%40lists.sourceforge.net/msg00491
> .html Please send your answers to the iText mailing list.
> You don't need to subscribe, I will pass them through.
> Remark: sorry, but due to the lack of time to read all
> my mail as it is, I will now unsubscribe from the FOP
> mailing list. kind regards,
> Bruno Lowagie
_______________________________________________
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Re: FW: [iText-questions] Re: merging two libraries
Posted by "David B. Bitton" <da...@codenoevil.com>.
Absolutely. In fact, I am using iText to do just that, encryption. iText
has a PDFReader class that take a byte[] array for the constructor.
...
PdfReader reader = new PdfReader(out.toByteArray());
...
goto to http://www.lowagie.com/iText/tutorial/ch01.html#readingPDF and check
out the http://www.lowagie.com/iText/examples/Encrypt.java sample. If you
check the API JavaDocs, you can see how you can adapt the sample to use the
PdfReader constructor i noted earlier. :)
--
David B. Bitton
david@codenoevil.com
www.codenoevil.com
Diversa ab illis virtute valemus.
----- Original Message -----
From: "Matt Savino" <ma...@synergizethis.com>
To: <fo...@xml.apache.org>
Sent: Tuesday, March 12, 2002 8:32 AM
Subject: Re: FW: [iText-questions] Re: merging two libraries
> Is it possible to use iText for post-FOP processing like encryption or
> adding conditional text based on page breaks?
>
> "New, Cecil (GEAE)" wrote:
> >
> > My suggestion was *not* to merge the two!
> >
> > iText is a Java API with a document creation focus. In this day and
age,
> > XSL:FO can be viewed as just another document type - in the same way
that
> > more proprietary or older formats are (that is, PDF, RTF, etc.).
> >
> > Now XSL:FO is different in that you can't just double click on one and
see
> > something. But the FOP project comes close.
> >
> > Making iText (optionally) output xsl:fo would greatly extend its
potential
> > applications and make it squarely standards based.
> >
> > I would like to think that someday, StarOffice, Wordperfect, etc. would
> > either natively use xsl:fo as their file storage format or at least be
able
> > to import it.
> >
> > Having something like iText that *programatically* create documents is
very
> > exciting!
> >
> > -----Original Message-----
> > From: Keiron Liddle [mailto:keiron@aftexsw.com]
> > Sent: Tuesday, March 12, 2002 3:53 AM
> > To: fop-user@xml.apache.org
> > Cc: fop-dev@xml.apache.org; itext-questions@lists.sourceforge.net
> > Subject: [iText-questions] Re: merging two libraries
> >
> > Hi,
> >
> > From the archives it appears that the discussion on the fop-dev list
was
> > about 2 years ago (no apparent refusal though). It is certainly time to
> > revisit.
> >
> > From the small amount of information I know about iText it would appear
> > to be a more advanced pdf library.
> > I don't know what the license issues might be.
> >
> > What sort of joining forces are you proposing?
> >
> > Please send to the fop-dev list for further discussion.
> >
> > Regards,
> > Keiron.
> >
> > On 2002.03.12 09:27 bruno@lowagie.com wrote:
> > > Hello all,
> > >
> > > I'm not familiar with FOP, but I can't help noticing
> > > that people are moving from FOP to iText and vice versa. As original
> > > developer of iText, a JAVA-PDF library, I already
> > > proposed you guys at Apache twice to join forces and to combine
> > > both libraries. I now subscribe to this mailing list only to
> > > ask you a third time to reconsider your refusal. Please read these
mails
> > > from some iText/FOP users:
> > > http://www.geocrawler.com/lists/3/SourceForge/8175/0/8071577/
> > >
> >
http://www.mail-archive.com/itext-questions%40lists.sourceforge.net/msg00491
> >
> > > .html Please send your answers to the iText mailing list.
> > > You don't need to subscribe, I will pass them through.
> > > Remark: sorry, but due to the lack of time to read all
> > > my mail as it is, I will now unsubscribe from the FOP
> > > mailing list. kind regards,
> > > Bruno Lowagie
> >
> > _______________________________________________
> > iText-questions mailing list
> > iText-questions@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/itext-questions
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> > For additional commands, email: fop-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: FW: [iText-questions] Re: merging two libraries
Posted by Matt Savino <ma...@synergizethis.com>.
Is it possible to use iText for post-FOP processing like encryption or
adding conditional text based on page breaks?
"New, Cecil (GEAE)" wrote:
>
> My suggestion was *not* to merge the two!
>
> iText is a Java API with a document creation focus. In this day and age,
> XSL:FO can be viewed as just another document type - in the same way that
> more proprietary or older formats are (that is, PDF, RTF, etc.).
>
> Now XSL:FO is different in that you can't just double click on one and see
> something. But the FOP project comes close.
>
> Making iText (optionally) output xsl:fo would greatly extend its potential
> applications and make it squarely standards based.
>
> I would like to think that someday, StarOffice, Wordperfect, etc. would
> either natively use xsl:fo as their file storage format or at least be able
> to import it.
>
> Having something like iText that *programatically* create documents is very
> exciting!
>
> -----Original Message-----
> From: Keiron Liddle [mailto:keiron@aftexsw.com]
> Sent: Tuesday, March 12, 2002 3:53 AM
> To: fop-user@xml.apache.org
> Cc: fop-dev@xml.apache.org; itext-questions@lists.sourceforge.net
> Subject: [iText-questions] Re: merging two libraries
>
> Hi,
>
> From the archives it appears that the discussion on the fop-dev list was
> about 2 years ago (no apparent refusal though). It is certainly time to
> revisit.
>
> From the small amount of information I know about iText it would appear
> to be a more advanced pdf library.
> I don't know what the license issues might be.
>
> What sort of joining forces are you proposing?
>
> Please send to the fop-dev list for further discussion.
>
> Regards,
> Keiron.
>
> On 2002.03.12 09:27 bruno@lowagie.com wrote:
> > Hello all,
> >
> > I'm not familiar with FOP, but I can't help noticing
> > that people are moving from FOP to iText and vice versa. As original
> > developer of iText, a JAVA-PDF library, I already
> > proposed you guys at Apache twice to join forces and to combine
> > both libraries. I now subscribe to this mailing list only to
> > ask you a third time to reconsider your refusal. Please read these mails
> > from some iText/FOP users:
> > http://www.geocrawler.com/lists/3/SourceForge/8175/0/8071577/
> >
> http://www.mail-archive.com/itext-questions%40lists.sourceforge.net/msg00491
>
> > .html Please send your answers to the iText mailing list.
> > You don't need to subscribe, I will pass them through.
> > Remark: sorry, but due to the lack of time to read all
> > my mail as it is, I will now unsubscribe from the FOP
> > mailing list. kind regards,
> > Bruno Lowagie
>
> _______________________________________________
> iText-questions mailing list
> iText-questions@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/itext-questions
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [iText-questions] Re: merging two libraries
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "alex" <al...@yahoo.com>
> At 14:27 12/03/02, Keiron Liddle wrote:
> > > FOP behaves exactly the same but instead of having its own pdf
> > generation code then iText is
> > used as a library to generate pdf.
>
> I agree that if anything iText could be considered as a "plugin" for PDF
> generation and FOP as an XSL:FO processor which could use iText to
generate
> the end result. I think however it would require a significant software
> change which I am not qualified to estimate. Those more familiar with the
> FOP source code can evaluate that.
>
> > > So the questions are:
> > > - is the license useable
> > > - is the api sufficient for FOP to use
>
> A look at Sourceforge tells us that the licenCes (bloody Americans can't
> spell English words) are
> License: GNU Lesser General Public License (LGPL), Mozilla Public License
1.1
>
> If Bruno is still the copyright holder then he can presumably simply "add"
> an Apache-style licence.
> I don't feel comfortable using the LGPL for this and don't know about the
> Mozilla license.
Any *GPL licenced stuff cannot go in Apache CVS.
If the code goes in the Apache CVS, it must have Apache licen(c|s)e.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: merging two libraries
Posted by Hans Cobben <ha...@omicronn.com>.
Bruno : whatever license iText gets, if you sign a non-disclosure with your
employer, he can withhold you from "publishing" whatever you get to know or
do during working hours, if he expects it of being of strategic importance
to him.
Apart from that : keep an eye on different legal copyright approach between
continental Europe and Anglo-saxon countries (read UK/US). In Belgium and
other EU countries in principle you're the "de facto" owner of anything you
"create", even during working hours. Often employers then try to agree on a
transfer of "exploitation rights", but that must be stated explicitely in
your contract...and doesn't give them "intellectual property rights". Though
they can still ask you to sign a "non-disclosure".
Kind of dull and boring, but definitely of importance to anyone
writing/publishing code I'm afraid ...
Hans
-----Original Message-----
From: bruno@lowagie.com [mailto:bruno@lowagie.com]
Sent: woensdag 13 maart 2002 8:45
To: alex
Cc: fop-dev@xml.apache.org; itext-questions@lists.sourceforge.net
Subject: Re: merging two libraries
alex writes:
> I think however it would require a significant
> software change which I am not qualified to estimate. Those more familiar
> with the FOP source code can evaluate that.
I am now working on 'Styles' and 'default fonts', so that you
can tell some iText object 'please apply this style'.
Once this is finished, I will take a look at FOP.
>> > So the questions are:
>> > - is the license useable
>> > - is the api sufficient for FOP to use
>
> A look at Sourceforge tells us that the licenCes (bloody Americans can't
> spell English words) are
> License: GNU Lesser General Public License (LGPL), Mozilla Public License
> 1.1
>
> If Bruno is still the copyright holder then he can presumably simply "add"
> an Apache-style licence.
> I don't feel comfortable using the LGPL for this and don't know about the
> Mozilla license.
>
> Now I can't even find the exact text of these on the sourceforge site but
> I know they must be somewhere.
>
> I suppose I could always just download the software since the licences
> will be in the software package, no?
You don't need to download the complete package, the licen[c|s]es
are on my site:
http://www.lowagie.com/iText/lgpl.txt
http://www.lowagie.com/iText/MPL-1.1.txt
You can find my motivation for using these libraries here:
http://www.lowagie.com/iText/faq.html#lgpl
If Apache is compatible with MPL, I can indeed add it.
But as I stated before: I am going to work in the private
sector again soon (for the moment I work for the government).
I didn't like some non-disclosure clausules in my contract
at my new company, but I signed it because I feel protected
by the MPL: if they ask me to write extra functionality for
iText, the MPL has priority over my contract (if they'll
disagree, I'll quit). I fear that if iText gets an Apache
licen[c|s]e, my new company will be able to prevent my from
distributing all improvements.
kind regards,
Bruno
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: merging two libraries
Posted by br...@lowagie.com.
alex writes:
> I think however it would require a significant
> software change which I am not qualified to estimate. Those more familiar
> with the FOP source code can evaluate that.
I am now working on 'Styles' and 'default fonts', so that you
can tell some iText object 'please apply this style'.
Once this is finished, I will take a look at FOP.
>> > So the questions are:
>> > - is the license useable
>> > - is the api sufficient for FOP to use
>
> A look at Sourceforge tells us that the licenCes (bloody Americans can't
> spell English words) are
> License: GNU Lesser General Public License (LGPL), Mozilla Public License
> 1.1
>
> If Bruno is still the copyright holder then he can presumably simply "add"
> an Apache-style licence.
> I don't feel comfortable using the LGPL for this and don't know about the
> Mozilla license.
>
> Now I can't even find the exact text of these on the sourceforge site but
> I know they must be somewhere.
>
> I suppose I could always just download the software since the licences
> will be in the software package, no?
You don't need to download the complete package, the licen[c|s]es
are on my site:
http://www.lowagie.com/iText/lgpl.txt
http://www.lowagie.com/iText/MPL-1.1.txt
You can find my motivation for using these libraries here:
http://www.lowagie.com/iText/faq.html#lgpl
If Apache is compatible with MPL, I can indeed add it.
But as I stated before: I am going to work in the private
sector again soon (for the moment I work for the government).
I didn't like some non-disclosure clausules in my contract
at my new company, but I signed it because I feel protected
by the MPL: if they ask me to write extra functionality for
iText, the MPL has priority over my contract (if they'll
disagree, I'll quit). I fear that if iText gets an Apache
licen[c|s]e, my new company will be able to prevent my from
distributing all improvements.
kind regards,
Bruno
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [iText-questions] Re: merging two libraries
Posted by alex <al...@yahoo.com>.
At 14:27 12/03/02, Keiron Liddle wrote:
> > FOP behaves exactly the same but instead of having its own pdf
> generation code then iText is
> used as a library to generate pdf.
I agree that if anything iText could be considered as a "plugin" for PDF
generation and FOP as an XSL:FO processor which could use iText to generate
the end result. I think however it would require a significant software
change which I am not qualified to estimate. Those more familiar with the
FOP source code can evaluate that.
> > So the questions are:
> > - is the license useable
> > - is the api sufficient for FOP to use
A look at Sourceforge tells us that the licenCes (bloody Americans can't
spell English words) are
License: GNU Lesser General Public License (LGPL), Mozilla Public License 1.1
If Bruno is still the copyright holder then he can presumably simply "add"
an Apache-style licence.
I don't feel comfortable using the LGPL for this and don't know about the
Mozilla license.
Now I can't even find the exact text of these on the sourceforge site but I
know they must be somewhere.
I suppose I could always just download the software since the licences will
be in the software package, no?
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Thursday 14 March 2002 09:00, Nicola Ken Barozzi wrote:
>. . .
> > 1. FopParser parses and validates the input XSL-FO document
> Not needed if using Cocoon as a pipeline.
>. . .
Right, but it's so easy that we might as well keep it for easier
testing.
>. . .
> What I would like to see, is that FOP stops discussing about the
> logging, resolving, pipelineing and stuff and starts to focus on the
> core functionality.
>. . .
Yes, but IMHO resolving (in the sense of "resolving FO object
properties" like I think is meant by FOP) is part of the core
functionality. I'm talking about computing presentation attributes for
child elements based on their parent's attributes.
>. . .
> This can big opportunity also for other projects to collaborate in
> the rendering.
> JFor, for example (I don't remember who maintains it ;-P)
>. .
That's me by the way ;-)
(but I haven't done much lately)
--
Bertrand Delacrétaz (codeconsult.ch, jfor.org)
buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
disclaimer: eternity is very long. mostly towards the end. get ready.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Thursday 14 March 2002 09:19, Keiron Liddle wrote:
>. . .
> Firstly the Area Tree is unavoidable. We must have a place to do the
> layout and to store the page information.
>. . .
Unavoidable for "Layout rendering", isn't it?
I thought structure-based rendering wouldn't need the area tree.
>. . .
> For the FOTree to structure document it is a different issue, that I
> hope we will solve one day. Maybe sax events could be used here.
>. . .
How hard would it be to render the FOTree in XSL-FO (based on SAX
events) with all possible attributes resolved?
Speaking specifically about the jfor RTF converter, this would allow it
to be used as a FOP renderer without needing as much code changes as an
API-based integration. Might be a little slower but much more flexible.
This would allow the parser and property resolver (is that the right
term?) components of FOP to be reused by jfor and future
structure-based renderers.
--
Bertrand Delacrétaz (codeconsult.ch, jfor.org)
buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
disclaimer: eternity is very long. mostly towards the end. get ready.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Thursday 14 March 2002 09:27, Nicola Ken Barozzi wrote:
>. . .
> Hmmm... AFAIK FO is about layout, not semantical structure.
> Bold is just Bold, and not "emphasis" or "strong".
> Maybe I don't get the point. Could you elaborate more please?
>. . .
The term "structure renderer" (as you could find by searching the list
archive probably ;-) is used here for yet-to-be renderers that don't do
any layout by themselves.
If you're generating RTF or MIF formats, for example, you usually don't
need to know on which page a given FO element will go, you leave this
to the word processor or desktop publishing program that will use the
generated document.
So these renderers will be plugged in right after the parsing and
property resolution stages, before the layout stage.
--
Bertrand Delacrétaz (codeconsult.ch, jfor.org)
buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
disclaimer: eternity is very long. mostly towards the end. get ready.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Hi Peter,
> Aside from my low opinion of SAX for process coupling, there should
> be no need for communication back from the renderer.
>. . .
cool - I thought the Area Tree code needed to know about font metrics
and the like, but if this communication is one-way all the better.
Regarding SAX events, I really meant that for structure renderers. What
I envision (in the context of RTF rendering through jfor) is the
possibility of using the FOP front-end only to resolve XSL-FO
properties, like an "XSL-FO preprocessor" if you want.
That's for this "preprocessor-to-StructureRenderer" interface that I
think using XML makes sense, for loose coupling of the
StructureRenderers which would then not necessarily be part of the FOP
code base.
If we agree that XML is good for this, I think generating this XML
through SAX events allows the preprocessor component to be efficiently
integrated in Cocoon (for example) later on, without having to
serialize and reparse the XML.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
Posted by "Peter B. West" <pb...@powerup.com.au>.
Bertrand,
Aside from my low opinion of SAX for process coupling, there should be
no need for communication back from the renderer. The Area Tree should
just give orders to the renderer. All of the layout decisions have been
made by the time the Area Tree is constructed. The feedback is within
the layout process, and the particulars of that are the cause of much
wailing and gnashing of teeth.
Peter
Bertrand Delacretaz wrote:
>On Thursday 14 March 2002 09:27, Nicola Ken Barozzi wrote:
>
>>. . .
>>I think that a SAXrenderer could be the solution. SAX is based on
>>calling a method when a tag begin-content-end is reached. It can be
>>used to communicate the Area Tree to the renderer in a clean way,
>>whith a standard interface.
>>. . .
>>
>
>Won't work I think, print-based layout (as opposed to structure-based)
>requires two-way communication between the layout engine and the
>renderer (to compute the width text runs, for example).
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Thursday 14 March 2002 09:27, Nicola Ken Barozzi wrote:
>. . .
> I think that a SAXrenderer could be the solution. SAX is based on
> calling a method when a tag begin-content-end is reached. It can be
> used to communicate the Area Tree to the renderer in a clean way,
> whith a standard interface.
>. . .
Won't work I think, print-based layout (as opposed to structure-based)
requires two-way communication between the layout engine and the
renderer (to compute the width text runs, for example).
--
Bertrand Delacrétaz (codeconsult.ch, jfor.org)
buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
disclaimer: eternity is very long. mostly towards the end. get ready.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
Posted by "Peter B. West" <pb...@powerup.com.au>.
Keiron Liddle wrote:
> On 2002.03.14 09:00 Nicola Ken Barozzi wrote:
>
>> What I would like to see, is that FOP stops discussing about the
>> logging,
>> resolving, pipelineing and stuff and starts to focus on the core
>> functionality.
>> IMHO, the best way to get this thing going *quick* is to use Cocoon as a
>> pipeline. Cocoon gives you all these features, and gives you a solid
>> framework to work on.
>> When it works on Cocoon, we can see if performance for stand-alone
>> processing is good enough. If not, we can *then* talk about the
>> structure
>> around FOP, and break eventually free from Cocoon.
>
>
> Firstly the Area Tree is unavoidable.
Hear, hear.
> We must have a place to do the layout and to store the page information.
> If you want this area tree turned into sax events, it really seems
> like an unecessary step but there is an xml renderer (admittedly
> simply writes text at the moment but you get the idea) if you want to
> add this extra step.
Agree strongly. At various times the notion of "flattening the area
tree" has been wrestled with in these pages. At some point the tree
model of pages loses all relevance. Trees are very useful to describe
the structure of the "stuff" being squirted onto the page. At the end
of the day, though, the "stuff" is rendered as a series of marks on a
flat surface, and, to the renderer of last resort, all of the data
structures that generated the marks are irrelevant.
I am utterly ignorant of any particular page description languages, so
imagine such a language that provides for the drawing of certain sorts
of marks on the page at certain co-ordinates. That, essentially, is the
output of the area tree.
If you want to express that page definition language in xml, go right
ahead. Xml output would indeed be loosely coupled. It's a data stream.
SAX events are about as loosely coupled as tree roots. It's an API,
after all, and an API which is inimical to pipelining processes.
However, if you want to be able to feed the area tree into various
renderers, you have to use some sort of PDL to transcribe the area tree,
and the description is linear set of random access instructions, whether
expressed in an xml file or an API.
>
> The FO Tree - Layout - Area Tree are the three core issues. This is
> what needs to be done first.
Yes.
>
> For the FOTree to structure document it is a different issue, that I
> hope we will solve one day. Maybe sax events could be used here.
>
My own approach is an API-based pipeline. As you say, these three, FO
Tree - Layout (Tree?) - Area Tree, are the tightly coupled core issues.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Keiron Liddle" <ke...@aftexsw.com>
> On 2002.03.14 09:00 Nicola Ken Barozzi wrote:
> > What I would like to see, is that FOP stops discussing about the
logging,
> > resolving, pipelineing and stuff and starts to focus on the core
> > functionality.
> > IMHO, the best way to get this thing going *quick* is to use Cocoon as a
> > pipeline. Cocoon gives you all these features, and gives you a solid
> > framework to work on.
> > When it works on Cocoon, we can see if performance for stand-alone
> > processing is good enough. If not, we can *then* talk about the
structure
> > around FOP, and break eventually free from Cocoon.
>
> Firstly the Area Tree is unavoidable. We must have a place to do the
> layout and to store the page information.
Right. And flush it ASAP, as FOP already tries to do now to some degree.
> If you want this area tree turned into sax events, it really seems like an
> unecessary step but there is an xml renderer (admittedly simply writes
> text at the moment but you get the idea) if you want to add this extra
> step.
I think that a SAXrenderer could be the solution. SAX is based on calling a
method when a tag begin-content-end is reached. It can be used to
communicate the Area Tree to the renderer in a clean way, whith a standard
interface.
To make a renderer use by FOP in this way, you just need to say:"We give you
this xml area tree that conforms to this schema via SAX. Render it". No
knowledge of FOP internals is needed.
> The FO Tree - Layout - Area Tree are the three core issues. This is what
> needs to be done first.
Can't agree more :-)
> For the FOTree to structure document it is a different issue, that I hope
> we will solve one day. Maybe sax events could be used here.
Hmmm... AFAIK FO is about layout, not semantical structure.
Bold is just Bold, and not "emphasis" or "strong".
Maybe I don't get the point. Could you elaborate more please?
Thank you.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
Posted by Keiron Liddle <ke...@aftexsw.com>.
On 2002.03.14 09:00 Nicola Ken Barozzi wrote:
> What I would like to see, is that FOP stops discussing about the logging,
> resolving, pipelineing and stuff and starts to focus on the core
> functionality.
> IMHO, the best way to get this thing going *quick* is to use Cocoon as a
> pipeline. Cocoon gives you all these features, and gives you a solid
> framework to work on.
> When it works on Cocoon, we can see if performance for stand-alone
> processing is good enough. If not, we can *then* talk about the structure
> around FOP, and break eventually free from Cocoon.
Firstly the Area Tree is unavoidable. We must have a place to do the
layout and to store the page information.
If you want this area tree turned into sax events, it really seems like an
unecessary step but there is an xml renderer (admittedly simply writes
text at the moment but you get the idea) if you want to add this extra
step.
The FO Tree - Layout - Area Tree are the three core issues. This is what
needs to be done first.
For the FOTree to structure document it is a different issue, that I hope
we will solve one day. Maybe sax events could be used here.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Bertrand Delacretaz" <bd...@codeconsult.ch>
> On Wednesday 13 March 2002 16:58, Nicola Ken Barozzi wrote:
> >. . .
> > -------------------------------------------------------------
> > FOP uses iText as a PDF generation library
> > -------------------------------------------------------------
> >. . .
>
> Maybe the following scenario could help making FOP more
> "pipeline-oriented", making it easier to plug in various renderers,
> layout engines, debugging tools, etc.
>
> I'm just making up component names, hopefully understandable
>
> 1. FopParser parses and validates the input XSL-FO document
Not needed if using Cocoon as a pipeline.
> 2. FopPropertyResolver does its job, attributes inheritance, etc.
>
> Then two options:
> 3a. FopLayoutEngine (existing code, API-coupled as now) computes layout
> and produces PDF
>
> 3b. *or* FopFoDumper dumps the result in XML (or SAX events) using the
> XSL-FO vocabulary but with all attributes explicity specified (as far
> as possible, I know there are some issues here).
3b
> After 3b, various XSLT transforms and/or XML-to-something converters
> can be plugged in using the well-defined and loosely-coupled SAX/XML
> interface.
>
> I think using XML/SAX to interface between future pipeline components
> (ParsingAndPropertyResolving -> Layout -> Serialization) opens up much
> more options than using java APIs for this, and could help keep FOP
> small and focused.
>
> If using Cocoon, being able to just resolve properties and pass the
> result on to various transforms opens up new horizons for XSL-FO
> processing.
This is the proposal I made, and I think it stands even stronger now.
If FOP is pipeline driven, any renderer can be quite easily plugged in.
AFAIK, the pipeline architecture is one of the major design differences that
in some way has been agreed on.
What I would like to see, is that FOP stops discussing about the logging,
resolving, pipelineing and stuff and starts to focus on the core
functionality.
IMHO, the best way to get this thing going *quick* is to use Cocoon as a
pipeline. Cocoon gives you all these features, and gives you a solid
framework to work on.
When it works on Cocoon, we can see if performance for stand-alone
processing is good enough. If not, we can *then* talk about the structure
around FOP, and break eventually free from Cocoon.
> At the other end of the pipeline, what about an XML-to-MIF
> converter, for example, much more generally useful than a
> tightly-coupled MIF renderer for FOP.
>
> Implementing 3b should be fairly easy (isn't that a serialization of
> the FOTree?), and we can go from here to reuse important parts of FOP
> as individual components.
I agree.
This can big opportunity also for other projects to collaborate in the
rendering.
JFor, for example (I don't remember who maintains it ;-P)
And POI. At POI, we are going to do a Word .doc format writer. It could fit
easily in this picture.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation-
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Wednesday 13 March 2002 16:58, Nicola Ken Barozzi wrote:
>. . .
> -------------------------------------------------------------
> FOP uses iText as a PDF generation library
> -------------------------------------------------------------
>. . .
Maybe the following scenario could help making FOP more
"pipeline-oriented", making it easier to plug in various renderers,
layout engines, debugging tools, etc.
I'm just making up component names, hopefully understandable
1. FopParser parses and validates the input XSL-FO document
2. FopPropertyResolver does its job, attributes inheritance, etc.
Then two options:
3a. FopLayoutEngine (existing code, API-coupled as now) computes layout
and produces PDF
3b. *or* FopFoDumper dumps the result in XML (or SAX events) using the
XSL-FO vocabulary but with all attributes explicity specified (as far
as possible, I know there are some issues here).
After 3b, various XSLT transforms and/or XML-to-something converters
can be plugged in using the well-defined and loosely-coupled SAX/XML
interface.
I think using XML/SAX to interface between future pipeline components
(ParsingAndPropertyResolving -> Layout -> Serialization) opens up much
more options than using java APIs for this, and could help keep FOP
small and focused.
If using Cocoon, being able to just resolve properties and pass the
result on to various transforms opens up new horizons for XSL-FO
processing.
At the other end of the pipeline, what about an XML-to-MIF
converter, for example, much more generally useful than a
tightly-coupled MIF renderer for FOP.
Implementing 3b should be fairly easy (isn't that a serialization of
the FOTree?), and we can go from here to reuse important parts of FOP
as individual components.
How does this sound?
--
Bertrand Delacrétaz (codeconsult.ch, jfor.org)
buzzwords: XML, java, XSLT, cocoon, mentoring/teaching/coding.
disclaimer: eternity is very long. mostly towards the end. get ready.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was:
merging two libraries)
Posted by Ralph LaChance <Ra...@compuserve.com>.
I'm wondering if marying FOP +iText would sacrifice the
-awt -print -ps options. (Same question for -text, but i'm
personally not interested in that.)
At 10:58 AM 3/13/02, you wrote:
>
>Given what has been said on the mailing lists of FOP and iText, and given
>the current scope of the two projects, I feel reasonably sure that this
>could be a proposal accepted by bot communities.
>
>-------------------------------------------------------------
> FOP uses iText as a PDF generation library
>-------------------------------------------------------------
>
>This could have greater benefits than a merger and keep intact the strenghts
>that these two projects have (remember AOL+Time Warner? is the result we
>want?).
>
>iText could continue to be an excellent PDF (and RTF AFAIK) generation
>package with a good java API.
>FOP could concentrate on FO2AreaTree and use iText as the last step.
>
>Given the licences, nobody is prohibited to cross-collaborate. iText
>developers can send patches to FOP and viceversa, and be [VOTE]d as usual
>when the time is right.
>FOP can distribute iText jar as it's MPL, and both projects would cross-link
>in a clear way.
>
>AFAIK iText is already able to produce PDF using an XML file. If FOP could
>make a transformation step from FO to this format, we could get this up
>running in a short time.
>And IText can also output to html, which is not bad at all.
>
>What do you think?
>Shall we pull this off?
>
>--
>Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
>---------------------------------------------------------------------
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
>For additional commands, email: fop-dev-help@xml.apache.org
' Best,
-Ralph LaChance
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: development status
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Peter B. West" <pb...@powerup.com.au>
> 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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: development status
Posted by "Peter B. West" <pb...@powerup.com.au>.
Nicola Ken Barozzi wrote:
>From: "Peter B. West" <pb...@powerup.com.au>
>
>>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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: development status
Posted by Keiron Liddle <ke...@aftexsw.com>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: development status
Posted by "Peter B. West" <pb...@powerup.com.au>.
Nicola Ken Barozzi wrote:
>From: "Arved Sandstrom" <Ar...@chebucto.ns.ca>
>
...
> I read the FO spec fully at
>least 3 times ;-)
>
Impossible!
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: development status
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Arved Sandstrom" <Ar...@chebucto.ns.ca>
> 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 understand your point of view and I respect it.
Since I didn't follow the discussions you refer to, I remain with what you
refer that the FOP community has decided; it makes sense and it is based on
the good life of the community.
Now FOP AFAIK wants to be based on SAX, iText offered to collaborate
closely, and there are indipendedt efforts of defining a new FOP codebase.
Keiron is doing an *awesome* job in explaining what FOP is all about, and
many developers are willing to take part.
Everything is ready for a project boost ;-)
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 :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: development status
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
Comments below.
-----Original Message-----
From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
Sent: March 14, 2002 11:07 AM
To: fop-dev@xml.apache.org
Subject: Re: development status
From: "Peter B. West" <pb...@powerup.com.au>
[ 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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: development status
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Peter B. West" <pb...@powerup.com.au>
> 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.
> 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?
> The
> approach of both Arved and me is revolutionary rather than evolutionary,
> primarily, I think, because both of us feel that the requirements are so
> complex and interrelated that the design of all of the phases must
> proceed in parallel, which also means that everything is up for grabs.
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 Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: development status
Posted by "Peter B. West" <pb...@powerup.com.au>.
Keiron,
You have pre-empted my last post on this topic.
Keiron Liddle wrote:
> 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.
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. 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. The
approach of both Arved and me is revolutionary rather than evolutionary,
primarily, I think, because both of us feel that the requirements are so
complex and interrelated that the design of all of the phases must
proceed in parallel, which also means that everything is up for grabs.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: development status
Posted by Keiron Liddle <ke...@aftexsw.com>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: development status
Posted by "Peter B. West" <pb...@powerup.com.au>.
Nicola,
Comments interspersed.
Nicola Ken Barozzi wrote:
>From: "Keiron Liddle" <ke...@aftexsw.com>
>
>>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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: development status
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Keiron Liddle" <ke...@aftexsw.com>
> (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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
development status
Posted by Keiron Liddle <ke...@aftexsw.com>.
(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.
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.
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)
On 2002.03.14 08:49 Nicola Ken Barozzi wrote:
> Although I'm subscribed to this mailing list for quite some time now, I
> didn't really understand the status of the works that are going on to get
> to
> FOP2 or whatever you are going to call it.
> AFAIK, changing codebase requires a notice of this, a branch in CVS (no
> vote
> is necessary), and a final VOTE if the codebase is to switch.
> This is how Tomcat, Xalan, Xerces and many other projects did it, and how
> the priject guidelines advise. (http://xml.apache.org/source.html)
>
> What's the current status?
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Peter B. West" <pb...@powerup.com.au>
> Nicola,
>
> I think there are a few issues to be considered here. Essentially, what
> is FOP?
Good point.
> There may be a number of requirements of an XSL-FO processor. The basic
> one is, "Show me this on a page or screen." Any kind of renderer, using
> any approach whatsoever, will achieve this, more or less. The so-called
> "structure renderers", like the rtf and mif renderers, do this with a
> useful side-effect; the file they produce can be not only viewed, but
> edited. It seems to me that what you are proposing is to use iText as a
> basic "structure renderer," mapping the fo structures into
> iText-compatible structures.
As a start, yes.
> With all of the structure renderers, however, you are at the mercy of
> the individual layout engines. Anyone who has tried to produce a
> complex document using two versions of MS-Word will have an acute
> understanding of what it means to be at the mercy of someone else's
> renderer.
I think the POI team (http://jakarta.apache.org/poi/) would have something
to say about this, but it would not be appreciation for the MS file formats
;-)
> The spec itself defines a layout engine in the production of the area
> tree from the fo tree. Admittedly, there are a number of grey areas in
> layout, especially when constraints conflict, in which the final
> decision is up to the User Agent. Effectively, it's up to the
> implementation. The area tree, though, defines the position of every
> mark on every page. It inherently holds out the prospect of producing
> identical layouts from every renderer downstream of the area tree.
This implies AFAIK that the creation of the area tree is the crucial point,
the pivotal scope of FOP.
> I was initially skeptical about this, because of the dependency of the
> layout on the font characteristics. It was pointed out to me, though,
> that as long as a renderer honoured the metrics of the design font then,
> even if individual glyphs were considerably different, the *layout*
> would still be identical down ot the position of individual glyphs on a
> page.
>
> It seems to me that that is what a full implementation of the spec
> implies, and that such a search for consistency in the position of marks
> on page or screen is one of the most desirable features of the spec.
> What may not be achievable across different implementations, we may
> still seek to achieve within a single implementation.
Yes.
> With that in mind, we can probably conclude that a true structure
> renderer cannot achieve this cross-renderer consistency.
And this is taken in account for in the spec as you know, which defines many
tags as optional and hints on how to downgrade gracefully.
> That would
> also be true of iText, used in such a way. If however, the interface to
> iText were defined such that the position and size of al marks to be put
> on the page could be rigorously determined, it could meet the
> requirement. I, for one, would like to see such a precise and
> relatively low-level pdf library.
In the proposal, the hint to active collaboration is there to achieve this
synergy.
Itext can give FOP a boost in rendering, and the FOP community can give
iText greater precision in rendering.
The iText community has shown IMO sincere quest for an active collaboration,
and even donation of the code to FOP.
As both communities pointed out correctly, just merging two project usually
doesn't make a bigger project, but a bigger mess.
So it seems that this thing can start :-)
There is no need for a VOTE, since plain discussion and sharing of views is
free, of course.
Although I'm subscribed to this mailing list for quite some time now, I
didn't really understand the status of the works that are going on to get to
FOP2 or whatever you are going to call it.
AFAIK, changing codebase requires a notice of this, a branch in CVS (no vote
is necessary), and a final VOTE if the codebase is to switch.
This is how Tomcat, Xalan, Xerces and many other projects did it, and how
the priject guidelines advise. (http://xml.apache.org/source.html)
What's the current status?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging
two libraries)
Posted by "Peter B. West" <pb...@powerup.com.au>.
Nicola,
I think there are a few issues to be considered here. Essentially, what
is FOP?
There may be a number of requirements of an XSL-FO processor. The basic
one is, "Show me this on a page or screen." Any kind of renderer, using
any approach whatsoever, will achieve this, more or less. The so-called
"structure renderers", like the rtf and mif renderers, do this with a
useful side-effect; the file they produce can be not only viewed, but
edited. It seems to me that what you are proposing is to use iText as a
basic "structure renderer," mapping the fo structures into
iText-compatible structures.
With all of the structure renderers, however, you are at the mercy of
the individual layout engines. Anyone who has tried to produce a
complex document using two versions of MS-Word will have an acute
understanding of what it means to be at the mercy of someone else's
renderer.
The spec itself defines a layout engine in the production of the area
tree from the fo tree. Admittedly, there are a number of grey areas in
layout, especially when constraints conflict, in which the final
decision is up to the User Agent. Effectively, it's up to the
implementation. The area tree, though, defines the position of every
mark on every page. It inherently holds out the prospect of producing
identical layouts from every renderer downstream of the area tree.
I was initially skeptical about this, because of the dependency of the
layout on the font characteristics. It was pointed out to me, though,
that as long as a renderer honoured the metrics of the design font then,
even if individual glyphs were considerably different, the *layout*
would still be identical down ot the position of individual glyphs on a
page.
It seems to me that that is what a full implementation of the spec
implies, and that such a search for consistency in the position of marks
on page or screen is one of the most desirable features of the spec.
What may not be achievable across different implementations, we may
still seek to achieve within a single implementation.
With that in mind, we can probably conclude that a true structure
renderer cannot achieve this cross-renderer consistency. That wouls
also be true of iText, used in such a way. If however, the interface to
iText were defined such that the position and size of al marks to be put
on the page could be rigorously determined, it could meet the
requirement. I, for one, would like to see such a precise and
relatively low-level pdf library.
Peter
Nicola Ken Barozzi wrote:
>Given what has been said on the mailing lists of FOP and iText, and given
>the current scope of the two projects, I feel reasonably sure that this
>could be a proposal accepted by bot communities.
>
>-------------------------------------------------------------
> FOP uses iText as a PDF generation library
>-------------------------------------------------------------
>
>This could have greater benefits than a merger and keep intact the strenghts
>that these two projects have (remember AOL+Time Warner? is the result we
>want?).
>
>iText could continue to be an excellent PDF (and RTF AFAIK) generation
>package with a good java API.
>FOP could concentrate on FO2AreaTree and use iText as the last step.
>
>Given the licences, nobody is prohibited to cross-collaborate. iText
>developers can send patches to FOP and viceversa, and be [VOTE]d as usual
>when the time is right.
>FOP can distribute iText jar as it's MPL, and both projects would cross-link
>in a clear way.
>
>AFAIK iText is already able to produce PDF using an XML file. If FOP could
>make a transformation step from FO to this format, we could get this up
>running in a short time.
>And IText can also output to html, which is not bad at all.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)
Posted by kyle koss <kk...@xperient.net>.
I say do it.
After using FOP for a while now and always having a problem with the
embedded fonts, I thought I would try iText. The iText was able to
handle the embedded fonts without any trouble at all. It seems that at
least in this area iText is much stronger than FOP.
The use of fo, for us, is the major benefit of FOP, while it is also
important for our project to be able to use fonts other than the
defaults. So, I think a merging of the two would definitely be a major
plus.
I am all for it. I think this is a proposal we could all support.
Kyle Koss
-----Original Message-----
From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
Sent: March 13, 2002 9:59 AM
To: fop-dev@xml.apache.org
Subject: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging
two libraries)
Given what has been said on the mailing lists of FOP and iText, and
given
the current scope of the two projects, I feel reasonably sure that this
could be a proposal accepted by bot communities.
-------------------------------------------------------------
FOP uses iText as a PDF generation library
-------------------------------------------------------------
This could have greater benefits than a merger and keep intact the
strenghts
that these two projects have (remember AOL+Time Warner? is the result we
want?).
iText could continue to be an excellent PDF (and RTF AFAIK) generation
package with a good java API.
FOP could concentrate on FO2AreaTree and use iText as the last step.
Given the licences, nobody is prohibited to cross-collaborate. iText
developers can send patches to FOP and viceversa, and be [VOTE]d as
usual
when the time is right.
FOP can distribute iText jar as it's MPL, and both projects would
cross-link
in a clear way.
AFAIK iText is already able to produce PDF using an XML file. If FOP
could
make a transformation step from FO to this format, we could get this up
running in a short time.
And IText can also output to html, which is not bad at all.
What do you think?
Shall we pull this off?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
[PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging two libraries)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Given what has been said on the mailing lists of FOP and iText, and given
the current scope of the two projects, I feel reasonably sure that this
could be a proposal accepted by bot communities.
-------------------------------------------------------------
FOP uses iText as a PDF generation library
-------------------------------------------------------------
This could have greater benefits than a merger and keep intact the strenghts
that these two projects have (remember AOL+Time Warner? is the result we
want?).
iText could continue to be an excellent PDF (and RTF AFAIK) generation
package with a good java API.
FOP could concentrate on FO2AreaTree and use iText as the last step.
Given the licences, nobody is prohibited to cross-collaborate. iText
developers can send patches to FOP and viceversa, and be [VOTE]d as usual
when the time is right.
FOP can distribute iText jar as it's MPL, and both projects would cross-link
in a clear way.
AFAIK iText is already able to produce PDF using an XML file. If FOP could
make a transformation step from FO to this format, we could get this up
running in a short time.
And IText can also output to html, which is not bad at all.
What do you think?
Shall we pull this off?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: merging two libraries
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: <br...@lowagie.com>
> Keiron Liddle writes:
>
> >
> > That sounds like a good suggestion.
> >
> > To start with I think we should consider only this:
> > FOP behaves exactly the same but instead of having its own pdf
generation
> > code then iText is used as a library to generate pdf.
> >
> > So the questions are:
> > - is the license useable
>
> I did a little search and I found people saying that
> MPL is compatible with the Apache license and others
> saying it isn't. My main concern is that I don't want
> a license that allows my employer to prevent me from
> distributing the code I write at my work for free.
> I don't know if the Apache License is strict enough
> to ensure me that.
The Apache licen(c|s)e makes the code available for any use as long as due
credit is given.
No reference is given to availability of the source code of the
modifications.
If you modify Apache licen(c|s)e code, you can keep the modifications for
yourself, as long as you give due credit.
If the code is to ask to become an Apache project, the source code *must* be
Apache licen(c|s)e 1.1.
If not, it can be still used by FOP as a jar if the licen(c|s)e permits its
distribution with Apache software-code.
> > - is the api sufficient for FOP to use
>
> I don't know, but we can always fill the gaps.
:-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: merging two libraries
Posted by br...@lowagie.com.
Keiron Liddle writes:
>
> That sounds like a good suggestion.
>
> To start with I think we should consider only this:
> FOP behaves exactly the same but instead of having its own pdf generation
> code then iText is used as a library to generate pdf.
>
> So the questions are:
> - is the license useable
I did a little search and I found people saying that
MPL is compatible with the Apache license and others
saying it isn't. My main concern is that I don't want
a license that allows my employer to prevent me from
distributing the code I write at my work for free.
I don't know if the Apache License is strict enough
to ensure me that.
> - is the api sufficient for FOP to use
I don't know, but we can always fill the gaps.
kind regards,
Bruno
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [iText-questions] Re: merging two libraries
Posted by Keiron Liddle <ke...@aftexsw.com>.
That sounds like a good suggestion.
To start with I think we should consider only this:
FOP behaves exactly the same but instead of having its own pdf generation
code then iText is used as a library to generate pdf.
So the questions are:
- is the license useable
- is the api sufficient for FOP to use
Once this is sorted out then we can think of other areas.
On 2002.03.12 15:05 Nicola Ken Barozzi wrote:
> From: "New, Cecil (GEAE)" <ce...@ae.ge.com>
>
> > My suggestion was *not* to merge the two!
> >
> > iText is a Java API with a document creation focus. In this day and
> age,
> > XSL:FO can be viewed as just another document type - in the same way
> that
> > more proprietary or older formats are (that is, PDF, RTF, etc.).
>
> Sorry if it's a bit off-topic, but this issue is similar to the one we
> just
> managed to handle between POI (http://jakarta.apache.org/poi/) and Cocoon
> (http://xml.apache.org/cocoon/).
>
> POI is a project that makes it possible to read-write common office file
> formats in Java.
> Cocoon is an XML processing framework-server.
>
> The POI team donated a Cocoon component that uses POI and outputs XML,
> but
> on the Cocoon side, committers saw too much POI code in it.
>
> Basically we understood that a project to read-write a file format should
> have a solid Java API. Other projects can use it to produce other
> results.
> Merging is not the best solution, both for developers and users.
>
> >From this experience, I would humbly suggest that, after getting the
> licencing stuff straight, FOP could be refactored to use iText as a PDF
> generation step.
> In this way communities can focus on a smaller part of the project with
> greater efficiency, and the two products may have a much wider
> applicability
> than a single merged one.
>
> Since iText has a strong community behind it, since it would like to
> integrate code with FOP, thus coming to Apache, and since FOP could use
> part
> of it proficiently, I would like to see iText make a proposal at Jakarta
> for
> the creation of a project.
> All details for this are under
> http://jakarta.apache.org/site/newproject.html .
>
> What do you think?
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [iText-questions] Re: merging two libraries
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "New, Cecil (GEAE)" <ce...@ae.ge.com>
> My suggestion was *not* to merge the two!
>
> iText is a Java API with a document creation focus. In this day and age,
> XSL:FO can be viewed as just another document type - in the same way that
> more proprietary or older formats are (that is, PDF, RTF, etc.).
Sorry if it's a bit off-topic, but this issue is similar to the one we just
managed to handle between POI (http://jakarta.apache.org/poi/) and Cocoon
(http://xml.apache.org/cocoon/).
POI is a project that makes it possible to read-write common office file
formats in Java.
Cocoon is an XML processing framework-server.
The POI team donated a Cocoon component that uses POI and outputs XML, but
on the Cocoon side, committers saw too much POI code in it.
Basically we understood that a project to read-write a file format should
have a solid Java API. Other projects can use it to produce other results.
Merging is not the best solution, both for developers and users.
Re: [iText-questions] Re: merging two libraries
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "New, Cecil (GEAE)" <ce...@ae.ge.com>
> My suggestion was *not* to merge the two!
>
> iText is a Java API with a document creation focus. In this day and age,
> XSL:FO can be viewed as just another document type - in the same way that
> more proprietary or older formats are (that is, PDF, RTF, etc.).
Sorry if it's a bit off-topic, but this issue is similar to the one we just
managed to handle between POI (http://jakarta.apache.org/poi/) and Cocoon
(http://xml.apache.org/cocoon/).
POI is a project that makes it possible to read-write common office file
formats in Java.
Cocoon is an XML processing framework-server.
The POI team donated a Cocoon component that uses POI and outputs XML, but
on the Cocoon side, committers saw too much POI code in it.
Basically we understood that a project to read-write a file format should
have a solid Java API. Other projects can use it to produce other results.
Merging is not the best solution, both for developers and users.
>From this experience, I would humbly suggest that, after getting the
licencing stuff straight, FOP could be refactored to use iText as a PDF
generation step.
In this way communities can focus on a smaller part of the project with
greater efficiency, and the two products may have a much wider applicability
than a single merged one.
Since iText has a strong community behind it, since it would like to
integrate code with FOP, thus coming to Apache, and since FOP could use part
of it proficiently, I would like to see iText make a proposal at Jakarta for
the creation of a project.
All details for this are under
http://jakarta.apache.org/site/newproject.html .
What do you think?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org