You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Simon Pepping <sp...@leverkruid.nl> on 2004/12/30 13:16:46 UTC
Re: cvs commit: xml-fop/src/java/org/apache/fop/datatypes LengthBase.java
On Tue, Dec 28, 2004 at 06:03:13PM -0000, jeremias@apache.org wrote:
>
> Index: LengthBase.java
> ===================================================================
> RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/datatypes/LengthBase.java,v
> retrieving revision 1.8
> retrieving revision 1.9
> diff -u -r1.8 -r1.9
> --- LengthBase.java 28 Oct 2004 10:00:19 -0000 1.8
> +++ LengthBase.java 28 Dec 2004 18:03:12 -0000 1.9
> @@ -20,6 +20,7 @@
>
> import org.apache.fop.fo.Constants;
> import org.apache.fop.fo.FObj;
> +import org.apache.fop.fo.IntrinsicSizeAccess;
> import org.apache.fop.fo.PropertyList;
> import org.apache.fop.fo.expr.PropertyException;
>
> @@ -122,13 +128,15 @@
> case BLOCK_HEIGHT:
> return parentFO.getLayoutDimension(PercentBase.BLOCK_BPD).intValue();
> case CONTAINING_REFAREA: // example: start-indent, end-indent
> - {
> //FONode fo;
> //for (fo = parentFO; fo != null && !fo.generatesReferenceAreas();
> // fo = fo.getParent());
> //return (((fo != null) && (fo instanceof FObj)) ? ((FObj)fo).getContentWidth() : 0);
> return 0;
> - }
> + case IMAGE_INTRINSIC_WIDTH:
> + return ((IntrinsicSizeAccess)propertyList.getFObj()).getIntrinsicWidth();
> + case IMAGE_INTRINSIC_HEIGHT:
> + return ((IntrinsicSizeAccess)propertyList.getFObj()).getIntrinsicHeight();
> case CUSTOM_BASE:
> //log.debug("!!! LengthBase.getBaseLength() called on CUSTOM_BASE type !!!");
> return 0;
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? 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?
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: cvs commit: xml-fop/src/java/org/apache/fop/fo FObj.java IntrinsicSizeAccess.java
Posted by 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
Posted by 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
Posted by 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
Re: cvs commit: xml-fop/src/java/org/apache/fop/datatypes LengthBase.java
Posted by 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/datatypes LengthBase.java
Posted by Finn Bock <bc...@worldonline.dk>.
Simon Pepping wrote:
> On Tue, Dec 28, 2004 at 06:03:13PM -0000, jeremias@apache.org wrote:
>
>>
>> Index: LengthBase.java
>> ===================================================================
>> RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/datatypes/LengthBase.java,v
>> retrieving revision 1.8
>> retrieving revision 1.9
>> diff -u -r1.8 -r1.9
>> --- LengthBase.java 28 Oct 2004 10:00:19 -0000 1.8
>> +++ LengthBase.java 28 Dec 2004 18:03:12 -0000 1.9
>> @@ -20,6 +20,7 @@
>>
>> import org.apache.fop.fo.Constants;
>> import org.apache.fop.fo.FObj;
>> +import org.apache.fop.fo.IntrinsicSizeAccess;
>> import org.apache.fop.fo.PropertyList;
>> import org.apache.fop.fo.expr.PropertyException;
>>
>> @@ -122,13 +128,15 @@
>> case BLOCK_HEIGHT:
>> return parentFO.getLayoutDimension(PercentBase.BLOCK_BPD).intValue();
>> case CONTAINING_REFAREA: // example: start-indent, end-indent
>> - {
>> //FONode fo;
>> //for (fo = parentFO; fo != null && !fo.generatesReferenceAreas();
>> // fo = fo.getParent());
>> //return (((fo != null) && (fo instanceof FObj)) ? ((FObj)fo).getContentWidth() : 0);
>> return 0;
>> - }
>> + case IMAGE_INTRINSIC_WIDTH:
>> + return ((IntrinsicSizeAccess)propertyList.getFObj()).getIntrinsicWidth();
>> + case IMAGE_INTRINSIC_HEIGHT:
>> + return ((IntrinsicSizeAccess)propertyList.getFObj()).getIntrinsicHeight();
>> case CUSTOM_BASE:
>> //log.debug("!!! LengthBase.getBaseLength() called on CUSTOM_BASE type !!!");
>> return 0;
>
>
> 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.
regards,
finn