Re: Connection between FObj and Area

[Tibor Vyletel]

- Original Message - 
From: "Finn Bock" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 29, 2004 10:17 PM
Subject: Re: Connection between FObj and Area


> [Tibor Vyletel]
>
> > Hello Fopsters,
> >
> > I use FOP (dev 1.0) in a bit different scenario as you. My renderer
works in
> > GEF framework. Till now, I have hacked simple change in relevant layout
> > managers:
> >
> > BlockLayoutManager.getParentArea(Area childArea) {
> > ...
> > // this creates connection between fobj and curBlockArea:
> > curBlockArea.addTrait(Trait.ID_AREA, this.fobj);
> > ...
> > }
> >
> > This solution is just a hack and a maintainance nightmare, as the design
is
> > constantly changing ;)
>  >
> > I am aware that described construction is breaking memory optimization
> > goals, however I need it to achieve my goal: enable editing after the
> > rendering process and make this editing as responsive as possible.
> >
> > Lately (in fact, after the removal of getID() method from FObj), I've
been
> > thinking about more elegant solution which would allow me to track a
mapping
> > between FObjs and Areas in cases I need it. I know that any technique
which
> > would force this connection in standard processing would not be
possible,
> > because its effects on memory consumption would be relevant.
> >
> > My alternative idea is:
> > - create AreaFactory interface (or abstract class) which would be
> > responsible for creation of areas. Provide default implementating class
with
> > today's functionality scattered among LMs.
> > There are to choices how to design this interface:
> > a) with one strong method: Area createArea(LayoutManager lm, FObj
fobj,
> > Object constraints)
> > b) with a set of specialized methods for creation of different area
> > types:
> > Inline createInline(...) {}
> > Block createBlock(...) {}
> > ...
>
> Would you need to return subclasses of Inline and Block etc? Or would
> you just set various additional traits such as this.fobj?

Yes, my intention is to create subclasses and return them through my own
implementation of AbstractAreaFactory. Although I have to admit that at this
moment I have just one added functionality in these subclasses in mind: they
will be holding a reference to FObj.

>
> > - refactor instantiation of area objects in layout managers: remove all
> > direct instantiations and replace them with calls to DefaultAreaFactory
> > - solve how to configure AreaFactory before layouting process. Layout
> > managers don't have access to UserAgent so far, so the best method would
> > probably be a pair of static methods:
>
> Actually, LMs normally has access to the fobj and through that the
> FONode.getUserAgent() method.
>

Ups, I did not consider this option: Of course, AreaFactory setting through
UserAgent is much more elegant solution than a static method in
AbstractAreaFactory class.

> > AreaFactory AreaFactory.getFactory()
> > AreaFactory.setFactory(AreaFactory factory)
> > and this constructrion in LMs:
> > currArea = AreaFactory().getFactory().create
> >
> > When this pattern would be applied, my problem would be simply solved by
> > creation of descendants for some Area classes, which would hold
reference to
> > the FObj data. Default implementation would bring no extra memory
> > consumption and/or relevant speed degradation.
> >
> > The reason why I have written this mail, is to obtain some feedback
about
> > suggested refactoring. In fact I am forced to do some changes to the FOP
> > code because of my project's special requirements.
>
> Would you still need to change FOP sources, even after your proposal was
> implemented?

This refactoring (that I want to implement myself and send it to the team as
a patch) would allow me to make parallel (pluginable) implementation of some
Area classes. These new classes would not be a part of the FOP itself, but
would be included in my own packages. In this case, I could develop my own
code and still could be able to use FOP and whole its functionality
(particulary LMs and existing Area classes).

Just to describe my situation now: When I update my local copy of FOP from
your CVS (let's say once a week), I have to make my own build of fop.jar
(where some layout managers contain one special line of code) and then use
this package file in my plugins.

>
> > The real payback for me
> > would the case when all the maintainance nightmares would be gone and
this
> > can happen only when creation of Areas is more modular. I think that
> > modularization of this could bring its two cents to the quality of the
FOP's
> > source code.
>
>  From your description I sort of get the impression that a smaller
> change, such having all LMs call a new method, say
>
> AbstractLayoutManager.setGeneralTraits(FObj)
>
> which has a default empty implementation. Would it be good enough for
> you to change AbstractLayoutManager to add your special requirements?
>
> regards,

Re: Connection between FObj and Area

[Finn Bock]

[Tibor Vyletel]
Hello Fopsters,
I use FOP (dev 1.0) in a bit different scenario as you. My renderer works in
GEF framework. Till now, I have hacked simple change in relevant layout
managers:
BlockLayoutManager.getParentArea(Area childArea) {
...
// this creates connection between fobj and curBlockArea:
curBlockArea.addTrait(Trait.ID_AREA, this.fobj);
...
}
This solution is just a hack and a maintainance nightmare, as the design is
constantly changing ;)
>
I am aware that described construction is breaking memory optimization
goals, however I need it to achieve my goal: enable editing after the
rendering process and make this editing as responsive as possible.
Lately (in fact, after the removal of getID() method from FObj), I've been
thinking about more elegant solution which would allow me to track a mapping
between FObjs and Areas in cases I need it. I know that any technique which
would force this connection in standard processing would not be possible,
because its effects on memory consumption would be relevant.
My alternative idea is:
- create AreaFactory interface (or abstract class) which would be
responsible for creation of areas. Provide default implementating class with
today's functionality scattered among LMs.
There are to choices how to design this interface:
a) with one strong method: Area createArea(LayoutManager lm, FObj fobj,
Object constraints)
b) with a set of specialized methods for creation of different area
types:
Inline createInline(...) {}
Block createBlock(...) {}
...
Would you need to return subclasses of Inline and Block etc? Or would 
you just set various additional traits such as this.fobj?

- refactor instantiation of area objects in layout managers: remove all
direct instantiations and replace them with calls to DefaultAreaFactory
- solve how to configure AreaFactory before layouting process. Layout
managers don't have access to UserAgent so far, so the best method would
probably be a pair of static methods:
Actually, LMs normally has access to the fobj and through that the 
FONode.getUserAgent() method.

AreaFactory AreaFactory.getFactory()
AreaFactory.setFactory(AreaFactory factory)
and this constructrion in LMs:
currArea = AreaFactory().getFactory().create
When this pattern would be applied, my problem would be simply solved by
creation of descendants for some Area classes, which would hold reference to
the FObj data. Default implementation would bring no extra memory
consumption and/or relevant speed degradation.
The reason why I have written this mail, is to obtain some feedback about
suggested refactoring. In fact I am forced to do some changes to the FOP
code because of my project's special requirements. 
Would you still need to change FOP sources, even after your proposal was 
implemented?

The real payback for me
would the case when all the maintainance nightmares would be gone and this
can happen only when creation of Areas is more modular. I think that
modularization of this could bring its two cents to the quality of the FOP's
source code.
From your description I sort of get the impression that a smaller 
change, such having all LMs call a new method, say

   AbstractLayoutManager.setGeneralTraits(FObj)
which has a default empty implementation. Would it be good enough for 
you to change AbstractLayoutManager to add your special requirements?

regards,
finn

Re: Connection between FObj and Area

[Glen Mazza]

--- Tibor Vyletel <[EMAIL PROTECTED]> wrote:

> Hello Glen,
> 
> I am aware of the LMs' function in the system. The
> problem is that their
> instantiation is hardcoded, too. At least, I don't
> see any quick method how
> to make a descendant of a LM and "plug" this new
> class (with just a little
> change) to the layouter tree. 

I see--don't worry, you're not the only one with this
type of request.  IIRC Finn (and Simon) wanted
something like that a few months back.  I believe
involving maker classes to allow you to easily
choose/plugin the LM's to use.  So you may see
something like this in the future that may be of help
to you.  

> As to the changes in the system's complexity and
> OOD:
> Introducing abstraction during creation of objects
> is commonly used pattern
> in SW design.

Just so you understand my perspective, layout is very,
very difficult coding, and relatively few can
comfortably work with it.  (Myself, I can do some very
simple changes, very slowly.)  Adding
abstractions--additional moving parts--can make the
coding even harder to understand (approaching IQ 200
range?), outside of the grasp of even more people, so
it's always best to get the code working first
*before* placing the abstractions in (iff they need to
be put in).  

Also, as I found multiple times, the abstractions can
prevent fundamental relationships (that can lead to
very nice simplifications) from becoming apparent. 
We're still at the stage where we need to be looking
at those relationships.

Thanks,
Glen

Re: Connection between FObj and Area

[Tibor Vyletel]

Hello Glen,

I am aware of the LMs' function in the system. The problem is that their
instantiation is hardcoded, too. At least, I don't see any quick method how
to make a descendant of a LM and "plug" this new class (with just a little
change) to the layouter tree. Maybe similar analogy as I described in
previous mail might be applicable in this place, too.

As to the changes in the system's complexity and OOD:
Introducing abstraction during creation of objects is commonly used pattern
in SW design. The change in the FOP system after application of proposed
change would be restricted to creation of two new classes
(AbstractAreaFactory, DefaultAreaFactory) and following refactoring in LMs
of this kind:
before:after:
currBlockArea = new Block()  --> currBlockArea = new
AbstractAreaFactory

.getFactory().createBlock(...)
In the first phase, implementation of "create" method would be trivial:
DefaultAreaFactory:
public Block createBlock() {
return new Block();
}

I agree, such implementation might not be worth the effort. On the other
hand, whole system is given new parametrizable feature. And secondly,
"create" methods will eventually become larger as a place for reuse of code
common directly after the instantiation of area object (eg:
TraitSetter.add...).

I want to say, that I understand that you might see my request as absolutely
useless. I can just repeat myself: I work in a different scenario. I
appreciate the work your are doing and I use FOP for long time. I want to
use layouting module in future, but my renderer/editor requires multiple
runs on an input document which (usually) changes just a little beween two
renderings. Till now, I have been using the simplest method: I had changed
underlying XML data according to users actions and then invoked full FOP's
run. This solution is very slow when document is larger. The ability to
interact with FObjs in the controller layer (GEF's editparts in my
environment) would be a great help.

Tibor

PS: Euromath project: http://euromath2.sourceforge.net/


- Original Message - 
From: "Glen Mazza" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 29, 2004 7:37 PM
Subject: Re: Connection between FObj and Area


> I'm quite leery of the changes he's proposing at this
> time.  The complexity of the system would shoot
> through the roof, it's not a solid OO/logical design
> (our LayoutManagers are currently responsible for the
> creation of areas, as they should be), and futhermore,
> I find his "more modular" arguments unconvincing,
> suspect at best.
>
> Glen
>
> --- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
> > Tibor,
> >
> > I will leave the techical side for the devs that are
> > really familiar
> > with this part of FOP. I'm not. Yet, anyway. But I
> > wanted to invite you
> > to share with us your requirements and help with
> > directly improving the
> > code. Even if you're not a committer you are allowed
> > and encouraged to
> > make suggestions. You can also send patches. Maybe
> > someday we may even
> > be able to welcome you in the team.
> >
> > It sounds like you're building an FO editor using
> > FOP in the backrgound.
> > I take it you mean the Eclipse GEF, not the Tigris
> > GEF, right? Can you
> > provide a link to or some info on your project? I'm
> > simply curious.
> >
> > On 29.10.2004 17:35:57 Tibor Vyletel wrote:
> > > Hello Fopsters,
> > >
> > > I use FOP (dev 1.0) in a bit different scenario as
> > you. My renderer works in
> > > GEF framework. Till now, I have hacked simple
> > change in relevant layout
> > > managers:
> > >
> > > BlockLayoutManager.getParentArea(Area childArea) {
> > > ...
> > > // this creates connection between fobj and
> > curBlockArea:
> > > curBlockArea.addTrait(Trait.ID_AREA,
> > this.fobj);
> > > ...
> > > }
> > >
> > > This solution is just a hack and a maintainance
> > nightmare, as the design is
> > > constantly changing ;)
> > >
> > > I am aware that described construction is breaking
> > memory optimization
> > > goals, however I need it to achieve my goal:
> > enable editing after the
> > > rendering process and make this editing as
> > responsive as possible.
> > >
> > > Lately (in fact, after the removal of getID()
> > method from FObj), I've been
> > > thinking about more elegant solution which would
> > allow me to track a mapping
> > > between FObjs and Areas in cases I need it. I know
> > that any technique which
> > > would force this connection in standard processing
> > would not be possible,
> > > because its effects on memory consumption would be
> > relevant.
> > >
> > > My alternative idea is:
> > > - create AreaFactory interface (or abstract class)
> > which would be
> > > responsible for creation of areas. Provide default
> > implementating class with
> > > today's functionality scattered among LMs.
> > > There are to choices how to design this
> > interface:
> >

Re: Connection between FObj and Area

[Glen Mazza]

I'm quite leery of the changes he's proposing at this
time.  The complexity of the system would shoot
through the roof, it's not a solid OO/logical design
(our LayoutManagers are currently responsible for the
creation of areas, as they should be), and futhermore,
I find his "more modular" arguments unconvincing,
suspect at best.

Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> Tibor,
> 
> I will leave the techical side for the devs that are
> really familiar
> with this part of FOP. I'm not. Yet, anyway. But I
> wanted to invite you
> to share with us your requirements and help with
> directly improving the
> code. Even if you're not a committer you are allowed
> and encouraged to
> make suggestions. You can also send patches. Maybe
> someday we may even
> be able to welcome you in the team.
> 
> It sounds like you're building an FO editor using
> FOP in the backrgound.
> I take it you mean the Eclipse GEF, not the Tigris
> GEF, right? Can you
> provide a link to or some info on your project? I'm
> simply curious.
> 
> On 29.10.2004 17:35:57 Tibor Vyletel wrote:
> > Hello Fopsters,
> > 
> > I use FOP (dev 1.0) in a bit different scenario as
> you. My renderer works in
> > GEF framework. Till now, I have hacked simple
> change in relevant layout
> > managers:
> > 
> > BlockLayoutManager.getParentArea(Area childArea) {
> > ...
> > // this creates connection between fobj and
> curBlockArea:
> > curBlockArea.addTrait(Trait.ID_AREA,
> this.fobj);
> > ...
> > }
> > 
> > This solution is just a hack and a maintainance
> nightmare, as the design is
> > constantly changing ;)
> > 
> > I am aware that described construction is breaking
> memory optimization
> > goals, however I need it to achieve my goal:
> enable editing after the
> > rendering process and make this editing as
> responsive as possible.
> > 
> > Lately (in fact, after the removal of getID()
> method from FObj), I've been
> > thinking about more elegant solution which would
> allow me to track a mapping
> > between FObjs and Areas in cases I need it. I know
> that any technique which
> > would force this connection in standard processing
> would not be possible,
> > because its effects on memory consumption would be
> relevant.
> > 
> > My alternative idea is:
> > - create AreaFactory interface (or abstract class)
> which would be
> > responsible for creation of areas. Provide default
> implementating class with
> > today's functionality scattered among LMs.
> > There are to choices how to design this
> interface:
> > a) with one strong method: Area
> createArea(LayoutManager lm, FObj fobj,
> > Object constraints)
> > b) with a set of specialized methods for
> creation of different area
> > types:
> > Inline createInline(...) {}
> > Block createBlock(...) {}
> > ...
> > 
> > - refactor instantiation of area objects in layout
> managers: remove all
> > direct instantiations and replace them with calls
> to DefaultAreaFactory
> > - solve how to configure AreaFactory before
> layouting process. Layout
> > managers don't have access to UserAgent so far, so
> the best method would
> > probably be a pair of static methods:
> > AreaFactory AreaFactory.getFactory()
> > AreaFactory.setFactory(AreaFactory factory)
> > and this constructrion in LMs:
> > currArea =
> AreaFactory().getFactory().create
> > 
> > When this pattern would be applied, my problem
> would be simply solved by
> > creation of descendants for some Area classes,
> which would hold reference to
> > the FObj data. Default implementation would bring
> no extra memory
> > consumption and/or relevant speed degradation.
> > 
> > The reason why I have written this mail, is to
> obtain some feedback about
> > suggested refactoring. In fact I am forced to do
> some changes to the FOP
> > code because of my project's special requirements.
> The real payback for me
> > would the case when all the maintainance
> nightmares would be gone and this
> > can happen only when creation of Areas is more
> modular. I think that
> > modularization of this could bring its two cents
> to the quality of the FOP's
> > source code.
> > 
> > Best Regards,
> > 
> > Tibor Vyletel
> > Slovakia
> 
> 
> 
> Jeremias Maerki
> 
> 

Re: [Discussion/draft] XML Graphics setup

[Glen Mazza]

That's fine.

--- Clay Leeds <[EMAIL PROTECTED]> wrote:

> On Oct 29, 2004, at 8:36 AM, Glen Mazza wrote:
> > Well, the word "additional" implies something
> > preceding it, so if you want that order you need
> to
> > change "additional" on line two to "commands
> outside
> > of unsubscribing", i.e., don't do that ordering!
> >
> > Glen
> 
> I thought I was done, but how about:
>
---
> Apache XML Graphics Project URL:
> http://xmlgraphics.apache.org
> E-mail commands & help:   
> [EMAIL PROTECTED]
> Unsubscribe e-mail:
> [EMAIL PROTECTED]
>
=(END)===
> 
> CHANGES:
> - 63 chars wide
> - briefer, semantically correct description
> 
> Web Maestro Clay
> -- 
> Clay Leeds - <[EMAIL PROTECTED]>
> Webmaster/Developer - Medata, Inc. -
> 
> PGP Public Key:
> 
> 
> 

Re: [Discussion/draft] XML Graphics setup

[Clay Leeds]

On Oct 29, 2004, at 8:36 AM, Glen Mazza wrote:
Well, the word "additional" implies something
preceding it, so if you want that order you need to
change "additional" on line two to "commands outside
of unsubscribing", i.e., don't do that ordering!
Glen
I thought I was done, but how about:
---
Apache XML Graphics Project URL: http://xmlgraphics.apache.org
E-mail commands & help:[EMAIL PROTECTED]
Unsubscribe e-mail: [EMAIL PROTECTED]
=(END)===
CHANGES:
- 63 chars wide
- briefer, semantically correct description
Web Maestro Clay
--
Clay Leeds - <[EMAIL PROTECTED]>
Webmaster/Developer - Medata, Inc. - 
PGP Public Key: 

Re: Connection between FObj and Area

[Jeremias Maerki]

Tibor,

I will leave the techical side for the devs that are really familiar
with this part of FOP. I'm not. Yet, anyway. But I wanted to invite you
to share with us your requirements and help with directly improving the
code. Even if you're not a committer you are allowed and encouraged to
make suggestions. You can also send patches. Maybe someday we may even
be able to welcome you in the team.

It sounds like you're building an FO editor using FOP in the backrgound.
I take it you mean the Eclipse GEF, not the Tigris GEF, right? Can you
provide a link to or some info on your project? I'm simply curious.

On 29.10.2004 17:35:57 Tibor Vyletel wrote:
> Hello Fopsters,
> 
> I use FOP (dev 1.0) in a bit different scenario as you. My renderer works in
> GEF framework. Till now, I have hacked simple change in relevant layout
> managers:
> 
> BlockLayoutManager.getParentArea(Area childArea) {
> ...
> // this creates connection between fobj and curBlockArea:
> curBlockArea.addTrait(Trait.ID_AREA, this.fobj);
> ...
> }
> 
> This solution is just a hack and a maintainance nightmare, as the design is
> constantly changing ;)
> 
> I am aware that described construction is breaking memory optimization
> goals, however I need it to achieve my goal: enable editing after the
> rendering process and make this editing as responsive as possible.
> 
> Lately (in fact, after the removal of getID() method from FObj), I've been
> thinking about more elegant solution which would allow me to track a mapping
> between FObjs and Areas in cases I need it. I know that any technique which
> would force this connection in standard processing would not be possible,
> because its effects on memory consumption would be relevant.
> 
> My alternative idea is:
> - create AreaFactory interface (or abstract class) which would be
> responsible for creation of areas. Provide default implementating class with
> today's functionality scattered among LMs.
> There are to choices how to design this interface:
> a) with one strong method: Area createArea(LayoutManager lm, FObj fobj,
> Object constraints)
> b) with a set of specialized methods for creation of different area
> types:
> Inline createInline(...) {}
> Block createBlock(...) {}
> ...
> 
> - refactor instantiation of area objects in layout managers: remove all
> direct instantiations and replace them with calls to DefaultAreaFactory
> - solve how to configure AreaFactory before layouting process. Layout
> managers don't have access to UserAgent so far, so the best method would
> probably be a pair of static methods:
> AreaFactory AreaFactory.getFactory()
> AreaFactory.setFactory(AreaFactory factory)
> and this constructrion in LMs:
> currArea = AreaFactory().getFactory().create
> 
> When this pattern would be applied, my problem would be simply solved by
> creation of descendants for some Area classes, which would hold reference to
> the FObj data. Default implementation would bring no extra memory
> consumption and/or relevant speed degradation.
> 
> The reason why I have written this mail, is to obtain some feedback about
> suggested refactoring. In fact I am forced to do some changes to the FOP
> code because of my project's special requirements. The real payback for me
> would the case when all the maintainance nightmares would be gone and this
> can happen only when creation of Areas is more modular. I think that
> modularization of this could bring its two cents to the quality of the FOP's
> source code.
> 
> Best Regards,
> 
> Tibor Vyletel
> Slovakia



Jeremias Maerki

Re: [Discussion/draft] XML Graphics setup

[Glen Mazza]

Well, the word "additional" implies something
preceding it, so if you want that order you need to
change "additional" on line two to "commands outside
of unsubscribing", i.e., don't do that ordering!

Glen

--- Clay Leeds <[EMAIL PROTECTED]> wrote:

> On Oct 29, 2004, at 7:51 AM, Glen Mazza wrote:
> >
>
---
> >>> To unsubscribe e-mail:  
> [EMAIL PROTECTED]
> >>> For additional commands e-mail:
> [EMAIL PROTECTED]
> >>> Apache XML Graphics Project -- URL: 
> http://xmlgraphics.apache.org/
> >
>
=(END)===
> >
> > I'd like to see the "Apache XML Graphics Project"
> line
> > moved to the top (i.e., from line 3 to line 1).
> >
> > Glen
> 
> Good catch! Although my inner-perfectionist, thinks
> symmetry is king, 
> so I suggest:
> 
> =(CUT
> HERE)==
>
---
> Apache XML Graphics Project -- URL:  
> http://xmlgraphics.apache.org
> For additional commands e-mail:
> [EMAIL PROTECTED]
> To unsubscribe e-mail:  
> [EMAIL PROTECTED]
>
=(END)===
> 
> CHANGES:
> - removed the trailing '/' from the URL (identical
> to others)
> - makes the blue auto-href underlining more uniform
> - put unsubscribe at the bottom (where people tend
> to look anyway)
> 
> (I'm done now!)
> 
> Web Maestro Clay
> -- 
> Clay Leeds - <[EMAIL PROTECTED]>
> Webmaster/Developer - Medata, Inc. -
> 
> PGP Public Key:
> 
> 
> 

Connection between FObj and Area

[Tibor Vyletel]

Hello Fopsters,

I use FOP (dev 1.0) in a bit different scenario as you. My renderer works in
GEF framework. Till now, I have hacked simple change in relevant layout
managers:

BlockLayoutManager.getParentArea(Area childArea) {
...
// this creates connection between fobj and curBlockArea:
curBlockArea.addTrait(Trait.ID_AREA, this.fobj);
...
}

This solution is just a hack and a maintainance nightmare, as the design is
constantly changing ;)

I am aware that described construction is breaking memory optimization
goals, however I need it to achieve my goal: enable editing after the
rendering process and make this editing as responsive as possible.

Lately (in fact, after the removal of getID() method from FObj), I've been
thinking about more elegant solution which would allow me to track a mapping
between FObjs and Areas in cases I need it. I know that any technique which
would force this connection in standard processing would not be possible,
because its effects on memory consumption would be relevant.

My alternative idea is:
- create AreaFactory interface (or abstract class) which would be
responsible for creation of areas. Provide default implementating class with
today's functionality scattered among LMs.
There are to choices how to design this interface:
a) with one strong method: Area createArea(LayoutManager lm, FObj fobj,
Object constraints)
b) with a set of specialized methods for creation of different area
types:
Inline createInline(...) {}
Block createBlock(...) {}
...

- refactor instantiation of area objects in layout managers: remove all
direct instantiations and replace them with calls to DefaultAreaFactory
- solve how to configure AreaFactory before layouting process. Layout
managers don't have access to UserAgent so far, so the best method would
probably be a pair of static methods:
AreaFactory AreaFactory.getFactory()
AreaFactory.setFactory(AreaFactory factory)
and this constructrion in LMs:
currArea = AreaFactory().getFactory().create

When this pattern would be applied, my problem would be simply solved by
creation of descendants for some Area classes, which would hold reference to
the FObj data. Default implementation would bring no extra memory
consumption and/or relevant speed degradation.

The reason why I have written this mail, is to obtain some feedback about
suggested refactoring. In fact I am forced to do some changes to the FOP
code because of my project's special requirements. The real payback for me
would the case when all the maintainance nightmares would be gone and this
can happen only when creation of Areas is more modular. I think that
modularization of this could bring its two cents to the quality of the FOP's
source code.

Best Regards,

Tibor Vyletel
Slovakia

Re: [Discussion/draft] XML Graphics setup

[Clay Leeds]

On Oct 29, 2004, at 7:51 AM, Glen Mazza wrote:
---
To unsubscribe e-mail:   [EMAIL PROTECTED]
For additional commands e-mail: [EMAIL PROTECTED]
Apache XML Graphics Project -- URL:  http://xmlgraphics.apache.org/
=(END)===
I'd like to see the "Apache XML Graphics Project" line
moved to the top (i.e., from line 3 to line 1).
Glen
Good catch! Although my inner-perfectionist, thinks symmetry is king, 
so I suggest:

=(CUT HERE)==
---
Apache XML Graphics Project -- URL:   http://xmlgraphics.apache.org
For additional commands e-mail: [EMAIL PROTECTED]
To unsubscribe e-mail:   [EMAIL PROTECTED]
=(END)===
CHANGES:
- removed the trailing '/' from the URL (identical to others)
- makes the blue auto-href underlining more uniform
- put unsubscribe at the bottom (where people tend to look anyway)
(I'm done now!)
Web Maestro Clay
--
Clay Leeds - <[EMAIL PROTECTED]>
Webmaster/Developer - Medata, Inc. - 
PGP Public Key: 

RE: Defoe

[Victor Mote]

Clay Leeds wrote:

> I think it would be helpful for you both to include an 'examples' 
> section on your site to display the fruits of your labor (w 
> links to the FOs that generated them!).

That is a good idea. The FOray web site started out thinking of itself as an
extension of the FOP website (and therefore referring to it for basics like
example), and it still has that perspective. Changing that to a turnkey
operation is one of the reasons FOray 0.2 has been delayed.

Victor Mote

Re: [Discussion/draft] XML Graphics setup

[Glen Mazza]

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
>
---
> > To unsubscribe e-mail:  
> [EMAIL PROTECTED]
> > For additional commands e-mail:
> [EMAIL PROTECTED]
> > Apache XML Graphics Project -- URL: 
> http://xmlgraphics.apache.org/
> >
>
=(END)===
> > 
> > (removed commas, 'evened' it out r-l and now 68
> chars instead of 70 ;-)
> 
> Ah, here's my favourite nitpicker in action again.
> :-) Sorry for my
> sloppyness.
> 

I'd like to see the "Apache XML Graphics Project" line
moved to the top (i.e., from line 3 to line 1).

Glen

Re: Defoe

[Clay Leeds]

I think it would be helpful for you both to include an 'examples' 
section on your site to display the fruits of your labor (w links to 
the FOs that generated them!).

On Oct 29, 2004, at 5:02 AM, Victor Mote wrote:
Peter B. West wrote:
I've started a blog as a diary of Defoe development and, at
the moment, my learning experiences with Java 5.0, especially
Typesafe Enums and Generics.  If you drop in there from time
to time, you can see what I am up to.  Have you considered
one for FOray?
I actually spent some time on your blog yesterday, and I think it is
probably useful for the kind of work that you are doing. My work is 
much
more mundane, and, between commit logs and project documentation and
announcements, a blog would be pretty redundant for me (although the 
commit
log will be more useful when we are using Subversion). Probably the 
closest
thing to a blog that I have is:
http://www.foray.org/release.html

I haven't really craved the 5.0 features yet, but did finally decide a 
few
days ago to use 1.4 as a minimum, primarily to eliminate preprocessing
(developer productivity) and to use "assert".

Victor Mote

Web Maestro Clay
--
Clay Leeds - <[EMAIL PROTECTED]>
Webmaster/Developer - Medata, Inc. - 
PGP Public Key: 

RE: Defoe

[Victor Mote]

Peter B. West wrote:

> I've started a blog as a diary of Defoe development and, at 
> the moment, my learning experiences with Java 5.0, especially 
> Typesafe Enums and Generics.  If you drop in there from time 
> to time, you can see what I am up to.  Have you considered 
> one for FOray?

I actually spent some time on your blog yesterday, and I think it is
probably useful for the kind of work that you are doing. My work is much
more mundane, and, between commit logs and project documentation and
announcements, a blog would be pretty redundant for me (although the commit
log will be more useful when we are using Subversion). Probably the closest
thing to a blog that I have is:
http://www.foray.org/release.html

I haven't really craved the 5.0 features yet, but did finally decide a few
days ago to use 1.4 as a minimum, primarily to eliminate preprocessing
(developer productivity) and to use "assert".

Victor Mote

[GUMP@brutus]: Project xml-fop (in module xml-fop) failed

[Sam Ruby]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project xml-fop has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- xml-fop :  XSL-FO (Formatting Objects) processor


Full details are available at:
http://brutus.apache.org/gump/public/xml-fop/xml-fop/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [fop.jar] identifier set to project name
 -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/classes]
 -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/test-classes]
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/xml-fop/xml-fop/gump_work/build_xml-fop_xml-fop.html
Work Name: build_xml-fop_xml-fop (Type: Build)
Work ended in a state of : Failed
Elapsed: 30 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only gump 
[Working Directory: /usr/local/gump/public/workspace/xml-fop]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop/build/classes:/usr/local/gump/public/workspace/xml-fop/build/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-29102004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-29102004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-29102004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-29102004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-29102004.jar:/usr/local/gump/public/workspace/jfor/dist/lib/jfor-29102004.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar
-

junit:
[javac] Compiling 31 source files to 
/home/gump/workspaces2/public/workspace/xml-fop/build/test-classes
[javac] This version of java does not support the classic compiler; upgrading to 
modern
[javac] 
/home/gump/workspaces2/public/workspace/xml-fop/test/java/org/apache/fop/util/ASCII85InputStreamTestCase.java:25:
 warning: org.apac

[GUMP@brutus]: Project xml-fop (in module xml-fop) failed

[Sam Ruby]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project xml-fop has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 3 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- xml-fop :  XSL-FO (Formatting Objects) processor


Full details are available at:
http://brutus.apache.org/gump/public/xml-fop/xml-fop/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [fop.jar] identifier set to project name
 -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/classes]
 -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop/build/test-classes]
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/xml-fop/xml-fop/gump_work/build_xml-fop_xml-fop.html
Work Name: build_xml-fop_xml-fop (Type: Build)
Work ended in a state of : Failed
Elapsed: 30 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only gump 
[Working Directory: /usr/local/gump/public/workspace/xml-fop]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop/build/classes:/usr/local/gump/public/workspace/xml-fop/build/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-29102004/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-29102004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-29102004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-29102004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-29102004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-commons/io/dist/jakarta-commons-io-29102004.jar:/usr/local/gump/public/workspace/jfor/dist/lib/jfor-29102004.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar
-

junit:
[javac] Compiling 31 source files to 
/home/gump/workspaces2/public/workspace/xml-fop/build/test-classes
[javac] This version of java does not support the classic compiler; upgrading to 
modern
[javac] 
/home/gump/workspaces2/public/workspace/xml-fop/test/java/org/apache/fop/util/ASCII85InputStre