You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@greenmail.ch> on 2003/06/23 20:47:30 UTC
Alternative API proposal (was: startup refactoring)
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/AltAPIProposalJM
While writing down my thought about the API I have come to the
realization that I cannot make up my mind about the inner context
classes Victor has come up with. But I think he's quite close:
- Session: Looks like my and Jörg's FOProcessor to me. The user
interacts with this class to configure FOP and do processing runs.
- Document and RenderContext: I'm not sure but I think these two should
be merged. I've called it ProcessorContext in my proposal at first,
but then chose not to include them in the proposal right now because
I didn't quite know what to put in there. The thing I know is that we
need a central data object that keeps references while the FOProcessor
implementation coordinates the processing (data separated from logic).
- Renderer: You guys hate me for that, I know, but I still refuse to
give it so much visibility in these discussions. In my proposal I've
separated the logic from the data again (with JAXP as role-model) and
made the Renderer a totally normal Avalon service that is being looked
up by MIME type in the background. The FOPResult classes account for
the differences of output types. The FOProcessor impl is responsible
to establish the link between FOPResults and Renderer. For AWT (I'd
like to call it Java2D from now on if you guys agree. That's the
official name of the API after all.) I've tried to introduce an
interface that clients can use to interact with the Java2D renderer.
So, I don't have anything more concrete on the inner "glue" that keeps
the whole process together but maybe my proposal brings some new ideas.
I'd like to hear your thoughts about my proposal (flaws, nodding,
missing things etc.).
I hope that we can find a common path for the whole thing. Important to
me is to have a good terminology and an API that conforms to the
requirements I've written down on the FOPAvalonization page.
Side note WRT resolvers: I've only placed the SourceResolver in the API
because I think that the other resolvers are not necessary. I'm not
certain about that but this can be easily added later.
On 20.06.2003 21:40:09 Jeremias Maerki wrote:
>
> On 20.06.2003 21:34:28 J.Pietschmann wrote:
> > Could you outline your API ideas on the Wiki?
>
> Yes, please. I'm also in the process of writing down my ideas. That way
> it will be much easier to relate everyone's ideas to each other. At the
> moment I wish we could all sit together and figure it out by talking
> together and painting on a whiteboard. The Wiki will have to suffice I
> guess.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Alternative API proposal
Posted by Jeremias Maerki <de...@greenmail.ch>.
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.
On 24.06.2003 21:40:54 J.Pietschmann wrote:
> Hmhm. The class you vasll FOPResult and subclasses has the same
> role what I called Renderer and subclasses. Your choice may be
> more intuitive for many people.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Alternative API proposal
Posted by "J.Pietschmann" <j3...@yahoo.de>.
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 may be
more intuitive for many people.
> TraX has setOutputProperty on the Transformer.
Well, TrAX' output properties is a set of keyed properties each
with a relatively fixed set of cvalues...
J.Pietschman
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Alternative API proposal
Posted by Jeremias Maerki <de...@greenmail.ch>.
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 know, but I still refuse to
> > give it so much visibility in these discussions.
> Suppose the PDFRenderer a set of encryption options, as obtained from
> the request in a web service environment (or the text renderer is
> supposed to use the output encoding specified by the request). This
> is parametrization, not configuration, and in any case not as easy
> to press through a configure(File) or configure(InputStream).
>
> Could you add an example how this would be handled in your proposal?
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). TraX has setOutputProperty on the Transformer.
I've moved it to the Result class because that's the more intuitive
place for me.
> > Side note WRT resolvers: I've only placed the SourceResolver in the API
> > because I think that the other resolvers are not necessary. I'm not
> > certain about that but this can be easily added later.
>
> Image and font resolvers are needed as hooks for users who want to
> have their own caching implementation or want to implement metrics
> access for fonts mapping to several odd files in all kind of even more
> odd places. However, they can be implemented as Avalon services too.
Right. I think I'm not wanting to much if I let someone, who wants
advanced functionality, implement an Avalon service and register it in
the main configuration file. Day-to-day usage is covered by the API,
special behaviour through the Avalon container.
> And, well, the hyphenator is also a good Avalon service...
I guess so.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Xalan API was Re: Alternative API proposal
Posted by Jeremias Maerki <de...@greenmail.ch>.
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 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.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Xalan API was Re: Alternative API proposal
Posted by "J.Pietschmann" <j3...@yahoo.de>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Alternative API proposal (was: startup refactoring)
Posted by Glen Mazza <gr...@yahoo.com>.
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), perhaps we should call it OutputHandler?
Glen
--- "J.Pietschmann" <j3...@yahoo.de> 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 :-)
>
> J.Pietschmann
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> fop-dev-unsubscribe@xml.apache.org
> For additional commands, email:
> fop-dev-help@xml.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Alternative API proposal (was: startup refactoring)
Posted by Victor Mote <vi...@outfitr.com>.
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 abbr
for:
Really Exciting Newly Designed Eclectic Renderer for XML Result :-)
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Alternative API proposal (was: startup refactoring)
Posted by "J.Pietschmann" <j3...@yahoo.de>.
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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Alternative API proposal (was: startup refactoring)
Posted by Victor Mote <vi...@outfitr.com>.
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 to simply ask whether
> Avalonization can
> > be implemented with the model I have proposed or not.
>
> I can't answer that because I have the impression that your proposal is
> incomplete. What I'm missing:
> - How to specify output properties like encryption parameters
> - How to handle Java2D?
> - How to handle SAX input?
> - How to handle FOP configuration?
My proposal was not contemplating any significant changes to any of these.
Encryption parameters would be stored/set in the FOPResult object (I've
adopted your terms here even though the concepts might be a bit off -- I
don't know whether that is more or less confusing). Java2D would be a
FOPResult option, which would drive the creation of a RenderContext object
to handle the AreaTree creation for that scheme. SAX input would be handled
as it is now. FOP configuration would be handled as it is now, except for
the changes to the object model. Perhaps I am not catching the intent of
your questions?
> > This implies (and makes sense when you
> > think about interfaces) that it is a lowest-common-denominator.
>
> Yes, but holding that open for extensions:
> - Ability to add new subclasses of FOPResult which only certain
> implementations support.
> - Ability to pass in special output property objects to control special
> features.
OK. One that is on the top of my mind is pluggable layout aka
LayoutStrategy. Please walk me briefly through how that might work at the
API level, considering that other implementations might not want/need such a
thing, and how to handle defaults. What I am really grappling with here is
whether you build such a concept into a shared, industry-wide API, or treat
it as an extension, and if it is an extension, what the ramifications are,
especially to those using the API. Specifically, if the outer shell of the
API doesn't handle the extension, don't you end up kind of building (via
subclassing or whatever) a separate API underneath the outer shell that is
FOP-specific?
(BTW, the above paragraph is not asking anyone to endorse the idea of
pluggable layout, but simply using the concept as a specific example of the
type of thing that we might want to have the flexibility to handle).
> > There may be
> > times when, to get the full richness of an implementation, you
> have to use
> > things that are specific to it because the higher-level
> interface couldn't
> > and shouldn't force all implementations to implement that
> feature. FOP and
> > RenderX might (and probably already have) evolve(d) to meet different
> > use-cases. So it makes sense to me to use a simple lightweight
> API for FOP
> > (if possible), and if we want to build an industry-standard API
> like that
> > which you have proposed, that it be done in a separate project
> or at least
> > package, and probably be done in concurrence with the other
> implementors.
>
> You're right again. But then it happens that a good API gets adopted by
> other parties. At any rate I'll gladly participate in formulating a
> standard API as a separate project as my time allows it.
If there are any changes to the one that we propose, then we *must* change
our API in order to meet it (one of the things we have specifically said we
don't want to do), or not be compliant. And I don't think we want to wait
for such a process anyway.
> RenderX guys: If you're listening in, I'd like to hear your thoughts
> about having/creating a common client API for XSL-FO processing in Java.
BTW, we'd better change the name of FOPResult if we're going to try to sell
this to a wider audience :-)
> The biggest difference probably arises from your focus on the inner glue
> and my focus on the client API. Your thoughts are very valuable but they
> should evolve in the context of the inner glue because that's where you
> invested most of your brain time, I guess.
That's fair. I see the API as a function of the object model, and think the
best way to assure a stable API is to get the object model to better match
our processing needs. To the extent that the layer of API objects that you
have designed meets that end, I think we'll be OK.
If you and Joerg are satisfied that there are no major gotchas lurking, I am
quite happy to follow along.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Alternative API proposal (was: startup refactoring)
Posted by Jeremias Maerki <de...@greenmail.ch>.
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 why my API proposal
couldn't be enhanced (later), for example, with a MultipleFOPResult that
contains/holds a list of FOPResults. That would be a
backwards-compatible and even quite intuitive (See GoF Composite) way to
handle the case.
> 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 to simply ask whether Avalonization can
> be implemented with the model I have proposed or not.
I can't answer that because I have the impression that your proposal is
incomplete. What I'm missing:
- How to specify output properties like encryption parameters
- How to handle Java2D?
- How to handle SAX input?
- How to handle FOP configuration?
On the other side, it doesn't matter so much. I think it is important to
separate the inner glue from the client interface, so to isolate FOP's
Avalon container (or whatever we will use/do) from its environment so
FOP provides a blackbox interface to the outside. Only in the
Cocoon-context should there be a possibility to pass in a parent
ServiceManager so FOP can use Cocoon's SourceResolver, parser factories
etc. Your proposal can probably be made to handle that.
> I did have one afterthought that I think I should mention. The JAXP thing
> caught me a bit off-guard, and I only just now sorted out in my mind why. I
> don't use these tools often enough or in enough detail to keep this fresh in
> my mind (but I think I have the concepts straight), so please correct me if
> I am wrong. If I want to use Xalan, for example, I could use a Xalan
> interface, or I could use a Xalan implementation of the JAXP interface.
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). Xalan-1 had a
proprietary one. That got deprecated with the arrival of TraX/JAXP. But
my statement is not really based on extensive research. Maybe there ARE
use cases.
> You
> mentioned in an earlier posting that the functionality between the two
> didn't necessarily need to match up.
Right, but it should be avoided to have two different client APIs
because you will have to maintain and more importantly support them.
> This implies (and makes sense when you
> think about interfaces) that it is a lowest-common-denominator.
Yes, but holding that open for extensions:
- Ability to add new subclasses of FOPResult which only certain
implementations support.
- Ability to pass in special output property objects to control special
features.
> There may be
> times when, to get the full richness of an implementation, you have to use
> things that are specific to it because the higher-level interface couldn't
> and shouldn't force all implementations to implement that feature. FOP and
> RenderX might (and probably already have) evolve(d) to meet different
> use-cases. So it makes sense to me to use a simple lightweight API for FOP
> (if possible), and if we want to build an industry-standard API like that
> which you have proposed, that it be done in a separate project or at least
> package, and probably be done in concurrence with the other implementors.
You're right again. But then it happens that a good API gets adopted by
other parties. At any rate I'll gladly participate in formulating a
standard API as a separate project as my time allows it.
RenderX guys: If you're listening in, I'd like to hear your thoughts
about having/creating a common client API for XSL-FO processing in Java.
> That would be my preference, but I do not feel strongly enough about it to
> do much more than mention it. I think this distinction probably also
> explains the different wavelengths that we seem to be on.
The biggest difference probably arises from your focus on the inner glue
and my focus on the client API. Your thoughts are very valuable but they
should evolve in the context of the inner glue because that's where you
invested most of your brain time, I guess.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Alternative API proposal (was: startup refactoring)
Posted by Victor Mote <vi...@outfitr.com>.
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 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.
> > Hmmm. The whole thing seems pretty heavyweight to me (at least
> compared to
> > my proposal). Since my real interest is Control and not API, I think the
> > most productive thing for me to do is to simply defer on the
> API issues to
> > those of you who care more about them. As long as we can build whatever
> > Control infrastructure under that API that we want to (and it
> looks like we
> > can), and if you guys are happy with the API, we can defer that
> part of the
> > discussion until another day. It may very well be that when I
> see how your
> > vision is implemented, I will find the Control structures that
> (I think) I
> > need and that we are done anyway.
>
> I think we're getting in the right direction. I think, my API proposal
> would enable a stable API and you can concentrate on what's necessary to
> do inside FOP to handle the whole processing. You can even experiment
> over time, changing the inner glue without changing the API. And a
> stable and flexible API is one of the most important things to me. We
> changed the Driver class too many times. Hopefully, my proposal could
> improve this. Just trying to decouple...
I suspect that the reason the Driver class had to change so often is that it
was doing duty for three different hierarchical concepts by my count. As
long as we have all three of them accounted for with your proposal, I'm OK
with it (although see one afterthought see below).
> But I disagree with the heavyweight thing. It's only the most necessary
> things well separated by topic. Expand on your proposal to enable all
> the functionality my proposal covers. I wonder how lightweight yours
> stays.
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 to simply ask whether Avalonization can
be implemented with the model I have proposed or not.
I did have one afterthought that I think I should mention. The JAXP thing
caught me a bit off-guard, and I only just now sorted out in my mind why. I
don't use these tools often enough or in enough detail to keep this fresh in
my mind (but I think I have the concepts straight), so please correct me if
I am wrong. If I want to use Xalan, for example, I could use a Xalan
interface, or I could use a Xalan implementation of the JAXP interface. You
mentioned in an earlier posting that the functionality between the two
didn't necessarily need to match up. This implies (and makes sense when you
think about interfaces) that it is a lowest-common-denominator. There may be
times when, to get the full richness of an implementation, you have to use
things that are specific to it because the higher-level interface couldn't
and shouldn't force all implementations to implement that feature. FOP and
RenderX might (and probably already have) evolve(d) to meet different
use-cases. So it makes sense to me to use a simple lightweight API for FOP
(if possible), and if we want to build an industry-standard API like that
which you have proposed, that it be done in a separate project or at least
package, and probably be done in concurrence with the other implementors.
That would be my preference, but I do not feel strongly enough about it to
do much more than mention it. I think this distinction probably also
explains the different wavelengths that we seem to be on.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Alternative API proposal (was: startup refactoring)
Posted by Glen Mazza <gr...@yahoo.com>.
OK, thanks for the enlightenment.
--- "J.Pietschmann" <j3...@yahoo.de> 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 options? Text encoding? MIF
> version?
>
>
> > (If
> > there are output properties that cannot be
> specified
> > sufficiently by XSL-FO 1.0, well, that's what FOP
> > extensions or XSL-FO 2.0 would be for, correct?)
>
> I don't think the WG will accept output format
> specific stuff in
> the FO source. I personally don't think this is a
> good idea either.
>
> J.Pietschmann
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Alternative API proposal (was: startup refactoring)
Posted by "J.Pietschmann" <j3...@yahoo.de>.
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
> sufficiently by XSL-FO 1.0, well, that's what FOP
> extensions or XSL-FO 2.0 would be for, correct?)
I don't think the WG will accept output format specific stuff in
the FO source. I personally don't think this is a good idea either.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Alternative API proposal (was: startup refactoring)
Posted by Glen Mazza <gr...@yahoo.com>.
--- Jeremias Maerki <de...@greenmail.ch> 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.
>
Errr...I may not understand everything here, but
aren't our inputs *just*:
1) xsl-fo stream (file, DOM Document, or inputStream)
2) render type (*is* either an enumeration directly,
or could be represented as such--PDF, PS, etc.)
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? (If
there are output properties that cannot be specified
sufficiently by XSL-FO 1.0, well, that's what FOP
extensions or XSL-FO 2.0 would be for, correct?)
Just curious what others are thinking here.
Glen
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Alternative API proposal (was: startup refactoring)
Posted by Jeremias Maerki <de...@greenmail.ch>.
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 compatible.
> OK, so FOProcessorFactory is roughly equivalent to Session and FOProcessor
> is roughly equivalent to Document (I don't care about the terminology, I'm
> just trying to find where we thinking the same and where we are not).
I guess so.
> > Of course, it can be reused. Nothing prevents you from passing in the
> > same DocumentMetadata into the FOPResult. But nobody will want to do
> > that anyway because metadata like "title" will probably change with each
> > document being processed. I think we don't talk about the same thing.
>
> 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 context of producing multiple output formats
in one renderung run?
> > Right. but I think RenderType is not the right name for this because it
> > only suggests to be information about which renderer is to be used. It
> > omits all the nice parameters you want to pass over.
>
> 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.
> Hmmm. The whole thing seems pretty heavyweight to me (at least compared to
> my proposal). Since my real interest is Control and not API, I think the
> most productive thing for me to do is to simply defer on the API issues to
> those of you who care more about them. As long as we can build whatever
> Control infrastructure under that API that we want to (and it looks like we
> can), and if you guys are happy with the API, we can defer that part of the
> discussion until another day. It may very well be that when I see how your
> vision is implemented, I will find the Control structures that (I think) I
> need and that we are done anyway.
I think we're getting in the right direction. I think, my API proposal
would enable a stable API and you can concentrate on what's necessary to
do inside FOP to handle the whole processing. You can even experiment
over time, changing the inner glue without changing the API. And a
stable and flexible API is one of the most important things to me. We
changed the Driver class too many times. Hopefully, my proposal could
improve this. Just trying to decouple...
But I disagree with the heavyweight thing. It's only the most necessary
things well separated by topic. Expand on your proposal to enable all
the functionality my proposal covers. I wonder how lightweight yours
stays.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Alternative API proposal (was: startup refactoring)
Posted by Victor Mote <vi...@outfitr.com>.
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 could implement
> the same API and we would have a common API for XSL-FO processing. It
> would even be interesting to do an implementation of that API based on
> the maintenance branch. It would probably not support all the features
> but JAXP implementations also don't do that always.
Well, its a whole lot more than an API and there are some implementing
classes in your spec. However, thanks for clarifying.
> > I guess I don't
> > understand the need for FOProcessorFactory, which seems to be
> an unnecessary
> > complication for the user. Since I don't understand Avalon, I
> am not sure
> > how factoring it into/out of this affects the API, but if that
> is needed, it
> > seems like it should be done in an implementation of
> FOProcessor instead of
> > creating separate Factories.
>
> It's not an Avalon-specific reason why I specified the factory. For one,
> it's almost the same as in JAXP (The whole API is, BTW). The distinction
> between FOProcessorFactory and FOProcessor is the following:
>
> FOProcessorFactory has a configuration (where do the fonts come from,
> what's the caching strategy etc.etc.). You will want to have one such
> object per environment where FOP is used.
>
> FOProcessor could be argued to be superfluous if it weren't for the
> add/removeEventListener methods which allow you to register a listener
> to get events on a particular processing run (start page-sequence, new
> page, content clipped, end page-sequence, this kind of things). I
> haven't come up with more, yet, but I can imagine that this class could
> get additional methods later.
>
> Basically you distiguish the basic environment from the processor run.
> You wouldn't want to reload all the configuration stuff each time you
> want to run FOP.
OK, so FOProcessorFactory is roughly equivalent to Session and FOProcessor
is roughly equivalent to Document (I don't care about the terminology, I'm
just trying to find where we thinking the same and where we are not).
> > RenderContext is only useful if you are trying to reuse an AreaTree for
> > multiple output options. I am frankly confused right now about
> whether the
> > dev team even wants to try to do that.
>
> From the first discussion we had I got the impression that it's not
> worth the pains right now. In the worst case you simply hold the stuff
> from RenderContext in the ProcessorContext.
OK. Since it doesn't affect the API, we can always add it back later if
needed.
> > I think it is a good idea, and
> > suspect that whatever difficulties have existed in implementing
> this in the
> > past are probably a result of our current tight coupling between FOTree,
> > layout, AreaTree, and Rendering, which is of course what I am trying to
> > unravel.
> >
> > Your DocumentMetadata class holds information in it that would
> live in my
> > Document concept. That is information that is common to (but
> not necessarily
> > used by) by all output media, and does not need to be set for
> each output
> > media. It looks like you are pushing the data that I envisioned
> in Document
> > and RenderContext down to RenderType/FOPResult. The net effect
> is that it
> > can't be reused.
>
> Of course, it can be reused. Nothing prevents you from passing in the
> same DocumentMetadata into the FOPResult. But nobody will want to do
> that anyway because metadata like "title" will probably change with each
> document being processed. I think we don't talk about the same thing.
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.
> As I said before, what I'm trying to do is separate the inner workings
> from the API as well as possible. Things from FOPResult (including the
> metadata) will probably be placed in the RenderContext so you'll have
> access to it if necessary. I see DocumentMetadata only as a pass-through
> thing to the Renderer.
>
> > > - Renderer: You guys hate me for that, I know, but I still refuse to
> > > give it so much visibility in these discussions. In my proposal I've
> > > separated the logic from the data again (with JAXP as
> role-model) and
> > > made the Renderer a totally normal Avalon service that is
> being looked
> > > up by MIME type in the background. The FOPResult classes account for
> > > the differences of output types. The FOProcessor impl is responsible
> > > to establish the link between FOPResults and Renderer. For AWT (I'd
> > > like to call it Java2D from now on if you guys agree. That's the
> > > official name of the API after all.) I've tried to introduce an
> > > interface that clients can use to interact with the Java2D renderer.
> >
> > Your FOPResult is I think roughly equivalent to what I am
> calling RenderType
> > or Renderer (somewhere along the way, I started calling mine
> RenderType to
> > make a more clear distinction between it and the workhorse
> Renderers), and
> > if I understand what you are doing, I think our goals are the same.
> > FOPResult is more of a control class, and the Renderer is a
> workhorse class.
>
> Right. but I think RenderType is not the right name for this because it
> only suggests to be information about which renderer is to be used. It
> omits all the nice parameters you want to pass over.
I don't understand your last statement, but I agree that FOPResult is a
better name than RenderType.
> > > So, I don't have anything more concrete on the inner "glue" that keeps
> > > the whole process together but maybe my proposal brings some
> new ideas.
> > > I'd like to hear your thoughts about my proposal (flaws, nodding,
> > > missing things etc.).
> > >
> > > I hope that we can find a common path for the whole thing.
> Important to
> > > me is to have a good terminology and an API that conforms to the
> > > requirements I've written down on the FOPAvalonization page.
> >
> > Here are the issues that I am still uncomfortable with:
> > 1. complexity. In addition to the Factory issue already
> mentioned, I think
> > there is some benefit to arranging the data more intuitively
> for the user.
> > From the user's standpoint, there is input and output (ie. 2
> classes). It
> > makes sense to have a third (Session/FOProcessor) primarily to
> facilitate
> > reuse. IMO, if the user has to interact with more than 3
> classes to get the
> > work done, we are unnecessarily complex. (My 4th class,
> RenderContext, is
> > not exposed to the user).
>
> As I said, it's the same as JAXP. I don't see why people will have
> problem with that. It's a clean separation into input, output, setup and
> hook into the processing run.
OK.
> > 2. reuse. I see no downside to arranging our objects to allow
> reuse, even if
> > we decide we don't want to facilitate it. This doesn't directly
> affect the
> > API (we can have 15 or 50 classes supporting those exposed to the user).
>
> The only thing I would reuse in my API is the factory instance because
> this is the place where the Avalon Container would sit and which would
> manage all the inner services. The image cache service for example.
> Per-processing-run caching would be hooked into the ProcessorContext.
> It's the FOProcessorFactory implementation that will be heavy-weight,
> the rest is all light-weight.
Hmmm. The whole thing seems pretty heavyweight to me (at least compared to
my proposal). Since my real interest is Control and not API, I think the
most productive thing for me to do is to simply defer on the API issues to
those of you who care more about them. As long as we can build whatever
Control infrastructure under that API that we want to (and it looks like we
can), and if you guys are happy with the API, we can defer that part of the
discussion until another day. It may very well be that when I see how your
vision is implemented, I will find the Control structures that (I think) I
need and that we are done anyway.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Alternative API proposal (was: startup refactoring)
Posted by Jeremias Maerki <de...@greenmail.ch>.
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 writing down my thought about the API I have come to the
> > realization that I cannot make up my mind about the inner context
> > classes Victor has come up with. But I think he's quite close:
> >
> > - Session: Looks like my and Jörg's FOProcessor to me. The user
> > interacts with this class to configure FOP and do processing runs.
>
> 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 could implement
the same API and we would have a common API for XSL-FO processing. It
would even be interesting to do an implementation of that API based on
the maintenance branch. It would probably not support all the features
but JAXP implementations also don't do that always.
> I guess I don't
> understand the need for FOProcessorFactory, which seems to be an unnecessary
> complication for the user. Since I don't understand Avalon, I am not sure
> how factoring it into/out of this affects the API, but if that is needed, it
> seems like it should be done in an implementation of FOProcessor instead of
> creating separate Factories.
It's not an Avalon-specific reason why I specified the factory. For one,
it's almost the same as in JAXP (The whole API is, BTW). The distinction
between FOProcessorFactory and FOProcessor is the following:
FOProcessorFactory has a configuration (where do the fonts come from,
what's the caching strategy etc.etc.). You will want to have one such
object per environment where FOP is used.
FOProcessor could be argued to be superfluous if it weren't for the
add/removeEventListener methods which allow you to register a listener
to get events on a particular processing run (start page-sequence, new
page, content clipped, end page-sequence, this kind of things). I
haven't come up with more, yet, but I can imagine that this class could
get additional methods later.
Basically you distiguish the basic environment from the processor run.
You wouldn't want to reload all the configuration stuff each time you
want to run FOP.
A nice side-effect is the AvalonFOProcessorFactory that should fit nicely
as an component for use in Avalon-enabled system (mainly Cocoon).
> > - Document and RenderContext: I'm not sure but I think these two should
> > be merged. I've called it ProcessorContext in my proposal at first,
> > but then chose not to include them in the proposal right now because
> > I didn't quite know what to put in there. The thing I know is that we
> > need a central data object that keeps references while the FOProcessor
> > implementation coordinates the processing (data separated from logic).
>
> RenderContext is only useful if you are trying to reuse an AreaTree for
> multiple output options. I am frankly confused right now about whether the
> dev team even wants to try to do that.
From the first discussion we had I got the impression that it's not
worth the pains right now. In the worst case you simply hold the stuff
from RenderContext in the ProcessorContext.
> I think it is a good idea, and
> suspect that whatever difficulties have existed in implementing this in the
> past are probably a result of our current tight coupling between FOTree,
> layout, AreaTree, and Rendering, which is of course what I am trying to
> unravel.
>
> Your DocumentMetadata class holds information in it that would live in my
> Document concept. That is information that is common to (but not necessarily
> used by) by all output media, and does not need to be set for each output
> media. It looks like you are pushing the data that I envisioned in Document
> and RenderContext down to RenderType/FOPResult. The net effect is that it
> can't be reused.
Of course, it can be reused. Nothing prevents you from passing in the
same DocumentMetadata into the FOPResult. But nobody will want to do
that anyway because metadata like "title" will probably change with each
document being processed. I think we don't talk about the same thing.
As I said before, what I'm trying to do is separate the inner workings
from the API as well as possible. Things from FOPResult (including the
metadata) will probably be placed in the RenderContext so you'll have
access to it if necessary. I see DocumentMetadata only as a pass-through
thing to the Renderer.
> > - Renderer: You guys hate me for that, I know, but I still refuse to
> > give it so much visibility in these discussions. In my proposal I've
> > separated the logic from the data again (with JAXP as role-model) and
> > made the Renderer a totally normal Avalon service that is being looked
> > up by MIME type in the background. The FOPResult classes account for
> > the differences of output types. The FOProcessor impl is responsible
> > to establish the link between FOPResults and Renderer. For AWT (I'd
> > like to call it Java2D from now on if you guys agree. That's the
> > official name of the API after all.) I've tried to introduce an
> > interface that clients can use to interact with the Java2D renderer.
>
> Your FOPResult is I think roughly equivalent to what I am calling RenderType
> or Renderer (somewhere along the way, I started calling mine RenderType to
> make a more clear distinction between it and the workhorse Renderers), and
> if I understand what you are doing, I think our goals are the same.
> FOPResult is more of a control class, and the Renderer is a workhorse class.
Right. but I think RenderType is not the right name for this because it
only suggests to be information about which renderer is to be used. It
omits all the nice parameters you want to pass over.
> > So, I don't have anything more concrete on the inner "glue" that keeps
> > the whole process together but maybe my proposal brings some new ideas.
> > I'd like to hear your thoughts about my proposal (flaws, nodding,
> > missing things etc.).
> >
> > I hope that we can find a common path for the whole thing. Important to
> > me is to have a good terminology and an API that conforms to the
> > requirements I've written down on the FOPAvalonization page.
>
> Here are the issues that I am still uncomfortable with:
> 1. complexity. In addition to the Factory issue already mentioned, I think
> there is some benefit to arranging the data more intuitively for the user.
> From the user's standpoint, there is input and output (ie. 2 classes). It
> makes sense to have a third (Session/FOProcessor) primarily to facilitate
> reuse. IMO, if the user has to interact with more than 3 classes to get the
> work done, we are unnecessarily complex. (My 4th class, RenderContext, is
> not exposed to the user).
As I said, it's the same as JAXP. I don't see why people will have
problem with that. It's a clean separation into input, output, setup and
hook into the processing run.
> 2. reuse. I see no downside to arranging our objects to allow reuse, even if
> we decide we don't want to facilitate it. This doesn't directly affect the
> API (we can have 15 or 50 classes supporting those exposed to the user).
The only thing I would reuse in my API is the factory instance because
this is the place where the Avalon Container would sit and which would
manage all the inner services. The image cache service for example.
Per-processing-run caching would be hooked into the ProcessorContext.
It's the FOProcessorFactory implementation that will be heavy-weight,
the rest is all light-weight.
> Sorry to be so slow responding.
No need, happens to me, too.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Alternative API proposal
Posted by "J.Pietschmann" <j3...@yahoo.de>.
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 discussions.
Suppose the PDFRenderer a set of encryption options, as obtained from
the request in a web service environment (or the text renderer is
supposed to use the output encoding specified by the request). This
is parametrization, not configuration, and in any case not as easy
to press through a configure(File) or configure(InputStream).
Could you add an example how this would be handled in your proposal?
> Side note WRT resolvers: I've only placed the SourceResolver in the API
> because I think that the other resolvers are not necessary. I'm not
> certain about that but this can be easily added later.
Image and font resolvers are needed as hooks for users who want to
have their own caching implementation or want to implement metrics
access for fonts mapping to several odd files in all kind of even more
odd places. However, they can be implemented as Avalon services too.
And, well, the hyphenator is also a good Avalon service...
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
AW: Alternative API proposal (was: startup refactoring)
Posted by "J.U. Anderegg" <ha...@bluewin.ch>.
> J.Pietschmann wrote
> I think we have a few slightly more pressing problems:
> - improving the API to ease embedding (including Java2D embedding)
What has to be embedded?
> Adding multiple output streams is certainly fun but I suspect the
> bulk of the current users would be more interested in one of the
> points above. And somehow I have the feeling that your approach could
> easily get in the way, in particular I wouldn't like if it would
> *increase* memory usage in general.
Multiple output streams are here with FOP 0.x.x
The AWT viewer uses the area tree as page cache and it's print function
again.
I'm experimenting with a new Graphics2D renderer. The attached description
gives some hints to configuration/parametrization requirements. Directions,
orientations, i18n will be the next topics. All I know at the time is that
present renderers need heavy upgrades.
Hansuli Anderegg
RE: Alternative API proposal (was: startup refactoring)
Posted by Victor Mote <vi...@outfitr.com>.
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 tree, or something equivalent.
> FOP was implemented this way before 0.20.1. What you might see
> as "tight coupling" is the result of improving the situation.
I have been misunderstood somewhere. There may be times when building a full
area tree (and writing to disk if necessary) is appropriate, esp. if it were
going to be reused. That is a dead issue. If the area tree is only used
once, then PageSequence is the largest chunk that might need to be built,
and then only if patient processing is used. I do not intend to force anyone
to do anything different than is now done in terms of how memory is managed,
or even the general flow of the processing. What I am asking for is that
control of those decisions be made at a higher level, which keeps the code
modular and gives us more options. I don't want layout starting the process
of rendering a page, but rather to notify the control mechanism that a page
is ready, and letting the control mechanism decide whether to cache it,
render it, whether that should be done in a separate thread, etc. IOW the
performance "smarts" are in the high-level control objects.
I'm sorry if that was not clear before.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Alternative API proposal (was: startup refactoring)
Posted by "J.Pietschmann" <j3...@yahoo.de>.
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 implemented this way before 0.20.1. What you might see
as "tight coupling" is the result of improving the situation.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [PATCH] fop's resource.xml
Posted by Clay Leeds <cl...@medata.com>.
Victor,
On 6/27/2003 12:35 PM, Victor Mote wrote:
> Double-check the WinCVS MacCVS page to see if they have a later version. I
> am actually running a beta version of WinCVS, and seeing no known problems.
I'm using MacCvsX (which appears to be different from MacCVS ;( ). It
took a bit to get it running (mainly permissions issues), but it's
working. If it's all the same to you, I'll keep using MacCvsX... (That's
not to say I won't try to get MacCVS working, though).
> Try 'man diff'. CVS is largely "just" a wrapper around RCS and diff, so you
> should *generally* be able to use the diff doc.
Ahhh... --unified It looks like I can do it from the command line, now
that I know a bit more how it works...
> If MacCVS works like WinCVS, there is a command-line console available that
> has CVS built into it, even if the OS doesn't have natively.
I saw a command-line utility when I was first playing around with it.
I'm having trouble finding it again... I'll keep looking.
;-0
--
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: [PATCH] fop's resource.xml
Posted by Victor Mote <vi...@outfitr.com>.
Clay Leeds wrote:
> I'm launching MacCvsX as we speak (I don't run WinCVS ;-p). I just
> checked and unfortunately, "Unified diff" is not an option. I thought I
Double-check the WinCVS MacCVS page to see if they have a later version. I
am actually running a beta version of WinCVS, and seeing no known problems.
> could run it from the command line if you give me the command to run,
> but nope, it won't work... I did a 'man cvs' and /Unified showed
> "Pattern not found". Any ideas? I think I'll just do my edits onesy,
Try 'man diff'. CVS is largely "just" a wrapper around RCS and diff, so you
should *generally* be able to use the diff doc.
If MacCVS works like WinCVS, there is a command-line console available that
has CVS built into it, even if the OS doesn't have natively.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [PATCH] fop's resource.xml
Posted by Clay Leeds <cl...@medata.com>.
On 6/27/2003 10:33 AM, Victor Mote wrote:
> The only problem I saw with the DIFF file was that it was not in "unified"
> format, which helps the patch programs find the context more easily. On the
> one that you submitted, it didn't matter because it was easier to
> cut-and-paste than to run patch anyway. If you are using WinCVS, I know that
> the newer versions have a checkbox on the diff page for "Unified diff",
> which you will want to select.
I'm launching MacCvsX as we speak (I don't run WinCVS ;-p). I just
checked and unfortunately, "Unified diff" is not an option. I thought I
could run it from the command line if you give me the command to run,
but nope, it won't work... I did a 'man cvs' and /Unified showed
"Pattern not found". Any ideas? I think I'll just do my edits onesy,
twosy and send you each edit separately. I doubt there'll be many. Any
that happen to be "large" we'll probably have a discussion about on
fop-dev in advance anyway, so you'll know it's coming.
> Enhancement is fine, unless there is a specific category for Doc.
"Doc" is not an option in the "Severity" menu, but it is under the
"Component" menu. I'll choose "Enhancement" instead of "minor" for
Severity if that's what you prefer...
;-p
--
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: [PATCH] fop's resource.xml
Posted by Victor Mote <vi...@outfitr.com>.
Clay Leeds wrote:
> Thanks. So essentially, I did everything correctly except I didn't open
> a new bugzilla item, and put '[PATCH]' at the beginning of the SUMMARY.
> I'll do that next time. I'll then attach the DIFF file (were there any
> problems with that DIFF file?). Since much of what I'll be doing will be
The only problem I saw with the DIFF file was that it was not in "unified"
format, which helps the patch programs find the context more easily. On the
one that you submitted, it didn't matter because it was easier to
cut-and-paste than to run patch anyway. If you are using WinCVS, I know that
the newer versions have a checkbox on the diff page for "Unified diff",
which you will want to select.
> (hopefully) improving the web site, Platform will be 'All'. As for
> Severity, would you prefer I indicate "Enhancement", or stick with my
> own assessment to severity (most would end up being 'minor' as
> 'nit-picking' is not an option ;-p).
Enhancement is fine, unless there is a specific category for Doc.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [PATCH] fop's resource.xml
Posted by Clay Leeds <cl...@medata.com>.
On 6/27/2003 8:17 AM, Victor Mote wrote:
> Thanks for the patch. The instructions are here:
> http://xml.apache.org/fop/dev/index.html#patches
Thanks. So essentially, I did everything correctly except I didn't open
a new bugzilla item, and put '[PATCH]' at the beginning of the SUMMARY.
I'll do that next time. I'll then attach the DIFF file (were there any
problems with that DIFF file?). Since much of what I'll be doing will be
(hopefully) improving the web site, Platform will be 'All'. As for
Severity, would you prefer I indicate "Enhancement", or stick with my
own assessment to severity (most would end up being 'minor' as
'nit-picking' is not an option ;-p).
--
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: [PATCH] fop's resource.xml
Posted by Victor Mote <vi...@outfitr.com>.
Clay Leeds wrote:
> Forgive my newbie-ness here, but I'm having problems figuring out how
> to send this [patch] in. I'm sending it here... Please enlighten me
> (gently ;-p) so that next time I'm doing it as efficiently as possible.
> Thanks!
Thanks for the patch. The instructions are here:
http://xml.apache.org/fop/dev/index.html#patches
> PATCH INFO:
> The info for XPath is missing the fact that it's pretty much Windows IE
> 5+ only (requires MSXML 3.0). However, it's still a really useful tool!
> It'd be nice if it could be re-engineered to be cross-platform!
I modified (and applied) the patch to say something like "Requires Internet
Explorer 5+". IMO, comments like this are in a gray area -- if they do
change their product to be cross-platform, we're out-of-date. In spite of
the relative inconvenience to the user, it is almost better for them to find
this out by following the link.
Thanks for your continuing efforts to improve the doc.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
[PATCH] fop's resource.xml
Posted by Clay Leeds <cl...@medata.com>.
Forgive my newbie-ness here, but I'm having problems figuring out how
to send this [patch] in. I'm sending it here... Please enlighten me
(gently ;-p) so that next time I'm doing it as efficiently as possible.
Thanks!
PATCH INFO:
The info for XPath is missing the fact that it's pretty much Windows IE
5+ only (requires MSXML 3.0). However, it's still a really useful tool!
It'd be nice if it could be re-engineered to be cross-platform!
Here's the good part:
RE: Alternative API proposal (was: startup refactoring)
Posted by Victor Mote <vi...@outfitr.com>.
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 FOProcessorAPI by setting a Java
> property,
> or some similar mechanism at run time instead of choosing it at compile
> time. Granted, this seems of not much use given that FOP will be the only
Hmmm. I missed that in the "goals" section.
> implementation at least for some time. There is another aspect: the
> FOProcessorFactory holds a default configuration and is a mechanism to
> quickly create preconfigured FOProcessor objects. You just can't use
> a single FOProcessor, because it holds a state while rendering and is
> therefore not MT safe in itself. Unless you can live with blocked threads
> this means you have to create a FOProcessor for every thread. Furthermore
This aspect of it could/should be entirely hidden from the user. IOW, I
wouldn't make the API more complex just to achieve this. Also, the
alternative to sharing shareable data and blocking thread access it to
duplicate the data and the processing of it. I'll certainly leave that issue
to you performance gurus.
> you might want to keep FOProcessor objects some time around after
> rendering
> has finished in order to inquire the number of rendered pages or whatever
> useful data the processor can supply then.
>
> > RenderContext is only useful if you are trying to reuse an AreaTree for
> > multiple output options. I am frankly confused right now about
> whether the
> > dev team even wants to try to do that.
>
> I think we have a few slightly more pressing problems:
> - getting layout up to conformance
> - make FOP MT safe
> - improving the API to ease embedding (including Java2D embedding)
> - improve performance and reduce memory consumption
I am not trying to implement multiple output options, but merely to make
sure we have the flexibility to do so. And frankly, I don't care if it ever
gets implemented. What *is* important, but on which I seem not to be making
any progress in explaining, is that each of the major processing tasks in
FOP should have a high-level controlling class that is responsible for it. I
see all four of the items you mention as being dependent on that.
> Adding multiple output streams is certainly fun but I suspect the
> bulk of the current users would be more interested in one of the
> points above. And somehow I have the feeling that your approach could
> easily get in the way, in particular I wouldn't like if it would
> *increase* memory usage in general.
I agree with your first statement. On the second, I wouldn't like Jeremias's
proposal either if it caused a nuclear holocaust :-). 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.
> > It looks like you are pushing the data that I envisioned in Document
> > and RenderContext down to RenderType/FOPResult. The net effect
> is that it
> > can't be reused.
> Why can't it be reused?
See answer in my response to Jeremias (which crossed your inquiry in the
mail).
> > 1. complexity. In addition to the Factory issue already
> mentioned, I think
> > there is some benefit to arranging the data more intuitively
> for the user.
> Users should be able to recognize certain patterns, like the ones
> used in JAXP.
Well, I don't think anyone is ever going to want to put a GUI on top of
Xalan, but I'll bet it will happen with FOP. The use case for FOP as it is
right now is fairly analagous to JAXP, i.e. a non-interactive process, but I
don't expect that to stay the same. Also, see my response to Jeremias about
the JAXP issue (also crossed in the mail). I'm not opposed to that pattern,
I'm just not sure it makes sense as our API.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Alternative API proposal (was: startup refactoring)
Posted by "J.Pietschmann" <j3...@yahoo.de>.
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 similar mechanism at run time instead of choosing it at compile
time. Granted, this seems of not much use given that FOP will be the only
implementation at least for some time. There is another aspect: the
FOProcessorFactory holds a default configuration and is a mechanism to
quickly create preconfigured FOProcessor objects. You just can't use
a single FOProcessor, because it holds a state while rendering and is
therefore not MT safe in itself. Unless you can live with blocked threads
this means you have to create a FOProcessor for every thread. Furthermore
you might want to keep FOProcessor objects some time around after rendering
has finished in order to inquire the number of rendered pages or whatever
useful data the processor can supply then.
> RenderContext is only useful if you are trying to reuse an AreaTree for
> multiple output options. I am frankly confused right now about whether the
> dev team even wants to try to do that.
I think we have a few slightly more pressing problems:
- getting layout up to conformance
- make FOP MT safe
- improving the API to ease embedding (including Java2D embedding)
- improve performance and reduce memory consumption
Adding multiple output streams is certainly fun but I suspect the
bulk of the current users would be more interested in one of the
points above. And somehow I have the feeling that your approach could
easily get in the way, in particular I wouldn't like if it would
*increase* memory usage in general.
> It looks like you are pushing the data that I envisioned in Document
> and RenderContext down to RenderType/FOPResult. The net effect is that it
> can't be reused.
Why can't it be reused?
> 1. complexity. In addition to the Factory issue already mentioned, I think
> there is some benefit to arranging the data more intuitively for the user.
Users should be able to recognize certain patterns, like the ones
used in JAXP.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Alternative API proposal (was: startup refactoring)
Posted by Victor Mote <vi...@outfitr.com>.
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
> realization that I cannot make up my mind about the inner context
> classes Victor has come up with. But I think he's quite close:
>
> - Session: Looks like my and Jörg's FOProcessor to me. The user
> interacts with this class to configure FOP and do processing runs.
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). I guess I don't
understand the need for FOProcessorFactory, which seems to be an unnecessary
complication for the user. Since I don't understand Avalon, I am not sure
how factoring it into/out of this affects the API, but if that is needed, it
seems like it should be done in an implementation of FOProcessor instead of
creating separate Factories.
> - Document and RenderContext: I'm not sure but I think these two should
> be merged. I've called it ProcessorContext in my proposal at first,
> but then chose not to include them in the proposal right now because
> I didn't quite know what to put in there. The thing I know is that we
> need a central data object that keeps references while the FOProcessor
> implementation coordinates the processing (data separated from logic).
RenderContext is only useful if you are trying to reuse an AreaTree for
multiple output options. I am frankly confused right now about whether the
dev team even wants to try to do that. I think it is a good idea, and
suspect that whatever difficulties have existed in implementing this in the
past are probably a result of our current tight coupling between FOTree,
layout, AreaTree, and Rendering, which is of course what I am trying to
unravel.
Your DocumentMetadata class holds information in it that would live in my
Document concept. That is information that is common to (but not necessarily
used by) by all output media, and does not need to be set for each output
media. It looks like you are pushing the data that I envisioned in Document
and RenderContext down to RenderType/FOPResult. The net effect is that it
can't be reused.
> - Renderer: You guys hate me for that, I know, but I still refuse to
> give it so much visibility in these discussions. In my proposal I've
> separated the logic from the data again (with JAXP as role-model) and
> made the Renderer a totally normal Avalon service that is being looked
> up by MIME type in the background. The FOPResult classes account for
> the differences of output types. The FOProcessor impl is responsible
> to establish the link between FOPResults and Renderer. For AWT (I'd
> like to call it Java2D from now on if you guys agree. That's the
> official name of the API after all.) I've tried to introduce an
> interface that clients can use to interact with the Java2D renderer.
Your FOPResult is I think roughly equivalent to what I am calling RenderType
or Renderer (somewhere along the way, I started calling mine RenderType to
make a more clear distinction between it and the workhorse Renderers), and
if I understand what you are doing, I think our goals are the same.
FOPResult is more of a control class, and the Renderer is a workhorse class.
> So, I don't have anything more concrete on the inner "glue" that keeps
> the whole process together but maybe my proposal brings some new ideas.
> I'd like to hear your thoughts about my proposal (flaws, nodding,
> missing things etc.).
>
> I hope that we can find a common path for the whole thing. Important to
> me is to have a good terminology and an API that conforms to the
> requirements I've written down on the FOPAvalonization page.
Here are the issues that I am still uncomfortable with:
1. complexity. In addition to the Factory issue already mentioned, I think
there is some benefit to arranging the data more intuitively for the user.
>From the user's standpoint, there is input and output (ie. 2 classes). It
makes sense to have a third (Session/FOProcessor) primarily to facilitate
reuse. IMO, if the user has to interact with more than 3 classes to get the
work done, we are unnecessarily complex. (My 4th class, RenderContext, is
not exposed to the user).
2. reuse. I see no downside to arranging our objects to allow reuse, even if
we decide we don't want to facilitate it. This doesn't directly affect the
API (we can have 15 or 50 classes supporting those exposed to the user).
Sorry to be so slow responding.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org