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 "J.Pietschmann" <j3...@yahoo.de> on 2003/06/23 21:28:56 UTC
Re: Alternative API proposal
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
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