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

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]

On 13.08.2002 23:15:39 J.Pietschmann wrote:
> 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).

I'm no Avalon guru, either, but I'm a big fan. We use it at work with
great success and I would never consider throwing that out again.

> 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?

Keiron answered this already. I'd just like to add that in this approach
information holding and layout logic get separated which leads to a
cleaner design. 

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

See Keiron's answer. And I think that a DOM would be too generic making
the code hard to read. The FO objects can be optimized to their tasks.

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

Let me explain that by showing what an Avalon container does for you:
- You can define a configuration for a component to fine-tune its
  behaviour.
- It provides factory services which can be configured. That means you
  can have multiple implementations of the same interface and define
  in configuration which one to instantiate at runtime. We've already
  had such a case for line-breaking, I think, where Keiron and Karen
  both had an implementation. We could, for example, have specialized
  implementations for languages such as Japanese, if that makes sense.
  The implementations could be looked up based on the language property
  making the code itself clearer.
- It provides pooling services. Layout managers (or renderers etc.)
  could be reused instead of recreated. If it can be used in a
  multithreaded way, even better.

Sure, you could have that without Avalon, but you would have to write a
lot of code just to provides this functionality. You'd have to debug, to
maintain.
  
> 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.

Correct. That's what it does.

> 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.

Avalon CAN do that.

> 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.

I got a bit of that following the Avalon mailing lists. I think this may
have happened, because the devs there were/are in the process of
learning how to work with Avalon. The Avalon guys are also still
learning. From following the mailing list I think at least the Avalon
devs have identified this problem and they are constantly trying to
improve documentation to communicate what they have learned.

I don't intend to over-avalonize FOP. As I said before it doesn't make
sense to spread Avalon in to every corner of FOP (the FO tree for
example). The most important thing is to identify the real components.
Maybe they overdid it at Cocoon. I can't tell. What I intend with Avalon
is to improve code reuse (factory services, pooling/recycling, caching,
URI resolving, resource loading etc. exist in Avalon) and to help
improving overall design by promoting SoC and IoC. There are other
benefits but also the fact that Avalon has a relatively steep learning
curve. Well, nowadays even the Jakarta Commons people don't all simply
say no to Avalon.

The problem I have is the fact that currently I cannot dedicate enough
time to do the full 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 adoptio

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]