, 2002 3:10 PM
To: [EMAIL PROTECTED]
Subject: Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was:
merging two libraries)
From: Matthias Fischer
My company, for instance, would have to stop using FOP;
we would not even take the time to go into studying legal
aspects, because, as a medium
From: Matthias Fischer [EMAIL PROTECTED]
In other terms: IMO, the legal dispositions of an open source software
shouldn't be more complex than those of their commercial competitors.
You're right.
In fact, the ASF is less complex.
The ASF distributes software that can be 100% sure to be
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
From: [EMAIL PROTECTED]
Nicola Ken Barozzi wrote:
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
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
From: Keiron Liddle [EMAIL PROTECTED]
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
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.
. . .
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
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.
Nicola Ken Barozzi wrote:
IF the integration FOP-iText is done in a way where PDF
output via iText is not just an option but a replacement
for the existing PDF output - or even for the other renderers,
too, then I'd say this step contradicts the intention
though not the letters of the
From: [EMAIL PROTECTED]
Technically, it's very tempting to do what you propose. In fact,
technically,
I'm all for it. Let's just be aware that the license problem is not only a
philosophical issue.
Of course. I think we agree.
And as for this:
This would reduce the usefulness of
FOP
If n persons are using FOP now and some
of these can no longer use FOP
because a part of FOP they need has a license they can't use, then
I'd say this reduces FOPs usefulness for
these "some" persons, despite being more useful to others. Arnd Beissner --Arnd
Beißner
From: Matthias Fischer
My company, for instance, would have to stop using FOP;
we would not even take the time to go into studying legal
aspects, because, as a medium-sized company, we
don't have the time and money and personnel to do this...
I think you are exaggerating a bit.
Are you
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
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
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
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
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
Nicola Ken Barozzi wrote:
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.
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.
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
From: Peter B. West [EMAIL PROTECTED]
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
From: Bertrand Delacretaz [EMAIL PROTECTED]
On Wednesday 13 March 2002 16:58, Nicola Ken Barozzi wrote:
. . .
-
FOP uses iText as a PDF generation library
-
. . .
23 matches
Mail list logo
