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 2002/09/04 23:02:08 UTC
[REDESIGN] API requirements
Hi Foppers
This mail is something I wanted to do for a long time now. I think it is
important to have around especially since Nicola has started working in
this domain.
I've tried to collect all API requirements and present them as a concise
document for future reference. I didn't include some of Jörg's (valid)
requirements because I thought they were already a bit too
implementation oriented for a requirements document. I can always add
them if you guys think I should.
I'm going to transform this document to XML once it is approved. I'll
post my own thoughts about possible solutions for the API shortly. I'm
sure this will also develop with Nicola's ideas.
General requirements
--------------------
- Easy to understand, learn and use
- Well documented behaviour
- Several example classes demonstrating the use of FOPs API
- Must cater to both novice users and expert developers
- Ready for multi-threaded server environment (Little overhead, fast)
- FOP is a service. It must be easy to integrate into a bigger system
(especially Cocoon)
- The service must be strongly configurable.
- Good defaults when not using configuration
- Logging to any logging mechanism
Additional wrappers
-------------------
- Command-line
- Ant task
- Sample Servlet
- Morphos morpher
Input
-----
DataType: application/xml (XSL:FO)
DataForm: Stream (File, URL, InputStream), SAX, DOM, JDOM etc.
Output
------
DataType: application/pdf
DataForm: Stream (File, URL, OutputStream)
DataType: application/postscript
DataForm: Stream (File, URL, OutputStream)
Repeat above for RTF, PCL, MIF, Text etc.
DataType: application/xml (SVG)
DataForm: Stream (File, URL, OutputStream), SAX, DOM, JDOM etc.
DataType: AWT Graphics2D
DataForm: GUI output, Java Printing, Stream (as Bitmap)
Additional output
-----------------
Some people want additional output from FOP such as:
- Number of pages generated overall
- Page-Sequences generated along with the number of pages for each
page-sequence
- Page-master used for each page
Notifications interface
-----------------------
- Layout warnings such as overflows
- Support for callbacks from FOP (ex. when a new page is rendered)
To be discussed
---------------
- We might want to generate multiple output formats in one run.
- AWT requirements should be more detailed. Any ideas?
Important References
--------------------
- Thread: Exploring the FOP API design space
http://marc.theaimsgroup.com/?t=102288093500008&r=1&w=2
- Thread: FOP Interfaces
http://marc.theaimsgroup.com/?t=101482634300004&r=1&w=2
Comments and additions welcome.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [REDESIGN] API requirements
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Mon, 2002-09-09 at 11:27, Jeremias Maerki wrote:
> > > To be discussed
> > > ---------------
> > >
> > > - We might want to generate multiple output formats in one run.
> >
> > Simple use a different area tree model (after checking font setup is
> > valid for both).
>
> Hmm, I was thinking of refactoring font setup one day. I'd like to
> provide a central font registry and the renderers could provide hints
> about which fonts they like best so multiple area tree models aren't
> necessary in most cases. Don't know if that would really work. But font
> setup as it is today doesn't feel right to me.
The layout managers only need to know the width of each caharacter and
the ascender/descender information. So if it is possible to get the
renderer to use this information or suuply common information it could
be possible.
I suppose that fonts are generally similar across different situations
but the size sometimes differs.
I don't know, have to see.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [REDESIGN] API requirements
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 09.09.2002 10:46:12 Keiron Liddle wrote:
> On Wed, 2002-09-04 at 23:02, Jeremias Maerki wrote:
> > General requirements
> > --------------------
> >
> > - Easy to understand, learn and use
> > - Well documented behaviour
> > - Several example classes demonstrating the use of FOPs API
> > - Must cater to both novice users and expert developers
> > - Ready for multi-threaded server environment (Little overhead, fast)
> > - FOP is a service. It must be easy to integrate into a bigger system
> > (especially Cocoon)
> > - The service must be strongly configurable.
> > - Good defaults when not using configuration
> > - Logging to any logging mechanism
>
> Sounds good to me.
>
> >
> > Additional wrappers
> > -------------------
> >
> > - Command-line
> > - Ant task
> > - Sample Servlet
> > - Morphos morpher
> >
> >
> > Input
> > -----
> >
> > DataType: application/xml (XSL:FO)
> > DataForm: Stream (File, URL, InputStream), SAX, DOM, JDOM etc.
> >
> >
> > Output
> > ------
> >
> > DataType: application/pdf
> > DataForm: Stream (File, URL, OutputStream)
> >
> > DataType: application/postscript
> > DataForm: Stream (File, URL, OutputStream)
> >
> > Repeat above for RTF, PCL, MIF, Text etc.
> >
> > DataType: application/xml (SVG)
> > DataForm: Stream (File, URL, OutputStream), SAX, DOM, JDOM etc.
>
> Will this be able to output multiple files? For example for one svg file
> per page.
I haven't really thought about that, yet. I'll add a comment and we'll
see how to do this. Probably by passing in a factory.
> > DataType: AWT Graphics2D
> > DataForm: GUI output, Java Printing, Stream (as Bitmap)
>
> I know it's not the api but handling things ike this will mean some sort
> of selector for the area tree model. Printing can use a render pages
> model, whereas the awt viewer will need a cached store pages model.
Ok.
> > Additional output
> > -----------------
> >
> > Some people want additional output from FOP such as:
> > - Number of pages generated overall
> > - Page-Sequences generated along with the number of pages for each
> > page-sequence
> > - Page-master used for each page
>
> Looks like the area tree will need to handle a number of callback
> things.
I can't tell ATM.
> Also what to do for errors such as IOException etc.
Well, IOExceptions are typically fatal errors which results in aborting
processing. There might be IOExceptions while loading resources (images)
that could be declared as non-fatal, but I think not. I think that's
something for the notifications interface.
>
> >
> > Notifications interface
> > -----------------------
> >
> > - Layout warnings such as overflows
>
> Do we need callbacks for this.
I think so. Something like javax.xml.transform.ErrorListener.
> > - Support for callbacks from FOP (ex. when a new page is rendered)
> >
> >
> > To be discussed
> > ---------------
> >
> > - We might want to generate multiple output formats in one run.
>
> Simple use a different area tree model (after checking font setup is
> valid for both).
Hmm, I was thinking of refactoring font setup one day. I'd like to
provide a central font registry and the renderers could provide hints
about which fonts they like best so multiple area tree models aren't
necessary in most cases. Don't know if that would really work. But font
setup as it is today doesn't feel right to me.
> > - AWT requirements should be more detailed. Any ideas?
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [REDESIGN] API requirements
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Wed, 2002-09-04 at 23:02, Jeremias Maerki wrote:
> General requirements
> --------------------
>
> - Easy to understand, learn and use
> - Well documented behaviour
> - Several example classes demonstrating the use of FOPs API
> - Must cater to both novice users and expert developers
> - Ready for multi-threaded server environment (Little overhead, fast)
> - FOP is a service. It must be easy to integrate into a bigger system
> (especially Cocoon)
> - The service must be strongly configurable.
> - Good defaults when not using configuration
> - Logging to any logging mechanism
Sounds good to me.
>
> Additional wrappers
> -------------------
>
> - Command-line
> - Ant task
> - Sample Servlet
> - Morphos morpher
>
>
> Input
> -----
>
> DataType: application/xml (XSL:FO)
> DataForm: Stream (File, URL, InputStream), SAX, DOM, JDOM etc.
>
>
> Output
> ------
>
> DataType: application/pdf
> DataForm: Stream (File, URL, OutputStream)
>
> DataType: application/postscript
> DataForm: Stream (File, URL, OutputStream)
>
> Repeat above for RTF, PCL, MIF, Text etc.
>
> DataType: application/xml (SVG)
> DataForm: Stream (File, URL, OutputStream), SAX, DOM, JDOM etc.
Will this be able to output multiple files? For example for one svg file
per page.
> DataType: AWT Graphics2D
> DataForm: GUI output, Java Printing, Stream (as Bitmap)
I know it's not the api but handling things ike this will mean some sort
of selector for the area tree model. Printing can use a render pages
model, whereas the awt viewer will need a cached store pages model.
> Additional output
> -----------------
>
> Some people want additional output from FOP such as:
> - Number of pages generated overall
> - Page-Sequences generated along with the number of pages for each
> page-sequence
> - Page-master used for each page
Looks like the area tree will need to handle a number of callback
things.
Also what to do for errors such as IOException etc.
>
> Notifications interface
> -----------------------
>
> - Layout warnings such as overflows
Do we need callbacks for this.
> - Support for callbacks from FOP (ex. when a new page is rendered)
>
>
> To be discussed
> ---------------
>
> - We might want to generate multiple output formats in one run.
Simple use a different area tree model (after checking font setup is
valid for both).
> - AWT requirements should be more detailed. Any ideas?
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: [REDESIGN] API requirements
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> I've tried to collect all API requirements and present them as a concise
> document for future reference.
Well, I just posted a few to the avalonization thread.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org