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 PN...@directsourcing.com on 2000/03/20 20:12:36 UTC
Configuration System
Regarding developing the Configuration system for the Images in fop so that
any library(Jimi,JAI,xxxx) could be plugged in. I have following thoughts
It seems to me that the switchable components(libraries) Cocoon uses is
parsers. All these parsers are based on well defined interfaces defined by
neutral bodies. SO these parsers have a well defined api to access, thus
being a good candidate for being switchable. While in case of image handling
libraries we intend to use are totally disparate. Now I don't know if we
should go ahead and define few interfaces for image handling. Then design
wrappers based on these interfaces for the respective libraries or stick to
one library. Although config system would be great choice for specifying
parser and xsl formatter used by fop.
Tell me what you guys think?
Pankaj Narula
502-326-4426 (Office)
Re: Configuration System
Posted by Jon Smirl <jo...@mediaone.net>.
Why does the FOP layout code need to load the images from the URL, shouldn't
this be deferred until the rendering code? It looks like the current code
makes all of the images for the document simultaneously resident in memory.
I looked at the XSL spec for external-graphic. Does it require that the
layout engine be able to open external graphic files and extract a default
length? I know this is convenient but it has the side effect of requiring
XSL formatters to be able to decode all image types.
Jon Smirl
jonsmirl@mediaone.net
Re: Configuration System
Posted by Stefano Mazzocchi <st...@apache.org>.
PNarula@directsourcing.com wrote:
>
> Regarding developing the Configuration system for the Images in fop so that
> any library(Jimi,JAI,xxxx) could be plugged in. I have following thoughts
>
> It seems to me that the switchable components(libraries) Cocoon uses is
> parsers. All these parsers are based on well defined interfaces defined by
> neutral bodies. SO these parsers have a well defined api to access, thus
> being a good candidate for being switchable. While in case of image handling
> libraries we intend to use are totally disparate. Now I don't know if we
> should go ahead and define few interfaces for image handling. Then design
> wrappers based on these interfaces for the respective libraries or stick to
> one library. Although config system would be great choice for specifying
> parser and xsl formatter used by fop.
>
> Tell me what you guys think?
The Cocoon2 component system (modeled after Avalon) is based on the
assumption that all components implement the same interface and, for
this reason, can be polymorphically see as the exaxt same component
without requiring any other change in the tool that uses the component.
This is true with any plugin system, but java is simply great at doing
all this for you (while you can easily see how painful this is on other
native systems, for example apache or XFree 4.0)
Anyway, you are right: if you don't have the same interface the system
doesn't work so either
- find a common API set that it's implemented by all of the components
- write your own interface and write "adapter/decorator" classes that
wrap around the libraries you want to use and make them look all the
same to the component user.
Cocoon1 did that for all XML parser, XSLT processor and XML formatter.
Cocoon2 will try to use JAXP-next (so SAX2 + DOM2 + TRaX) to avoid the
use to define our own decorating interfaces... but we still have a way
to go to see those API collections stabilize.
So, at the end, yes without a common API set, you can't use polymorphism
and you can't do what cocoon does. Period.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Configuration System
Posted by Eric SCHAEFFER <es...@posterconseil.com>.
But we already have the interface : "FopImage", no ? (It maybe needs to be a
bit changed, but that's the interface we need).
We just need to write a class implementing this interface for each type of
"reader" we want to use (JAI, Jimi, etc...), and a configurable factory.
Eric.
(I was in holidays for one week).
_______________________________________
Eric SCHAEFFER
eschaeffer@posterconseil.com
POSTER CONSEIL
118 rue de Tocqueville
75017 PARIS
FRANCE
Tel. : 33-140541058
Fax : 33-140541059
_______________________________________
----------------------------------------------------------------------------
-----------------------------
Come to the first official Apache Software Foundation Conference!
-----------------------------------
http://ApacheCon.Com ------------------------------------
----- Original Message -----
From: <PN...@directsourcing.com>
To: <fo...@xml.apache.org>; <co...@xml.apache.org>
Sent: Monday, March 20, 2000 9:12 PM
Subject: Configuration System
> Regarding developing the Configuration system for the Images in fop so
that
> any library(Jimi,JAI,xxxx) could be plugged in. I have following thoughts
>
> It seems to me that the switchable components(libraries) Cocoon uses is
> parsers. All these parsers are based on well defined interfaces defined by
> neutral bodies. SO these parsers have a well defined api to access, thus
> being a good candidate for being switchable. While in case of image
handling
> libraries we intend to use are totally disparate. Now I don't know if we
> should go ahead and define few interfaces for image handling. Then design
> wrappers based on these interfaces for the respective libraries or stick
to
> one library. Although config system would be great choice for specifying
> parser and xsl formatter used by fop.
>
> Tell me what you guys think?
>
> Pankaj Narula
> 502-326-4426 (Office)
>
Re: Configuration System
Posted by Jon Smirl <jo...@mediaone.net>.
Why does the FOP layout code need to load the images from the URL, shouldn't
this be deferred until the rendering code? It looks like the current code
makes all of the images for the document simultaneously resident in memory.
I looked at the XSL spec for external-graphic. Does it require that the
layout engine be able to open external graphic files and extract a default
length? I know this is convenient but it has the side effect of requiring
XSL formatters to be able to decode all image types.
Jon Smirl
jonsmirl@mediaone.net
Re: Configuration System
Posted by Stefano Mazzocchi <st...@apache.org>.
PNarula@directsourcing.com wrote:
>
> Regarding developing the Configuration system for the Images in fop so that
> any library(Jimi,JAI,xxxx) could be plugged in. I have following thoughts
>
> It seems to me that the switchable components(libraries) Cocoon uses is
> parsers. All these parsers are based on well defined interfaces defined by
> neutral bodies. SO these parsers have a well defined api to access, thus
> being a good candidate for being switchable. While in case of image handling
> libraries we intend to use are totally disparate. Now I don't know if we
> should go ahead and define few interfaces for image handling. Then design
> wrappers based on these interfaces for the respective libraries or stick to
> one library. Although config system would be great choice for specifying
> parser and xsl formatter used by fop.
>
> Tell me what you guys think?
The Cocoon2 component system (modeled after Avalon) is based on the
assumption that all components implement the same interface and, for
this reason, can be polymorphically see as the exaxt same component
without requiring any other change in the tool that uses the component.
This is true with any plugin system, but java is simply great at doing
all this for you (while you can easily see how painful this is on other
native systems, for example apache or XFree 4.0)
Anyway, you are right: if you don't have the same interface the system
doesn't work so either
- find a common API set that it's implemented by all of the components
- write your own interface and write "adapter/decorator" classes that
wrap around the libraries you want to use and make them look all the
same to the component user.
Cocoon1 did that for all XML parser, XSLT processor and XML formatter.
Cocoon2 will try to use JAXP-next (so SAX2 + DOM2 + TRaX) to avoid the
use to define our own decorating interfaces... but we still have a way
to go to see those API collections stabilize.
So, at the end, yes without a common API set, you can't use polymorphism
and you can't do what cocoon does. Period.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------