I would judge the notion that FOP and RenderX share
common goals to be somewhat sentimental; perhaps we
should wait until Coke and Pepsi form such warm
collaborative bonds first!
At any rate, instead of "FOPResult", since we already
have an InputHandler class (and subclasses where
needed), perhap
J.Pietschmann wrote:
> Victor Mote wrote:
> > BTW, we'd better change the name of FOPResult if we're going to
> try to sell
> > this to a wider audience :-)
> abbr for FormattingObjectsProcessingResult. No need to change :-)
Just don't be surprised to see a counter-proposal RenderXResult, an ab
Victor Mote wrote:
BTW, we'd better change the name of FOPResult if we're going to try to sell
this to a wider audience :-)
abbr for FormattingObjectsProcessingResult. No need to change :-)
J.Pietschmann
-
To unsubscribe, e-mail
Jeremias Maerki wrote:
> > Except for Avalonization (which I admit I don't understand, but which I
> > understood not to be a factor here), I don't see what functionality your
> > model provides over mine. On the Avalonization issue, I guess
> the easy way
> > to get to the heart of the matter is
On 26.06.2003 21:48:10 Victor Mote wrote:
> > Then you mean reuse in the context of producing multiple output formats
> > in one renderung run?
>
> Yes. Even if we think we don't want that now, we should have the flexibility
> to add it later.
Granted. I thought about that myself. I don't see wh
J.Pietschmann wrote:
> Victor Mote wrote:
> > I don't see why you
> > would suggest that my proposal would use more memory. I am quite sure it
> > would use less, but not enough to even mention.
>
> Well, your approach to "decoupling layout and rendering" seems
> to include building a full area tr
Victor Mote wrote:
I don't see why you
would suggest that my proposal would use more memory. I am quite sure it
would use less, but not enough to even mention.
Well, your approach to "decoupling layout and rendering" seems
to include building a full area tree, or something equivalent.
FOP was imple
J.Pietschmann wrote:
> Victor Mote wrote:
> > I guess I don't
> > understand the need for FOProcessorFactory, which seems to be
> an unnecessary
> > complication for the user.
>
> It has something to do with the GoF Factory pattern. This means you can
> choose the implementation of the FOProcessor
OK, thanks for the enlightenment.
--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> Glen Mazza wrote:
> > Shouldn't we be leery of "render options" where
> one
> > specifies properties of how the output should look
> > outside of what is specified by the XSL-FO file?
>
> PDF encryption? Printer op
Jeremias Maerki wrote:
> > That is not reuse. The metadata example is a trivial one. A
> Collection of
> > Fonts used and Fonts to be embedded would be a more important
> one. However,
> > I don't care. You are correct that we aren't talking about the
> same thing.
>
> Then you mean reuse in the c
Glen Mazza wrote:
Shouldn't we be leery of "render options" where one
specifies properties of how the output should look
outside of what is specified by the XSL-FO file?
PDF encryption? Printer options? Text encoding? MIF version?
(If
there are output properties that cannot be specified
sufficie
Victor Mote wrote:
I guess I don't
understand the need for FOProcessorFactory, which seems to be an unnecessary
complication for the user.
It has something to do with the GoF Factory pattern. This means you can
choose the implementation of the FOProcessorAPI by setting a Java property,
or some simi
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> >
> > I don't understand your last statement, but I
> agree that FOPResult is a
> > better name than RenderType.
>
> Let's try different wording: The name "RenderType"
> suggests that it is a
> enumeration or a parameter, but it's more than that.
>
On 26.06.2003 20:13:06 Victor Mote wrote:
> Well, its a whole lot more than an API and there are some implementing
> classes in your spec. However, thanks for clarifying.
Only two classes (DefaultFOProcessorFactory and AvalonFOProcessorFactory)
to show how the two world can be made more or less c
Jeremias Maerki wrote:
> > I think your name is fine. I am confused about whether it is an
> interface
> > (as written) or a class (I don't see any implementations).
>
> It's an API. You don't necessarily see implementing classes in the
> specification. Compare to JAXP. Theoretically, RenderX coul
On 26.06.2003 18:40:58 Victor Mote wrote:
> Jeremias Maerki wrote:
>
> > I have done so now. I've added a new (sub)page to the Wiki to avoid
> > making the FOPAvalonization page even longer.
> >
> > http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization/AltA
> PIProposalJM
> >
> > While wr
Jeremias Maerki wrote:
> I have done so now. I've added a new (sub)page to the Wiki to avoid
> making the FOPAvalonization page even longer.
>
> http://nagoya.apache.org/wiki/apachewiki.cgi?FOPAvalonization/AltA
PIProposalJM
>
> While writing down my thought about the API I have come to the
> real
17 matches
Mail list logo
