Re: cvs commit: xml-fop/src/java/org/apache/fop/datatypes LengthBase.java

[Jeremias Maerki <de...@greenmail.ch>]

I'm trying to understand what's going on here. One thing that strikes me
as odd is that PropertyList.convertAttributeToProperty() always
contructs Properties based on the parentFO. Normally, this is probably
ok since most calculation bases are the parent FOs but in the case of
content-width/height it's the context FO itself that provides the base
(the intrinsic image size).

I've rewritten my latest addition so it goes over a getLayoutDimension()
call but left the rest as is for the moment (still uses the property
list). I'll try to have another shot at it later.

On 30.12.2004 20:35:54 Finn Bock wrote:
> > I am surprised to find the property list here. If I understand Finn's
> > restructuring of the usage of property lists, it was the intention
> > that all references to the property lists are released, so that they
> > can be GC'ed. The exceptions are the subtree under Marker and the line
> > of ancestors of RetrieveMarker. This patch reveals that LengthBase
> > maintains a reference to the property list. Perhaps that is an
> > oversight in the restructuring? 
> 
> Indeed.
> 
> > Perhaps the references to the
> > property list and to the parent FO might be replaced by a reference to
> > the FO to which the property using this LengthBase belongs. But I
> > would not know how to replace the method
> > PropertyList.getInherited(). Perhpaps Finn wants to take a look at
> > this?
> 
> Unfortunately not at the moment where real work takes its toll.
> 
> The idea was that all base values was assigned on the FObj in 
> layoutDimension, including font sizes. And that also goes for image sizes.
> 
> In the longer term the layoutDimension should be available in a context 
> object that is passed into all Length.getValue(context) calls.


Jeremias Maerki

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo FObj.java IntrinsicSizeAccess.java

[Glen Mazza <gr...@yahoo.com>]

+1!  Ausgezeichnet!  Danke...

Glen

--- Jeremias Maerki <de...@greenmail.ch> wrote:

> Sorry, I'm so used to using A-F Enums that I didn't
> think about that.
> I've fixed this and hope that you can agree with my
> change now.
> 

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo FObj.java IntrinsicSizeAccess.java

[Jeremias Maerki <de...@greenmail.ch>]

Sorry, I'm so used to using A-F Enums that I didn't think about that.
I've fixed this and hope that you can agree with my change now.

On 03.01.2005 14:51:00 Glen Mazza wrote:
> Jeremias,
> 
> Would you please elaborate on the need for this?  I
> want to make sure that adding an additional dependency
> on the Avalon project is passing a cost-benefit
> analysis here.
> 
> We're not a fluffy hi-level word processing system
> --we are a very low-level application (like a
> compiler), that is in turn will be integrated into
> other applications.  Therefore we have to be careful
> not to include gratuitous linkages to other libraries.
>  (That we already--currently--use Avalon for
> configuration does not excuse us from this principle. 
> Linkages should be kept at a minimum.  For example, we
> had an option of using Commons Configuration instead
> of Avalon.  Now, if we do so, we're still required to
> keep Avalon just because of your change below.)
> 
> What is lost if we don't link to Avalon here?  How
> often have we failed by relying on Java variables? 
> How come Xalan and Xerces can work without Avalon
> variables but FOP can't?
> 
> Also, why is the Cocoon Team in error for trying to
> detach themselves from Avalon[1]?  Why are those 15
> committers wrong?
> 
> I'm -1 (veto) on this change.
> 
> Glen
> 
> [1]
> http://marc.theaimsgroup.com/?t=108004833700001&r=1&w=2
> 
> --- jeremias@apache.org wrote:
> >
> >   Made the LayoutDimension keys a subclass of Avalon
> > Framework's Enum to make the thing more
> > debugger-friendly and more type-safe.
> >   



Jeremias Maerki

Re: cvs commit: xml-fop/src/java/org/apache/fop/datatypes LengthBase.java

[Simon Pepping <sp...@leverkruid.nl>]

On Mon, Jan 03, 2005 at 02:20:25PM +0100, Jeremias Maerki wrote:
> I'm trying to understand what's going on here. One thing that strikes me
> as odd is that PropertyList.convertAttributeToProperty() always
> contructs Properties based on the parentFO. Normally, this is probably
> ok since most calculation bases are the parent FOs but in the case of
> content-width/height it's the context FO itself that provides the base
> (the intrinsic image size).

PropertyList.convertAttributeToProperty() calls prop =
propertyMaker.make(this, attributeValue, parentFO). If I remember
correctly, the parentFO is only used if the attribute value is
'inherit'. Otherwise it converts the attribute value into a property
value object. See my description in
http://www.leverkruid.nl/FOP/html/ch09s02.html.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl