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 Keiron Liddle <ke...@aftexsw.com> on 2002/02/27 17:11:10 UTC
FOP Interfaces
Since this seems to be a hot topic at the moment I thought I might jump
in. To use FOP in the various contexts we need to properly setup the right
interfaces. First we need to determine why and what those interfaces are.
All of the interfaces are set through the Driver. The Driver is the
central control point for all fo -> pdf etc. transformations.
Below is a sample of the type of areas and information that needst o pass
to and from FOP:
User agent
The list of things this needs to supply is on this page, rather badly
formatted:
http://xml.apache.org/fop/design/useragent.html
Logging
- logging level
- logging messages of various levels
- error handling
XML input
- various ways to supply FOP with the xsl:fo file
- sax handler
general options
- base directory
- uri resolvers
renderer options
- embedding fonts
- compression in pdf
- image embedding
The Driver handles the XML input.
The user agent information is through the FOUserAgent.
We could handle logging through the user agent.
Options could also be handled through the user agent, using mime type
selection for renderer options.
So, what do people think. What other information will be needed.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: FOP Interfaces
Posted by Jeremias Maerki <je...@outline.ch>.
> Since this seems to be a hot topic at the moment I thought I might jump
> in. To use FOP in the various contexts we need to properly setup the right
> interfaces. First we need to determine why and what those interfaces are.
>
> All of the interfaces are set through the Driver. The Driver is the
> central control point for all fo -> pdf etc. transformations.
I'm not so sure right now, if a monolithic Driver class is so good.
Maybe we really have a little number of specialized classes for FOP
processing that are particularly easy to use. For example an easy one
that integrates nicely with JAXP. That could help reducing the support
questions on how to embed FOP. Maybe we can have a FOPResult (similar to
SAXResult) that people can use. I don't know yet, I'm just trying to
gather some thoughts. :-)
> Below is a sample of the type of areas and information that needst o pass
> to and from FOP:
>
> User agent
> The list of things this needs to supply is on this page, rather badly
> formatted:
> http://xml.apache.org/fop/design/useragent.html
>
>
> Logging
> - logging level
> - logging messages of various levels
> - error handling
>
> XML input
> - various ways to supply FOP with the xsl:fo file
> - sax handler
>
> general options
> - base directory
> - uri resolvers
>
> renderer options
> - embedding fonts
> - compression in pdf
> - image embedding
for the PS renderer (eventually):
- PostScript Level
- PPD to use
- binary/ascii switch
FOP's component setup: which implementation of a particular
LayoutManager to use, Logging setup (LogKit, Log4J, JDK14Logging), etc.
Output from FOP:
- Generation statistics: Number of pages total, Number of pages of each
page-sequence, page-master used for each page (could be used to
control the paper bin to get paper from, important for me in
conjunction with PS Renderer).
> The Driver handles the XML input.
> The user agent information is through the FOUserAgent.
> We could handle logging through the user agent.
> Options could also be handled through the user agent, using mime type
> selection for renderer options.
May I add that it might be nice if we could render to more than one
renderer at once (maybe not from the command line). Two independent
sources have asked me in the last few weeks if this works. I must say
that this would be nice, since I could generate a PDF for the archive
and the PS for the printer in one run. It would probably be faster than
converting the PDF to PostScript afterwards.
> So, what do people think. What other information will be needed.
Maybe there's more...
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 41 317 20 20 - Fax +41 41 317 20 29
Internet http://www.outline.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: FOP Interfaces
Posted by Ralph LaChance <Ra...@compuserve.com>.
At 05:11 PM 2/27/02 +0100, you wrote:
>renderer options
>- embedding fonts
>- compression in pdf
>- image embedding
>
>
>The Driver handles the XML input.
>The user agent information is through the FOUserAgent.
>We could handle logging through the user agent.
>Options could also be handled through the user agent, using mime type
>selection for renderer options.
>
>So, what do people think. What other information will be needed.
Keiron,
my 2 cents, shot from the hip ;-)
Based on both our fop usage here and on dozens of questions I've seen go by
on this list, perhaps it makes sense to consider some support for driving
various printing options. i.e., put up the dialog, default to std printer,
etc. Clearly the
options are very different for a servlet vs an application.
Also, in view, of the new PrinterServices facility in 1.4, perhaps some
thought
to allowing the calling framework (servlet or app) to specifying the printer.
And then there is the recurring question of whether -awt generates a panel or
a frame and whether it returns a swing object or not.
' Best,
-Ralph LaChance
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org