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
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 with
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
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 u
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 IT-Engineer
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
>
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
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 interfa
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 f
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.
>.
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
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 th
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
c
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. Cocoo
From: "Bertrand Delacretaz" <[EMAIL PROTECTED]>
> On Wednesday 13 March 2002 16:58, Nicola Ken Barozzi wrote:
> >. . .
> > -
> > FOP uses iText as a PDF generation library
> >
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,
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 FO
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.
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.
A
: [EMAIL PROTECTED]
Subject: Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was:
merging two libraries)
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
: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
Sent: March 13, 2002 9:59 AM
To: [EMAIL PROTECTED]
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
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 projec
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 libr
23 matches
Mail list logo
