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
Ok, but that's a special purpose API that has (almost) nothing to do
with XSL transformation. And it's only a proprietary API because there
is no standard API for this.
On 28.06.2003 13:23:21 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > The problem with this example is that I can't think of a
Jeremias Maerki wrote:
The problem with this example is that I can't think of any reason why I
would need a Xalan-specific API (if there is still one).
Everytime you need something to do which is not in JAXP, like
using an XPath to select nodes from a DOM.
J.Pietschmann
-
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
It's not only meant to be intuitive (read: JAXP-like) but also to get
that Renderer thing into the background where it belongs IMHO. You also
don't get direct access to the serializer in JAXP, I think. This helps
decoupling the API from the inner workings which is one factor towards a
stable API.
Jeremias Maerki wrote:
I've updated the Wiki page. The parametrization (as opposed to
configuration) is done through set/getOutputProperty (also see my
comment on the Wiki page).
Hmhm. The class you vasll FOPResult and subclasses has the same
role what I called Renderer and subclasses. Your choice
On 23.06.2003 21:28:56 J.Pietschmann 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.
>
> Interesting proposal. One thing I'm still missing:
>
> > - Renderer: You guys hate me for that, I
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.
Interesting proposal. One thing I'm still missing:
- Renderer: You guys hate me for that, I know, but I still refuse to
give it so much visibility in these di
23 matches
Mail list logo
