Re: FOP components

[Glen Mazza]

+1

--- Chris Bowditch <[EMAIL PROTECTED]> wrote:
> You would make FOP unavailable to 70% of the user
> base. Take a look at 
> Sun's Xmlroff, it has a feature set comparable to
> the maintainance 
> branch, its free, but FOP has a much bigger user
> base. Why? because 
> xmlroff doesnt run on windows, i.e. its unavailable
> to a large 
> percentage of its user base. So in summary, if we
> developed FOP for JDK 
> 1.5, it would be a failure because few people would
> use it.
> 
> Chris
> 
> 

Re: FOP components

[Jeremias Maerki]

No, the question is: How long will it take for the 1.5 platform to
establish itself? 1.4 took quite a long time, less than 1.3 but still...
You will have 1.5 on Windows, Solaris and Linux immediately but all the
other platforms are not so quick, even MacOSX which was promoted as the
"best Java platform". :-)

On 09.02.2004 16:11:05 Andreas L. Delmelle wrote:
> Besides that, question remains: how many users currently using 1.4 expect to
> upgrade to 1.5 as soon as it arrives?


Jeremias Maerki

Re: FOP components

[Jeremias Maerki]

It has multiple pluggable datasources (Property files, XML, JNDI)

See http://jakarta.apache.org/commons/configuration/

On 09.02.2004 01:06:08 J.Pietschmann wrote:
> There's also jakarta commons configuration, which uses property
> files (IIRC, may well be wrong).



Jeremias Maerki

Re: FOP components

[Jeremias Maerki]

...and I should probably help since I was the main pusher here.

BTW, I've started a little something for testing the SVG transcoder
using GhostScript as converter to bitmaps. I've created little Avalon
components that can nicely be configured by XML. I hope I can soon
upload that for you to see.

Another cool place to see Avalon power at work is the Cocoon codebase.

On 08.02.2004 12:37:53 J.Pietschmann wrote:
> I should probably move a bit faster in order to provide some
> working sample code so everybody can see how this could look
> like for FOP.


Jeremias Maerki

Re: FOP components

[Jeremias Maerki]

The Preferences API is exactly that: for preferences. IMO this is best
for client application (GUIs) that need to save and reload preferences
for the application. That's the reason for the distinction between
system root and user root [1]. This is cool for our preview application
and the "FOP utility" that I promised long ago and never delivered. But
for configuring FOP (the engine) I consider the preferences API
rather unsuitable.

We also need to make sure that FOP can easily be configured from within
Cocoon which could be difficult with the Preferences API.

[1] http://java.sun.com/j2se/1.4.2/docs/api/java/util/prefs/PreferencesFactory.html

On 08.02.2004 04:57:35 Peter B. West wrote:
> possibly also the preferences API (java.util.prefs) for 
> configuration/user agent/user prefs?


Jeremias Maerki

Re: FOP components

[J.Pietschmann]

Clay Leeds wrote:
As for 1.0 (forgive my playing the devil's 
advocate here), why stop at 1.4? Assuming Java 1.5 will be released by 
the time FOP 1.0 will be released, why not base it on the latest and 
greatest? Would that offer any benefits? What problems might that lead to?
Well, 1.4 is out since nearly two years now (counting the usable
betas), and will be stable for nearly two years or more when
1.0 is released. This means it will be available for even pretty
obscure environments. The only users stuck with 1.3 and earlier
will the ones where upgrading to 1.4 implies severe side effects,
mainly upgrading essential software services, the whole OS, or
even hardware upgrades.
From what I heard, development efforts are meanwhile firmly based
on 1.4, everything based on 1.3 is strictly maintenance, with
a gradual migration to 1.4.
J.Pietschmann

Re: FOP components

[Jeremias Maerki]

On 08.02.2004 01:34:16 Glen Mazza wrote:
> --- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> > - avalon and logging for the base library.
> > 
> 
> The avalon jar is indeed quite small (only 25K or so),
> but this dependency I'd like us to eventually get rid
> of in favor of what Xalan does with its messaging and
> i18n instead.  (I suspect AH or RX don't bother with
> loggers, they're probably more like Xalan as well.)

I don't think logging is the same as providing user-friendly and
localized error messages. I'd agree that Xalan's approach is good and we
could or even should adopt it but IMO it doesn't replace logging which
is primarily for debugging purposes (be it for Java developers or
stylesheet producers). It is debatable whether the Avalon Framework's
logging approach is the best. I don't think so. There are situations
where I should have use Commons Logging instead of Avalon Logging (PDF
library for example). Both have their uses. I'll gladly outline if
desired.

> Xalan appears to route all messages through an
> XMLMessages.java [1] (with a couple of subclasses for
> XPath and XSLT-specific messages) with the result
> going to stdout by default.  (I don't know what
> happens in embedded usage, whether those messages can
> be re-routed to a logger of the user's choosing.) 
> Also, they use message constant enums so they can get
> the messages to appear in multiple languages. [2]  

The problem I have with Xalan is that they do no logging. Sometimes it
would be good to get some feedback on what is going on inside. At the
time where I had to do some intensive error searches inside Xalan I
encountered a lot of System.outs that where commented out (I don't know
if this has changed in the meantime, though). Indicates that they should
have used a logging package. And when you have a software live at a
customer site you will love the chance to change the debug level to see
what's going on inside when you're in trouble.



Jeremias Maerki

Re: FOP components (and JDK 1.4 requirement)

[Jeremias Maerki]

I'm pleasantly surprised by your proposal. Wasn't it you who wanted the
servlet in the main source tree a year ago?

On 08.02.2004 00:38:35 J.Pietschmann wrote:

> There ought to be a less messy approach. It could be an idea
> to move the various packages to different base directories,
> making FOP essentially a multi-subproject project similar
> to jakarta commons. This way each subpackage has its own
> buildfile and lib directory, and dependencies become more
> clear. In order to manage the cross package dependencies and
> dependencies outside of FOP, Maven seems to be the tool of
> choice. Unfortunately, I'm not enough of a Maven wizard to
> asses this completely. Is there somebody out there with more
> time at hand to look at these issues?
> 
> BTW
> 1. I'd like to get rid of the servlet.jar in our CVS.
> 2. If we standardize on JDK 1.4 as base (as it currently
>   is), we could drop the Xerces, Xalan and xml-api jars as
>   well. Our Jars seem to be somewhat outdated anyway.

"If we standardize..." triggers something inside me: I'd like to put on
record that I request a vote (by someone who really cares) on the issue
of making JDK 1.4 a minimal requirement for FOP. I still don't buy it.
For the AWT renderer, any time, but not for the rest. I won't block
either, but I want this done properly. I may request that certain parts
of FOP (base libraries like PDF and fonts for example) remain compatible
with JDK 1.3. Especially the Batik transcoders for PDF and PostScript
should remain JDK 1.3 compatible as Batik still has JDK 1.3 (AFAIK) and
the transcoders and supporting code should move to a common subproject
in the future "XML Graphics" (or whatever) PMC. If the Batik team
changes the minimum requirements this could, of course, look different,
but that's how it looks today. BTW, Cocoon, an important FOP customer,
is also still on JDK 1.3. It me be good prior to taking a decision to
ask these two projects about their plans in the regard.

Sorry to be a pain. :-)

http://xml.apache.org/batik/install.html
http://cocoon.apache.org/2.1/installing/requirements.html


Jeremias Maerki

RE: FOP components

[Andreas L. Delmelle]

> -Original Message-
> From: Clay Leeds [mailto:[EMAIL PROTECTED]
>

> I had a similar thought process (0_20_2-maintain for pre-1.4 users--if
> it works, don't fix it?). As for 1.0 (forgive my playing the devil's
> advocate here), why stop at 1.4? Assuming Java 1.5 will be released by
> the time FOP 1.0 will be released, why not base it on the latest and
> greatest? Would that offer any benefits? What problems might that lead
> to?
>

As much as I like the idea, that's going to be two X.0 releases... I suspect
we'd better keep the '1.4.X Recommended' foot behind the door (--but we
should definitely be looking at gradually providing 1.5 specific stuff
wherever it's advantageous to do so)

Besides that, question remains: how many users currently using 1.4 expect to
upgrade to 1.5 as soon as it arrives?


Cheers,

Andreas

Re: FOP components

[Chris Bowditch]

Clay Leeds wrote:

On Feb 8, 2004, at 3:37 AM, J.Pietschmann wrote:


I had a similar thought process (0_20_2-maintain for pre-1.4 users--if 
it works, don't fix it?). As for 1.0 (forgive my playing the devil's 
advocate here), why stop at 1.4? Assuming Java 1.5 will be released by 
the time FOP 1.0 will be released, why not base it on the latest and 
greatest? Would that offer any benefits? What problems might that lead to?
You would make FOP unavailable to 70% of the user base. Take a look at 
Sun's Xmlroff, it has a feature set comparable to the maintainance 
branch, its free, but FOP has a much bigger user base. Why? because 
xmlroff doesnt run on windows, i.e. its unavailable to a large 
percentage of its user base. So in summary, if we developed FOP for JDK 
1.5, it would be a failure because few people would use it.

Chris

Re: FOP components

[Clay Leeds]

On Feb 8, 2004, at 3:37 AM, J.Pietschmann wrote:
If we are involved in such considerations, we need to decide how we 
propose to support our 1.3 user base.  The most recent discussions 
showed that a number of users face steep costs to upgrade to 1.4.
As for the 1.4 discussion: The jakarta commons list held it at
some length a few weeks ago. It's choosing between Scylla and
Charybdis: Using 1.4 gives a lot of functionality, thereby giving
the project leverage to move faster rather than worrying about
reimplementation of such functions. OTOH, it may lock out users
on platforms which lag behind. There was also the consideration
that many enterprises have servers based on 1.3 deployed, and
upgrading a working service is usually frowned upon, even if a
convenient path is available.
Given that FOP 1.0 wont be released until at least late this year,
if not later, we could tell our 1.3 users to use 0.20.5 and
declare 1.4 the minimum for 1.0.
I had a similar thought process (0_20_2-maintain for pre-1.4 users--if 
it works, don't fix it?). As for 1.0 (forgive my playing the devil's 
advocate here), why stop at 1.4? Assuming Java 1.5 will be released by 
the time FOP 1.0 will be released, why not base it on the latest and 
greatest? Would that offer any benefits? What problems might that lead 
to?

Web Maestro Clay

RE: FOP components

[Andreas L. Delmelle]

> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]

> There's also jakarta commons configuration, which uses property
> files (IIRC, may well be wrong).

Not wrong necessarily, I think. Just maybe a bit outdated to some. The
Properties API is treated in many docs as a sort of predecessor to the
Preferences API.

> Other approaches include using commons digester or betwixt for
> reading XML, using a handcrafted XML reader as 0.20.5 does, or
> using JNDI like J2EE.
>
> No shortage of ideas at all :-)
>

Indeed no reason to go re-inventing the wheel.
But then again, I haven't yet found any specific approaches making use of
1.4's Preferences API. The particular thing I'm referring to is Sun's or
Apple's choice on the storage location of the settings file. No objection at
all on this being a system-specific location, but it might as well be
HKEY_CURRENT_USER\Software\Apache\{project-name} (Win)
or one separate file named apache.{project-name}.plist, instead of one file
for each subtree and corresponding entries for these in the
'com.apple.java.util.prefs.plist' (Mac OSX)

What I certainly didn't mean was that we couldn't be doing some pioneering
work ourselves :)


Cheers,

Andreas

Re: FOP components

[J.Pietschmann]

Andreas L. Delmelle wrote:
Apache projects... Perhaps someone at Jakarta already has an idea for a
common Preferences library? (AFAICT not)
It's common enough that everybody invents its own solution, as
expected.
Avalon provides for XML configuration files, there are classes
mapping XML structures conveniently to objects, which can be
passed to Avalon components. That's one of the more amenable
features of Avalon.
There's also jakarta commons configuration, which uses property
files (IIRC, may well be wrong).
Other approaches include using commons digester or betwixt for
reading XML, using a handcrafted XML reader as 0.20.5 does, or
using JNDI like J2EE.
No shortage of ideas at all :-)

J.Pietschmann

RE: FOP components

[Andreas L. Delmelle]

> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]

> ... The settings themselves are stored in a
> system location where they are not meant to be found and edited by hand...
> (On Windows the more straightforward way to modify the prefs
> outside of the application is some regedit'ing).

BTW:
And then there is still the question of whether to blindly use the
implementation provided by Sun --in which case 'our' FOP configuration
settings will end up in places like, on Windows, a common Java Apps key-hive
in the registry(*) - or whether we're going to provide our own
implementation --maybe this could/should best be done in co-op with other
Apache projects... Perhaps someone at Jakarta already has an idea for a
common Preferences library? (AFAICT not)
Settling on a common location for the Preferences' BackingStore seems like a
decision meant to be taken on a larger scale.


Cheers,

Andreas

(*) HKEY_CURRENT_USER\Software\JavaSoft\Prefs\{package-ref} for the
user-level preferences.
on Mac OS X these are stored as .plist XML files in the user's
~/Library/Preferences folder

Re: FOP components

[J.Pietschmann]

Peter B. West wrote:
I don't know Avalon, so I don't know what other facilities from there we 
are using or considering using.
Avalon is a great way to decompose a large system into components.
The real advantage is that there can be different implementations
managing the components.
For example, we could build our own simple managers, more or less
hardwiring what FOP components are instantiated and how they are
composed into a working FO processor. That's good enough for
testing and a simple CLI. Others could use ECM or Phoenix or
whatever the Avalon guys throw out for efficient configuration
and lifecycle management of the whole stuff in a server environment,
with object pooling and caching (images and fonts) and so on.
I should probably move a bit faster in order to provide some
working sample code so everybody can see how this could look
like for FOP.
If we are involved in such considerations, we need to decide how we 
propose to support our 1.3 user base.  The most recent discussions 
showed that a number of users face steep costs to upgrade to 1.4.
As for the 1.4 discussion: The jakarta commons list held it at
some length a few weeks ago. It's choosing between Scylla and
Charybdis: Using 1.4 gives a lot of functionality, thereby giving
the project leverage to move faster rather than worrying about
reimplementation of such functions. OTOH, it may lock out users
on platforms which lag behind. There was also the consideration
that many enterprises have servers based on 1.3 deployed, and
upgrading a working service is usually frowned upon, even if a
convenient path is available.
Given that FOP 1.0 wont be released until at least late this year,
if not later, we could tell our 1.3 users to use 0.20.5 and
declare 1.4 the minimum for 1.0.
J.Pietschmann

RE: FOP components

[Andreas L. Delmelle]

> -Original Message-
> From: Peter B. West [mailto:[EMAIL PROTECTED]
>

> If we go to 1.4, should we also use 1.4 logging (java.util.logging) and
> possibly also the preferences API (java.util.prefs) for
> configuration/user agent/user prefs?
>

I like this latter proposal (using preferences). The more because about 6
months ago I played with the idea of extending FOP to use prefs --my main
idea back then was to allow for simplifying command-line use when performing
the rendering of many similar documents (CL doesn't support using wildcards
AFAIK --I remember at that time it didn't seem too difficult to hack this
in, just didn't get around to doing it; then started to focus on HEAD).

The reason I decided to freeze these ideas was the support still being
offered for 1.3 on one hand, and the fact that, where our current
configuration file can be easily hand-edited, this is a bit more difficult
when using the Preferences API. The settings themselves are stored in a
system location where they are not meant to be found and edited by hand...
(On Windows the more straightforward way to modify the prefs outside of the
application is some regedit'ing).
So, on top of the facility of reading the configuration settings, we would
also have to provide for a way to enter/alter them. (more command-line
switches...)

Basically this would thus also require a thorough revision of all documents
concerning configuration.

Once support of this sort is operational, however, you could easily export
the config settings from one system (be it Win / Linux / MacOS) and transfer
this to another platform without too much further ado. The Prefs API is
quite straightforward to use programmatically, so IMHO our embedded users
would certainly benefit from this approach. (Thinking of the intuitive
distinction between user- and system-level preferences)

If we're maintaining support for 1.3, the absence of java.util.prefs would
have to be tackled in a way similar to JCE support, I think (--might be
overly complicating in itself) and on top of that, some sort of transition
should be made, leaving the option of reading an 'old' config file into the
brand new FOPPreferences (--this in itself shouldn't be too difficult, just
a matter of transforming the config XML file into an XML ready for import by
the Prefs ).


Cheers,

Andreas

Re: FOP components

[Glen Mazza]

> Peter B. West wrote:
> > If we go to 1.4, should we also use 1.4 logging (java.util.logging) and
> > possibly also the preferences API (java.util.prefs) for
> > configuration/user agent/user prefs?
> >
> > I don't know Avalon, so I don't know what other facilities from there we
> > are using or considering using.
> >

If we need a logger internally--or find it beneficial to continue with
one--our two options are probably just Avalon and commons-logging, as those
are the two that provide the user logging options:  either Log4J, Java 1.4
Logging, Avalon, stdout, or Null logger.  I believe Log4J and 1.4 logging
tie the user to only one logging implementation, namely, themselves.

Avalon has a benefit that we know it already and it apparently offers other
features besides logging (but I also haven't researched what those other
features are).  Commons-logging, OTOH, may allow for somewhat closer
integration of FOP with Struts (which uses that logger).[1]

[1] http://marc.theaimsgroup.com/?l=struts-user&m=102090805604782&w=2

Re: FOP components

[Peter B. West]

Peter B. West wrote:
J.Pietschmann wrote:
...
- avalon and logging for the base library.

...

BTW
1. I'd like to get rid of the servlet.jar in our CVS.
2. If we standardize on JDK 1.4 as base (as it currently
 is), we could drop the Xerces, Xalan and xml-api jars as
 well. Our Jars seem to be somewhat outdated anyway.


If we go to 1.4, should we also use 1.4 logging (java.util.logging) and 
possibly also the preferences API (java.util.prefs) for 
configuration/user agent/user prefs?

I don't know Avalon, so I don't know what other facilities from there we 
are using or considering using.

framework.ValuedEnum for one.  That will have to wait until Java 1.5.

Peter
--
Peter B. West 

Re: FOP components

[Peter B. West]

J.Pietschmann wrote:
...
- avalon and logging for the base library.

...
BTW
1. I'd like to get rid of the servlet.jar in our CVS.
2. If we standardize on JDK 1.4 as base (as it currently
 is), we could drop the Xerces, Xalan and xml-api jars as
 well. Our Jars seem to be somewhat outdated anyway.
If we go to 1.4, should we also use 1.4 logging (java.util.logging) and 
possibly also the preferences API (java.util.prefs) for 
configuration/user agent/user prefs?

I don't know Avalon, so I don't know what other facilities from there we 
are using or considering using.

If we are involved in such considerations, we need to decide how we 
propose to support our 1.3 user base.  The most recent discussions 
showed that a number of users face steep costs to upgrade to 1.4.

Peter
--
Peter B. West 

Re: FOP components

[Glen Mazza]

--- "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> - avalon and logging for the base library.
> 

The avalon jar is indeed quite small (only 25K or so),
but this dependency I'd like us to eventually get rid
of in favor of what Xalan does with its messaging and
i18n instead.  (I suspect AH or RX don't bother with
loggers, they're probably more like Xalan as well.)

Xalan appears to route all messages through an
XMLMessages.java [1] (with a couple of subclasses for
XPath and XSLT-specific messages) with the result
going to stdout by default.  (I don't know what
happens in embedded usage, whether those messages can
be re-routed to a logger of the user's choosing.) 
Also, they use message constant enums so they can get
the messages to appear in multiple languages. [2]  

Glen

[1]
http://cvs.apache.org/viewcvs.cgi/xml-xalan/java/src/org/apache/xml/res/XMLMessages.java?rev=1.4&view=auto

[2]
http://cvs.apache.org/viewcvs.cgi/xml-xalan/java/src/org/apache/xml/res/


__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

FOP components

[J.Pietschmann]

Hi,
while fiddling with the New API it dawned me there are actually
several packages in FOP:
- the basic engine, embeddable
- a CLI wrapper
- a servlet wrapper
- an Ant task
- the font utilities
- the hyphenation data utilities (basically the Ant task)
- a variety of extenstions.
Perhaps the AWT viewer or even all of the renderers can be
added here too.
The problem is managing the dependencies:
- commons-cli for the CLI wrapper (new API), also probably
 nice for the font utilities
- Ant for the FOP Ant task and the hyphenation data task
- servlet.jar for the servlet
- avalon and logging for the base library.
There ought to be a less messy approach. It could be an idea
to move the various packages to different base directories,
making FOP essentially a multi-subproject project similar
to jakarta commons. This way each subpackage has its own
buildfile and lib directory, and dependencies become more
clear. In order to manage the cross package dependencies and
dependencies outside of FOP, Maven seems to be the tool of
choice. Unfortunately, I'm not enough of a Maven wizard to
asses this completely. Is there somebody out there with more
time at hand to look at these issues?
BTW
1. I'd like to get rid of the servlet.jar in our CVS.
2. If we standardize on JDK 1.4 as base (as it currently
 is), we could drop the Xerces, Xalan and xml-api jars as
 well. Our Jars seem to be somewhat outdated anyway.
J.Pietschmann

Re: FOP components (was: Re: Avalon integration: First batch of changes,Logging)

[Oleg Tkachenko]

J.Pietschmann wrote:

> - If the FO objects are primarily data holders, why
>   have them at all, instead of using a standard DOM?
I believe standard DOM implementations are obviously too synchronized to 
provide thread-safe access, while fo tree is built sequentially and is 
read-only after its building is done, so we have more possibilities to 
optimize it.

-- 
Oleg Tkachenko
Multiconn International, Israel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP components (was: Re: Avalon integration: First batch of changes, Logging)

[Jeremias Maerki]

 transition to Avalon. And I'm essentially alone at
the moment. Nicola Ken Barozzi has once offered his assistance but he
seems to be too involved in too many projects. So I concentrate only on
slowly trying to show a way towards adoption of Avalon which I started
with looking over logging which in turn is the first step in the Avalon
life-cycle. That's also what we did at work when we rewrote our system
based on Avalon. When I'm back from holidays I will again try to get the
resources to work on FOP but I can't tell what's going to happen.

> If I'd be asked for components in FOP, I'd start with
> the components FOP provides to the external world. A
> good starting point would be the FOP CLI, which can be
> easily seen as a composition of an XML parser, an
> optional XSLT processor, a FOP core layout component
> and a renderer, with the latter two provided by the FOP
> team. What else components do we have to export?

I don't think CLI is a good starting point because it's just a little
wrapper around the high-level API for FOP. By the way, I should really
reread the API discussion we started two months ago. Anyway, from the
outside I'd like to view FOP as a simple transformer/morpher. The
renderer should, for example, be an internal thing that may, of course,
be configured, but should not be visible to the outside. FOP is
essentially:

input --> transform/morph --> output

where input and output are just parameters to a call to FOPs processor.
From the outside you shouldn't have to care whether FOP uses an AT renderer
or a structure renderer.

And I think this processor/transformer/morpher is the only component
that should normally be exported.

> The other approach is bottom-up: Which common, at least
> potentially reusable services (or components) do FOP
> components use? Immediately come to mind:
> - Logging and XML parsing of course.
> - Sources for external graphics, including customisable
>resolvers.
> - Fonts: getting metrics and character mappings for the
>layout core, perhaps more for renderers.
> - Components implementing inline-foreign-objects :-)

Yes, and:
- Temporary storage facilities (for pages with forward references, for
  the AWT viewer, for renderers that will write the header of the
  output file at the end of rendering etc.)
- Image loading
- Caching of images
- line-breaking algorithms, perhaps

There may be more. I'm going to document this once I get to the point
where I really have the full overview.

> Again, what else obvious components do we use? I'd like
> to add stuff like PDF encryption, but I don't know enough
> about this to decide how tight this has to be integrated
> into the PDF renderer.

No, I think it is an agreement that the PDF library should become a
fully detachable part of FOP. PDF encryption will likely be done in the
PDF package and not in the renderer. The renderer should only use the
PDF library. I'm not so sure if the PDF library is really a component,
because it mostly consists of data holding classes. But maybe it needs
to be refactored a bit to separate logic from data holding like for the
FO tree.

As an aside: Quite often libraries such as a PDF library is avalonized
by creating a little wrapper around it. This was done with Tomcat for
example. The wrapper is then only a well-defined entry point to the
enclosed library/component/package.

> Answers and Comments?

I answered as well as I could. I hope it helps a bit.


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP components (was: Re: Avalon integration: First batch ofchanges, Logging)

[Keiron Liddle]

On Tue, 2002-08-13 at 23:15, J.Pietschmann wrote:
> Well, I'm not a real Avalon guru (and actually not the
> greatest of the Avalon fans, after several dozen hours
> of stepping through Excalibur stuff in a Cocoon
> application). Therefore I need some explanations (read past
> the questions first):
> - What's the advantage of transferring functionality of
>managing layout from the FO objects to layout managers?
>I understand there need objects managing layout of pages
>and lines, which do not have a FO counterpart, but for
>the other stuff?

No-one has come up with a layout that works from within the FO tree.
Getting the layout outside the fo tree really does make a big difference
in achieving the layout.
For example a block doesn't need to know about lots of other parts of
the fo tree in order to do the layout. The layout managers can handle
the fo tree and let parts be garbage collected once they are finished
with. It is more difficult to do this inside the fo tree.

> - If the FO objects are primarily data holders, why
>have them at all, instead of using a standard DOM?

I think DOM would mean that the whole document must be in memory at
once. It is easier to deal with if we can let the FO tree have methods
to access views of the data it contains. eg. getting table columns.

> - What's the advantage of layout managers being Avalon
>components?

If anything I would think the the "layout manager set" would be a
component, using some sort of factory to create the individual layout
managers. I don't see any particular need for this at the moment.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: FOP components (was: Re: Avalon integration: First batch ofchanges, Logging)

[Kevin O'Neill]

> Again, what else obvious components do we use? I'd like
> to add stuff like PDF encryption, but I don't know enough
> about this to decide how tight this has to be integrated
> into the PDF renderer.

I've been having a look at encryption and components could be used
though to supply say no vs 40 bit vs 128 bit encryption.

The encryption "component" would need to be available before any streams
where created the absence of a encryption component would produce an
unencrypted document.

Just thoughts.


-k.

-- 
If you don't test then your code is only a collection of bugs which 
apparently behave like a working program. 

Website: http://radio.weblogs.com/0111457/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

FOP components (was: Re: Avalon integration: First batch of changes,Logging)

[J.Pietschmann]

Jeremias Maerki <[EMAIL PROTECTED]> wrote:
 > The FO objects are primarily just data holder, so it doesn't make
 > sense to make them too heavy-weight. They need to be as light-weighted
 > as possible to save memory. Most of the logic is transferred to the
 > layout managers. And the layout managers are components/services. They
 > will eventually conform to the Avalon lifecycle.

Well, I'm not a real Avalon guru (and actually not the
greatest of the Avalon fans, after several dozen hours
of stepping through Excalibur stuff in a Cocoon
application). Therefore I need some explanations (read past
the questions first):
- What's the advantage of transferring functionality of
   managing layout from the FO objects to layout managers?
   I understand there need objects managing layout of pages
   and lines, which do not have a FO counterpart, but for
   the other stuff?
- If the FO objects are primarily data holders, why
   have them at all, instead of using a standard DOM?
- What's the advantage of layout managers being Avalon
   components?

My understanding is that a component framework, and in
particular Avalon, provides mechanisms for conveniently
configuring and composing objects as well as some often
used services like logging, therefore boosting developer
productivity. In order to sell it to *users* of the
developed software, the framework should provide something
for them as well, like caching and saving configuration
and composition overhead by recycling objects, rather
than only having a hefty ressource usage tag attached.
In order to get the latter, the objects both have to be
a bit cooperative and have to be either being a
composite or part of a composition, or have some
significant configuration data.
You know, on the Cocoon mailing list there are now and
then complaints about "over-Avalonization", which means
using Avalon for objects too small or too specialized so
that only the developer gets a benefit (however small),
while the user gets the overhead.

If I'd be asked for components in FOP, I'd start with
the components FOP provides to the external world. A
good starting point would be the FOP CLI, which can be
easily seen as a composition of an XML parser, an
optional XSLT processor, a FOP core layout component
and a renderer, with the latter two provided by the FOP
team. What else components do we have to export?

The other approach is bottom-up: Which common, at least
potentially reusable services (or components) do FOP
components use? Immediately come to mind:
- Logging and XML parsing of course.
- Sources for external graphics, including customisable
   resolvers.
- Fonts: getting metrics and character mappings for the
   layout core, perhaps more for renderers.
- Components implementing inline-foreign-objects :-)
Again, what else obvious components do we use? I'd like
to add stuff like PDF encryption, but I don't know enough
about this to decide how tight this has to be integrated
into the PDF renderer.

Answers and Comments?

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]