[PATCH] Support for percentages and table-units

[Finn Bock]

[Simon Pepping]

Finn,

I see you also solved another problem, viz. that fo:layout-master-set
did not return a proper IPD. 
Correct. There are, I'm certain, many more cases where the layout 
managers does not yet set all the dimensions needed to resolve all the 
different percentages.

However, I am not happy with your
solution. During the layout process, you feed the page dimensions back
into the FO tree, in PageLayoutManager.createPageAreas. 
Yes, and in BlockLayoutManager and in all the other LM that defines base 
length for percentages.

I think it
would be a better design if, in order to resolve the percent-based
properties, you would not climb the FO tree but the Area tree. That
avoids feeding back results from the Area tree into the FO tree.
The XSL spec says (XSL-PR/slice3.html#section-N1208-Conceptual-Procedure):

'The formatting object supplies parameters to its children based on the
traits of areas already in the area tree, possibly including areas
generated by the formatting object or its ancestors.'
Holding those parameters in the FO tree is one solution. Extracting
them from the area tree layed out up to that point is another
solution, 
But there is *no* areas layed out or even created at the point where we 
need resolved length. When getNextBreakPoss is called, we only have a 
series of BreakPoss's stored in different layout managers.

The Area objects are created much later when we have BreakPoss's for an 
entire page. PageLM then calls addAreas which recursively creates all 
the areas for the page.

which has the advantage that it does not load the FO tree
with information that it does not need to have.
I initially had a separate PropertyContext object where the length was 
stored. The FO element then had a reference to the PropertyContext and 
there was a PropertyContext for every FO. But since there was a 
one-to-one correspondence between the FO's and the PropertyContexts I 
decided to put the information directly in the FO's instead.

Somehow, in our current design, the information must be stored in an 
object that exists:

- when the properties are parsed.
- when the break possibilities are created.
The FO nodes fulfills both requirements.

Perhaps the dimensions should be stored in the layout manager tree but 
the LM tree is not available when the the properties are parsed and 
there is no way to get from a FO to the LM's that the FO creates.

regards,
finn

RE: [PATCH] Support for percentages and table-units

[Andreas L. Delmelle]

> -Original Message-
> From: Finn Bock [mailto:[EMAIL PROTECTED]
>
> [Simon Pepping]
>

> > However, I am not happy with your
> > solution. During the layout process, you feed the page dimensions back
> > into the FO tree, in PageLayoutManager.createPageAreas.
>
> Yes, and in BlockLayoutManager and in all the other LM that defines base
> length for percentages.
>
> > I think it
> > would be a better design if, in order to resolve the percent-based
> > properties, you would not climb the FO tree but the Area tree. That
> > avoids feeding back results from the Area tree into the FO tree.
> >

Yes, but... isn't it the main idea that we serialize the FO tree for
possible later re-use? Independently of the Area tree?

In that case, it seems more than logical to feed these back into the FOT
once, instead of re-resolving them from the AT when the document is rendered
anew?


> > [Simon ]
> > Holding those parameters in the FO tree is one solution. Extracting
> > them from the area tree layed out up to that point is another
> > solution,
>
> But there is *no* areas layed out or even created at the point where we
> need resolved length. When getNextBreakPoss is called, we only have a
> series of BreakPoss's stored in different layout managers.
>
> The Area objects are created much later when we have BreakPoss's for an
> entire page. PageLM then calls addAreas which recursively creates all
> the areas for the page.

Strong point. Personally, I see the benefits of both approaches in that one
could be used to store in the FOT _a_ base for the percentages to be set to
preliminarily resolved values, with the option of re-resolving (or merely
fine-tune) them WRT more accurate figures from the AT downstream (--which
can take into account info provided by the LM's).

>
> Perhaps the dimensions should be stored in the layout manager tree but
> the LM tree is not available when the the properties are parsed and
> there is no way to get from a FO to the LM's that the FO creates.
>

...

Cheers,

Andreas

Re: [PATCH] Support for percentages and table-units

[Simon Pepping]

On Sun, Feb 15, 2004 at 10:43:12PM +0100, Finn Bock wrote:
> [Simon Pepping]
> 
> >Finn,
> >
> >I think it
> >would be a better design if, in order to resolve the percent-based
> >properties, you would not climb the FO tree but the Area tree. That
> >avoids feeding back results from the Area tree into the FO tree.
> >
> >The XSL spec says (XSL-PR/slice3.html#section-N1208-Conceptual-Procedure):
> >
> >'The formatting object supplies parameters to its children based on the
> >traits of areas already in the area tree, possibly including areas
> >generated by the formatting object or its ancestors.'
> >
> >Holding those parameters in the FO tree is one solution. Extracting
> >them from the area tree layed out up to that point is another
> >solution, 
> 
> But there is *no* areas layed out or even created at the point where we 
> need resolved length. When getNextBreakPoss is called, we only have a 
> series of BreakPoss's stored in different layout managers.
> 
> The Area objects are created much later when we have BreakPoss's for an 
> entire page. PageLM then calls addAreas which recursively creates all 
> the areas for the page.

Indeed, I had not thought of that.
 
> >which has the advantage that it does not load the FO tree
> >with information that it does not need to have.
> 
> I initially had a separate PropertyContext object where the length was 
> stored. The FO element then had a reference to the PropertyContext and 
> there was a PropertyContext for every FO. But since there was a 
> one-to-one correspondence between the FO's and the PropertyContexts I 
> decided to put the information directly in the FO's instead.
> 
> Somehow, in our current design, the information must be stored in an 
> object that exists:
> 
> - when the properties are parsed.
> - when the break possibilities are created.
> 
> The FO nodes fulfills both requirements.
> 
> Perhaps the dimensions should be stored in the layout manager tree but 
> the LM tree is not available when the the properties are parsed and 
> there is no way to get from a FO to the LM's that the FO creates.

I see the problem now. Thanks for the explanation.

Regards,
Simon Pepping

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

Re: [PATCH] Support for percentages and table-units

[Simon Pepping]

On Mon, Feb 16, 2004 at 08:22:31PM +0100, Andreas L. Delmelle wrote:
> > -Original Message-
> > From: Finn Bock [mailto:[EMAIL PROTECTED]
> >
> > [Simon Pepping]
> >
> 
> > > However, I am not happy with your
> > > solution. During the layout process, you feed the page dimensions back
> > > into the FO tree, in PageLayoutManager.createPageAreas.
> >
> > Yes, and in BlockLayoutManager and in all the other LM that defines base
> > length for percentages.
> >
> > > I think it
> > > would be a better design if, in order to resolve the percent-based
> > > properties, you would not climb the FO tree but the Area tree. That
> > > avoids feeding back results from the Area tree into the FO tree.
> > >
> 
> Yes, but... isn't it the main idea that we serialize the FO tree for
> possible later re-use? Independently of the Area tree?
> 
> In that case, it seems more than logical to feed these back into the FOT
> once, instead of re-resolving them from the AT when the document is rendered
> anew?

If in the re-use the layout would not change, the area tree could be
reused. OTOH, if the layout would change, e.g. because another
renderer would use a font with a different font metric, the layout
information in the FO tree cannot be reused. This is another argument
to separate FO tree and layout information.

Regards,
Simon Pepping

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

Re: [PATCH] Support for percentages and table-units

[Simon Pepping]

On Sun, Feb 15, 2004 at 10:43:12PM +0100, Finn Bock wrote:
> [Simon Pepping]
> 
> I initially had a separate PropertyContext object where the length was 
> stored. The FO element then had a reference to the PropertyContext and 
> there was a PropertyContext for every FO. But since there was a 
> one-to-one correspondence between the FO's and the PropertyContexts I 
> decided to put the information directly in the FO's instead.
> 
> Somehow, in our current design, the information must be stored in an 
> object that exists:
> 
> - when the properties are parsed.
> - when the break possibilities are created.
> 
> The FO nodes fulfills both requirements.
> 
> Perhaps the dimensions should be stored in the layout manager tree but 
> the LM tree is not available when the the properties are parsed and 
> there is no way to get from a FO to the LM's that the FO creates.

In the current design the layout manager tree seems the best
option. One could change the signature of getValue to
getValue(LayoutManager layoutmgr). For absolute properties the
layoutmgr could be null, but for relative properties it would be
impossible to get the value without reference to the layoutmanager.

Regards,
Simon Pepping

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

RE: [PATCH] Support for percentages and table-units

[Andreas L. Delmelle]

> -Original Message-
> From: Simon Pepping [mailto:[EMAIL PROTECTED]
>

> If in the re-use the layout would not change, the area tree could be
> reused. OTOH, if the layout would change, e.g. because another
> renderer would use a font with a different font metric, the layout
> information in the FO tree cannot be reused. This is another argument
> to separate FO tree and layout information.
>

Different font-metrics... indeed.

Another one I forgot: page-height/page-width="indefinite"
(to specify something as a percentage of an indefinite page-width... there's
a challenge)

Cheers,

Andreas

Re: [PATCH] Support for percentages and table-units

[J.Pietschmann]

Finn Bock wrote:
Somehow, in our current design, the information must be stored in an 
object that exists:
IIRC that's what the layout context was meant for.

J.Pietschmann

Re: [PATCH] Support for percentages and table-units

[Finn Bock]

Somehow, in our current design, the information must be stored in an 
object that exists:
[J.Pietschmann]

IIRC that's what the layout context was meant for.
Perhaps, but I doubt it. If they was change to always get a reference to 
the parent layout context when they are created, and if they had a 
reference to the FObj, and if they was made available to the property 
subsystem, then they could properly be used for it.

I still think it is easier to use either the FOs or the LMs .

regards,
finn

Re: [PATCH] Support for percentages and table-units

[Finn Bock]

[Simon Pepping]

If in the re-use the layout would not change, the area tree could be
reused. OTOH, if the layout would change, e.g. because another
renderer would use a font with a different font metric, the layout
information in the FO tree cannot be reused.
The layout dimension that is stored in the FO tree is constantly updated 
during discovery of BreakPoss'es and is never reused, not even when a 
block is split over a break where new values are assigned.

The solution I propose makes it impossible to run two different 
renderers concurrently, but it does not in any way prevent the FO tree 
from being reused with another renderer after the first rendering is 
finished.

This is another argument
to separate FO tree and layout information.
No, not really IMO.

regards,
finn

Re: [PATCH] Support for percentages and table-units

[J.Pietschmann]

Finn Bock wrote:
> Perhaps, but I doubt it. If they was change to always get a reference to
> the parent layout context when they are created, and if they had a
> reference to the FObj, and if they was made available to the property
> subsystem, then they could properly be used for it.
The layout context has the actual IPD MinOptMax. There is no
inherent reason it should have a link to a parent context or the
property subsystem, it's only necessary to have a method to
resolve a property expression given a set of MinOptMax for
the various traits which can be used as references for
percentages. Like
  textIndent=propertyManager.get(TEXT_INDENT).resolve(layoutContext);
> I still think it is easier to use either the FOs or the LMs .

Maybe.

J.Pietschmann

Re: [PATCH] Support for percentages and table-units

[Finn Bock]

 > Perhaps, but I doubt it. If they was change to always get a reference to
 > the parent layout context when they are created, and if they had a
 > reference to the FObj, and if they was made available to the property
 > subsystem, then they could properly be used for it.
[J.Pietschmann]

The layout context has the actual IPD MinOptMax. There is no
inherent reason it should have a link to a parent context or the
property subsystem, it's only necessary to have a method to
resolve a property expression given a set of MinOptMax for
the various traits which can be used as references for
percentages. Like
  textIndent=propertyManager.get(TEXT_INDENT).resolve(layoutContext);
Right, but it doesn't have all the base lengths. For some base lengths 
it is one of the parent layout contexts that has the trait, like ipd of 
the containing reference area. How could we get hold of that trait if 
the LayoutContexts isn't linked together?

Whatever object that is passed to the resolve() method must also AFAICT 
also have a reference to the FO so that the resolve() can find the right 
LayoutContext in the LayoutContext tree to use as base.

Perhaps I'm missing something fundamental in your suggestion, but I just 
can see how there is enough information in a single LayoutContext to 
resolve relative lengths that is inherited from a parent fo:element.

 > I still think it is easier to use either the FOs or the LMs .

Maybe.
Well, the approach using FOs are here already. It can't get easier than 
that.

regards,
finn

Re: [PATCH] Support for percentages and table-units

[Glen Mazza]

--- Finn Bock <[EMAIL PROTECTED]> wrote:
>
> The layout dimension that is stored in the FO tree
> is constantly updated 
> during discovery of BreakPoss'es and is never
> reused, not even when a 
> block is split over a break where new values are
> assigned.
> 

I don't know enough to comment too much on which
implementation would be better here, but the spec does
not appear to have much problem (see [1], also Finn's
earlier reference to the spec's conceptual procedure
[2]) with back-and-forth processes, updates, etc.
between the FO Tree and Area Tree.  Indeed, it seems
to indicate that this kind of interaction does need to
occur for the process to work correctly.

Now if would be faster or more efficient to do so,
that may be another issue.  But Finn's ideas seem to
be sufficiently in agreement with the spec.

[1]
http://marc.theaimsgroup.com/?l=fop-dev&m=107503563018878&w=2
[2]
http://marc.theaimsgroup.com/?l=fop-dev&m=107688130007968&w=2


> The solution I propose makes it impossible to run
> two different 
> renderers concurrently, but it does not in any way
> prevent the FO tree 
> from being reused with another renderer after the
> first rendering is 
> finished.
> 
> > This is another argument
> > to separate FO tree and layout information.
> 
> No, not really IMO.
> 

I think I agree with Finn on this issue.  Reuse of the
FOT/AT, i.e., re-rendering from the same input FO, but
with a different output type, would probably be only a
few percent of all usages of FOP.  It is trivial
enough that it should not weigh into the architectural
decision, especially if doing so would (1) create a
messier, hard-to-perfect design, or (2) slow things
down for bulk of users not requiring this
functionality.  

Stated another way, if those wanting both PCL and PDF
for the same input FO would have to have the FOT & AT
regenerated from scratch, we can live with that.  For
one thing, that's probably the current situation with
the commercial renderers anyway.  Also, a requirement
for the FOT and AT to stay-in-memory and be
reenterable may end up resulting in a rather buggy
implementation.

Glen

Re: [PATCH] Support for percentages and table-units

[Simon Pepping]

On Tue, Feb 17, 2004 at 09:31:52PM +0100, Finn Bock wrote:
> 
> [J.Pietschmann]
> 
> >The layout context has the actual IPD MinOptMax. There is no
> >inherent reason it should have a link to a parent context or the
> >property subsystem, it's only necessary to have a method to
> >resolve a property expression given a set of MinOptMax for
> >the various traits which can be used as references for
> >percentages. Like
> >  textIndent=propertyManager.get(TEXT_INDENT).resolve(layoutContext);
> 
> Right, but it doesn't have all the base lengths. For some base lengths 
> it is one of the parent layout contexts that has the trait, like ipd of 
> the containing reference area. How could we get hold of that trait if 
> the LayoutContexts isn't linked together?
> 
> Whatever object that is passed to the resolve() method must also AFAICT 
> also have a reference to the FO so that the resolve() can find the right 
> LayoutContext in the LayoutContext tree to use as base.
> 
> Perhaps I'm missing something fundamental in your suggestion, but I just 
> can see how there is enough information in a single LayoutContext to 
> resolve relative lengths that is inherited from a parent fo:element.

In the LayoutContext design, one does not climb a tree to find the
relevant information; instead, the information is propagated downward
for ready reference. Each getNextBreakPoss call gets a LayoutContext
from its caller, and constructs one for its own calls to
getNextBreakPoss. It should make sure that the latter LayoutContext
contains all the relevant information, such as the width of the
containing block and of the containing reference area. Either it
copies it from the LayoutContext it received from its caller, or it
inserts new values, as appropriate. In principle it should contain the
dimensions that correspond to the percent based length types listed in
LengthBase.

Regards,
Simon Pepping

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

Re: [PATCH] Support for percentages and table-units

[Simon Pepping]

On Tue, Feb 17, 2004 at 04:52:10PM -0800, Glen Mazza wrote:
> --- Finn Bock <[EMAIL PROTECTED]> wrote:
> >
> > The layout dimension that is stored in the FO tree
> > is constantly updated 
> > during discovery of BreakPoss'es and is never
> > reused, not even when a 
> > block is split over a break where new values are
> > assigned.
> > 
> 
> I don't know enough to comment too much on which
> implementation would be better here, but the spec does
> not appear to have much problem (see [1], also Finn's
> earlier reference to the spec's conceptual procedure
> [2]) with back-and-forth processes, updates, etc.
> between the FO Tree and Area Tree.  Indeed, it seems
> to indicate that this kind of interaction does need to
> occur for the process to work correctly.

In my view FOP consists of a number of subsystems that are ordered
from upstream to downstream. The FO tree is the most upstream system,
the area tree (or objects that are constructed by a renderer) is the
most downstream system. Information should flow downstream, not
upstream.

Regards,
Simon Pepping

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

RE: [PATCH] Support for percentages and table-units

[Andreas L. Delmelle]

> -Original Message-
> From: Simon Pepping [mailto:[EMAIL PROTECTED]
>
> In my view FOP consists of a number of subsystems that are ordered
> from upstream to downstream. The FO tree is the most upstream system,
> the area tree (or objects that are constructed by a renderer) is the
> most downstream system.

Indeed, but...

> Information should flow downstream, not
> upstream.

(Hmm. Isn't there an Aussie in this house who disagrees? Callbacks, Peter?
;) Nah, bad example...)

I gave the example of resolving a percentage p of an indefinite page-height
or -width...
Say you have to do this for a page that turns out to be .. quite long
(--say, an ancient scroll or something.. ).
For this you'd need the total width of every object laid out on the page
(nothing rendered yet), then a very simple: reswidth = totwidth * (1 +
p/100 ) / ( 1 - p/100 )

Don't know about you, but even *with* the possibility of the next renderer
not using the same configuration as the first, I wouldn't want to just throw
away a possibility of re-using the layout info and only having to reuse the
calculated values (--or, in the worst case, maybe results from a calculation
based upon higher-level relationships between the different configurations
used)

Basic point: the preferred direction of the information flow depends (almost
entirely) upon the relationship between the up- and downstream events that
is being
You are IMO very correct by stating that 'if the Layout info can be reused,
so can the AT and the renderer', however, if I interpret correctly, the
latter two are designed to dispose of their created objects ASAP.
The downstream objects hold a reference to the upstream ones, not the other
way around --unless you have a way out of there, as long as a certain
page-sequence is referenced, the entire Layout/AT/Renderer structure would
exist in memory, which can get .. quite large even for moderately sized
documents. Would it really be worth a shot to change the design there, and
flip a switch? Throw the FOTree away and just fill up the AT and re-use
that?


Cheers,

Andreas

RE: [PATCH] Support for percentages and table-units

[Andreas L. Delmelle]

> is being interrogated/perceived/discussed...


Sorry, it's late here...

> You are IMO very correct by stating that 'if the Layout info can
> be reused,
> so can the AT and the renderer', however, if I interpret correctly, the
> latter two are designed to dispose of their created objects ASAP.
> The downstream objects hold a reference to the upstream ones, not
> the other
> way around --unless you have a way out of there, as long as a certain
> page-sequence is referenced, the entire Layout/AT/Renderer structure would
> exist in memory, which can get .. quite large even for moderately sized
> documents. Would it really be worth a shot to change the design there, and
> flip a switch? Throw the FOTree away and just fill up the AT and re-use
> that?
>
>
> Cheers,
>
> Andreas
>
>
>
>

Re: [PATCH] Support for percentages and table-units

[Glen Mazza]

--- Simon Pepping <[EMAIL PROTECTED]> wrote:
> 
> In my view FOP consists of a number of subsystems
> that are ordered
> from upstream to downstream. The FO tree is the most
> upstream system,
> the area tree (or objects that are constructed by a
> renderer) is the
> most downstream system. Information should flow
> downstream, not
> upstream.
> 
> Regards,
> Simon Pepping
> 

In general, yes, but not as 100%.  We had this debate
for months, with Victor holding fast to your view on
the issue.  We've done more spec research since then
(I encourage you to read the parts of the spec I
indicated in my posting) which support the view of
Alt-Design (and probably still HEAD), that FOT & AT
interact with each other and can't be separated, and
for performance reasons, shouldn't be either.

Glen

Re: [PATCH] Support for percentages and table-units

[Finn Bock]

[J.Pietschmann]
The layout context has the actual IPD MinOptMax. There is no
inherent reason it should have a link to a parent context or the
property subsystem, it's only necessary to have a method to
resolve a property expression given a set of MinOptMax for
the various traits which can be used as references for
percentages. Like
textIndent=propertyManager.get(TEXT_INDENT).resolve(layoutContext);
Right, but it doesn't have all the base lengths. For some base lengths 
it is one of the parent layout contexts that has the trait, like ipd of 
the containing reference area. How could we get hold of that trait if 
the LayoutContexts isn't linked together?

Whatever object that is passed to the resolve() method must also AFAICT 
also have a reference to the FO so that the resolve() can find the right 
LayoutContext in the LayoutContext tree to use as base.

Perhaps I'm missing something fundamental in your suggestion, but I just 
can see how there is enough information in a single LayoutContext to 
resolve relative lengths that is inherited from a parent fo:element.
[Simon Pepping]

In the LayoutContext design, one does not climb a tree to find the
relevant information; instead, the information is propagated downward
for ready reference. Each getNextBreakPoss call gets a LayoutContext
from its caller, and constructs one for its own calls to
getNextBreakPoss. It should make sure that the latter LayoutContext
contains all the relevant information, such as the width of the
containing block and of the containing reference area. Either it
copies it from the LayoutContext it received from its caller, or it
inserts new values, as appropriate. In principle it should contain the
dimensions that correspond to the percent based length types listed in
LengthBase.
If an expression reference another expression in a parent fo, the parent 
fo expression must be evaluated against the LayoutContext that was in 
effect for the parent fo and *not* against the child fo LayoutContext.


   
   

It must be the LayoutContex for 'a' that is used when we evaluate the 
10% even when we call:
propertyList.get(PR_BORDER_START_WIDTH).getValue(lc)
with the layout context for 'b'.

I don't really care how that is done, but I would link the 
LayoutContexts to their parent. Or rather, I would use the LM as the 
objects for storing the actual dimension since they are already linked 
together with their parent.

But for now I think we should just use the FO tree and later change the 
signature of getValue() to take some kind of context parameter when a 
real need arise.

regards,
finn

Re: [PATCH] Support for percentages and table-units

[J.Pietschmann]

Finn Bock wrote:
If an expression reference another expression in a parent fo, the parent 
fo expression must be evaluated against the LayoutContext that was in 
effect for the parent fo and *not* against the child fo LayoutContext.


   
   

It must be the LayoutContex for 'a' that is used when we evaluate the 
10% even when we call:
propertyList.get(PR_BORDER_START_WIDTH).getValue(lc)
with the layout context for 'b'.
Well, I used to believe the 10% has been evaluated already, and the
inherited property can grab the absolute value immediately.
J.Pietschmann

Re: [PATCH] Support for percentages and table-units

[Finn Bock]

[me]

If an expression reference another expression in a parent fo, the 
parent fo expression must be evaluated against the LayoutContext that 
was in effect for the parent fo and *not* against the child fo 
LayoutContext.


   
   

It must be the LayoutContex for 'a' that is used when we evaluate the 
10% even when we call:
propertyList.get(PR_BORDER_START_WIDTH).getValue(lc)
with the layout context for 'b'.
[J.Pietschmann]

Well, I used to believe the 10% has been evaluated already, and the
inherited property can grab the absolute value immediately.
If it is evaluated already where would the evaluated value be stored? In 
the propertyList (aka the FO tree)? And then the value should be 
reverted to the expression when the base value changes due to breaks.

Storing the resolved value would IMO remove all the benefits from 
passing in a context parameter to getValue().

Perhaps it can be done that way too, but it is very different from my 
proposal.

regards,
finn

Re: [PATCH] Support for percentages and table-units

[J.Pietschmann]

Finn Bock wrote:
If it is evaluated already where would the evaluated value be stored?
The layout context for the child LM could be an appropriate place.

And then the value should be 
reverted to the expression when the base value changes due to breaks.
No problem, this is known at the place where a new Layout context is
created for getting BP from the child LM.
J.Pietschmann

Re: [PATCH] Support for percentages and table-units

[Finn Bock]

If it is evaluated already where would the evaluated value be stored?
[J.Pietschmann]

The layout context for the child LM could be an appropriate place.
The resolved property values of the parents should be stored in the 
layout context? I must be missing something here!

And then the value should be reverted to the expression when the base 
value changes due to breaks.
No problem, this is known at the place where a new Layout context is
created for getting BP from the child LM.
I don't understand how you propose to solve any of this, but I hope it 
would be Ok to commit the straight forward solution I propose. Then you 
can change it at a later time to pass in the LayoutContext as a 
parameter to Length.getValue().

regards,
finn

Re: [PATCH] Support for percentages and table-units

[Simon Pepping]

On Thu, Feb 19, 2004 at 08:52:41AM +0100, Finn Bock wrote:
> If an expression reference another expression in a parent fo, the parent 
> fo expression must be evaluated against the LayoutContext that was in 
> effect for the parent fo and *not* against the child fo LayoutContext.
> 
> 
>
> 
>
> 
> 
> It must be the LayoutContex for 'a' that is used when we evaluate the 
> 10% even when we call:
> propertyList.get(PR_BORDER_START_WIDTH).getValue(lc)
> with the layout context for 'b'.

The present code contains a partial implementation of percent based
properties, e.g. in fo:leader, leader-length. This implementation
indeed uses the context layout for the base dimensions with respect to
which a relative property is calculated. The ipd of the containing
block is retrieved from it and is propagated to the method that
calculates the actual leader length:

LeafNodeLayoutManager.getNextBreakPoss:
  ipd = getAllocationIPD(context.getRefIPD());
AddLMVisitor.getLeaderAllocIPD:
  node.getLength(Constants.PR_LEADER_LENGTH | Constants.CP_MAXIMUM, ipd);
Leader.getLength:
  length = (int)(((PercentLength) maxlength).value() * dim);

where dim = ipd = context.getRefIPD().

I realized that this is wrong for exactly the above reasons. If the
percent expression is specified on an ancestral FO, the current
implementation fails to see this and always calculates it on the basis
of the ipd of the current containing block. See this example:


  


  
  This is a block with a leader and a block with left
  and right margins of 60pt. The latter block contains a leader and
  this text. The leader length is specified as 30% on the topmost
  block.

  


The 30% must be calculated w.r.t. the page width for both leaders, and
both leaders must be equally wide. This is not the current result.

When I tried to remedy this, I got confused by the sets of symbols on
PercentBase and on LengthBase. Why are there 2 sets of symbols?  They
are mapped onto each other in LengthBase.getBaseLength(), but not all
symbols are mapped, e.g. LengthBase.CONTAINING_BOX, which is used by
leader-length, has no corresponding action. Some further integration
of old and new code must be done here.

Question: What to do if I insert a fo:wrapper between fo:flow and
fo:block? That makes it the parent of fo:block, but it has no layout
manager corresponding to it. Override getLayoutDimension on it?

> But for now I think we should just use the FO tree and later change the 
> signature of getValue() to take some kind of context parameter when a 
> real need arise.

I agree.  I am now convinced that your solution is simple, practical
and robust. You demonstrated that it deals properly with FOs that
generate more than one area. You also demonstrated that the
LayoutContext idea is insufficient. Holding layout information in the
Layout Managers is more pure, but indeed not absolutely necessary.

Regards,
Simon Pepping

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

Re: [PATCH] Support for percentages and table-units

[Simon Pepping]

On Wed, Feb 18, 2004 at 04:00:26PM -0800, Glen Mazza wrote:
> In general, yes, but not as 100%.  We had this debate
> for months, with Victor holding fast to your view on
> the issue.  We've done more spec research since then
> (I encourage you to read the parts of the spec I
> indicated in my posting) which support the view of
> Alt-Design (and probably still HEAD), that FOT & AT
> interact with each other and can't be separated, and
> for performance reasons, shouldn't be either.

I agree with you that the spec demands a close interaction of FOT &
AT. I interpret that mainly in terms of the process, which switches
between building the FO tree and building the area tree. It does not
necessarily mean that information should flow in both directions.

Regards,
Simon Pepping

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

Re: [PATCH] Support for percentages and table-units

[Peter B. West]

Re-sending due to mailer problems.

Peter

 Original Message 
Subject: Re: [PATCH] Support for percentages and table-units
Date: Thu, 19 Feb 2004 12:48:59 +1000


Andreas L. Delmelle wrote:
-Original Message-
From: Simon Pepping [mailto:[EMAIL PROTECTED]
In my view FOP consists of a number of subsystems that are ordered
from upstream to downstream. The FO tree is the most upstream system,
the area tree (or objects that are constructed by a renderer) is the
most downstream system.


Indeed, but...


Information should flow downstream, not
upstream.


(Hmm. Isn't there an Aussie in this house who disagrees? Callbacks, Peter?
;) Nah, bad example...)
Thanks Andreas.  Yes, I disagree, but then, so does the spec.  What
information *should* do is not terribly relevant.  We need to work out
and express what information *must* do to get this thing working.
...
Basic point: the preferred direction of the information flow depends (almost
entirely) upon the relationship between the up- and downstream events that
is being
Yep.  (Even without the end of the sentence.)

You are IMO very correct by stating that 'if the Layout info can be reused,
so can the AT and the renderer', however, if I interpret correctly, the
latter two are designed to dispose of their created objects ASAP.
The downstream objects hold a reference to the upstream ones, not the other
way around --unless you have a way out of there, as long as a certain
page-sequence is referenced, the entire Layout/AT/Renderer structure would
exist in memory, which can get .. quite large even for moderately sized
documents. Would it really be worth a shot to change the design there, and
flip a switch? Throw the FOTree away and just fill up the AT and re-use
that?
Or process the minimal relevant parts of the FO and Area trees in
parallel.  That is what I am working towards.  I believe that
page-at-a-time layout with just in time processing of the FOs is
possible.  Given that, both FOs and Areas can be kept alive while
required.  (I haven't given any thought to rendering.)  Note that
forward references are always going to be a problem, but that a
combination of weak/soft/phantom references and serialization should
keep memory requirements manageable.
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>

Re: [PATCH] Support for percentages and table-units

[Peter B. West]

Re-resending...

 Original Message 
Subject: Re: [PATCH] Support for percentages and table-units
Date: Fri, 20 Feb 2004 19:07:06 +1000
Finn Bock wrote:
[me]

If an expression reference another expression in a parent fo, the 
parent fo expression must be evaluated against the LayoutContext that 
was in effect for the parent fo and *not* against the child fo 
LayoutContext.


   
   

It must be the LayoutContex for 'a' that is used when we evaluate the 
10% even when we call:
propertyList.get(PR_BORDER_START_WIDTH).getValue(lc)
with the layout context for 'b'.


[J.Pietschmann]

Well, I used to believe the 10% has been evaluated already, and the
inherited property can grab the absolute value immediately.


If it is evaluated already where would the evaluated value be stored? In 
the propertyList (aka the FO tree)? And then the value should be 
reverted to the expression when the base value changes due to breaks.

Storing the resolved value would IMO remove all the benefits from 
passing in a context parameter to getValue().

Perhaps it can be done that way too, but it is very different from my 
proposal.
In principle, no area-based percentage can benefit from a one-off
resolution until all of its children have been fully laid out.  The
children inherit the computed value, but that value may change during
the layout life of the parent in question.
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>

Re: [PATCH] Support for percentages and table-units

[Peter B. West]

Re-resending...

 Original Message 
Subject: Re: [PATCH] Support for percentages and table-units
Date: Fri, 20 Feb 2004 21:20:52 +1000
Finn,

When I apply your most recent patch (10366) against a cvs updated HEAD
tree and attempt to compile, I get the following:
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/LinearCombinationLength.java:60: 

org.apache.fop.fo.properties.LinearCombinationLength is not abstract and
does not override abstract method getValue() in
org.apache.fop.datatypes.Length
[javac] public class LinearCombinationLength extends LengthProperty {
[javac]^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/LinearCombinationLength.java:96: 

cannot resolve symbol
[javac] symbol  : method setComputedValue (int)
[javac] location: class
org.apache.fop.fo.properties.LinearCombinationLength
[javac] setComputedValue(result);
[javac] ^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:64: 

org.apache.fop.fo.properties.MixedLength is not abstract and does not
override abstract method getValue() in org.apache.fop.datatypes.Length
[javac] public class MixedLength extends LengthProperty {
[javac]^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:89: 

cannot resolve symbol
[javac] symbol  : method isComputed ()
[javac] location: class org.apache.fop.fo.properties.LengthProperty
[javac] if (!l.isComputed()) {
[javac]   ^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:93: 

cannot resolve symbol
[javac] symbol  : method setComputedValue (int,boolean)
[javac] location: class org.apache.fop.fo.properties.MixedLength
[javac] setComputedValue(computedValue, bAllComputed);
[javac] ^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:109: 

cannot resolve symbol
[javac] symbol  : method resolveTableUnit (double)
[javac] location: class org.apache.fop.fo.properties.LengthProperty
[javac] ((LengthProperty)
e.nextElement()).resolveTableUnit(dTableUnit);
[javac] ^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:136: 

cannot resolve symbol
[javac] symbol  : method asNumeric ()
[javac] location: class org.apache.fop.fo.properties.LengthProperty
[javac] numeric = l.asNumeric();
[javac]^
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/MixedLength.java:139: 

cannot resolve symbol
[javac] symbol  : method asNumeric ()
[javac] location: class org.apache.fop.fo.properties.LengthProperty
[javac] NumericProperty sum =
numeric.add(l.asNumeric());
[javac]^
[javac] 8 errors
Is there a patch I have missed.  I tried applying the earlier patch
first, but then the second patch is reported as already/applied/reversed.
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>

Re: [PATCH] Support for percentages and table-units

[Finn Bock]

If an expression reference another expression in a parent fo, the parent 
fo expression must be evaluated against the LayoutContext that was in 
effect for the parent fo and *not* against the child fo LayoutContext.


  
  

It must be the LayoutContex for 'a' that is used when we evaluate the 
10% even when we call:
   propertyList.get(PR_BORDER_START_WIDTH).getValue(lc)
with the layout context for 'b'.
[Simon Pepping]

[leader example snipped}

The 30% must be calculated w.r.t. the page width for both leaders, and
both leaders must be equally wide. This is not the current result.
When I tried to remedy this, I got confused by the sets of symbols on
PercentBase and on LengthBase. Why are there 2 sets of symbols?
The idea was that PercentBase.XXX names the stored values and LengthBase 
names the algorithm for looking up a base value. Most of the time these 
maps one-to-one to each other but for some I imaged that they would be 
different. margin-top f.ex. should really use an algorithm like 
BLOCKIPD_OR_PAGEHEIGHT which would look for either PercentBase.BLOCK_IPD 
or PercentBase.PAGE_HEIGHT depending on the fo:element.

Clearly all of this isn't complete implemented in my patch yet and 
perhaps it can be done in a simpler way. Better names for PercentBase 
and LengthBase could help.

They
are mapped onto each other in LengthBase.getBaseLength(), but not all
symbols are mapped, e.g. LengthBase.CONTAINING_BOX, which is used by
leader-length, has no corresponding action. Some further integration
of old and new code must be done here.
Correct.

Question: What to do if I insert a fo:wrapper between fo:flow and
fo:block? That makes it the parent of fo:block, but it has no layout
manager corresponding to it. Override getLayoutDimension on it?
I don't think so, but perhaps I don't just yet understand the situation 
that you are describing. A percentage on the wrapper should be resolved 
against the parent of the wrapper, right?

regards,
finn

Re: [PATCH] Support for percentages and table-units

[Finn Bock]

[Peter B. West]

Finn,

When I apply your most recent patch (10366) against a cvs updated HEAD
tree and attempt to compile, I get the following:
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/LinearCombinationLength.java:60: 
After applying the patch (10366), the following files should be removed:

src/java/org/apache/fop/fo/properties/LinearCombinationLength.java
src/java/org/apache/fop/fo/properties/MixedLength.java
Does anyone know how to include a file-remove in a patch?

regards,
finn

Re: [PATCH] Support for percentages and table-units

[Simon Pepping]

On Sat, Feb 21, 2004 at 12:24:24PM +0100, Finn Bock wrote:
> >Question: What to do if I insert a fo:wrapper between fo:flow and
> >fo:block? That makes it the parent of fo:block, but it has no layout
> >manager corresponding to it. Override getLayoutDimension on it?
> 
> I don't think so, but perhaps I don't just yet understand the situation 
> that you are describing. A percentage on the wrapper should be resolved 
> against the parent of the wrapper, right?

The wrapper is the parent of the block, so the block tries to resolve
the layout dimension on the wrapper. I could have answered the
question myself though: No change is required. If the layout dimension
is not found on a certain FO, it is looked for at the parent. 

Regards,
Simon Pepping

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

RE: [PATCH] Support for percentages and table-units

[Andreas L. Delmelle]

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

>
> Thanks Andreas.  Yes, I disagree, but then, so does the spec.  What
> information *should* do is not terribly relevant.  We need to work out
> and express what information *must* do to get this thing working.
>

Voila! Without worrying too much about "textbook 'should'-stuff"... It is
after all *XSL*-FO, so I guess the basic compliance rule is also for FO
processors: 'the order of the processing events doesn't matter at all, as
long as the produced output is correct.'

> > [Me:]
> > ... Would it really be worth a shot to change the design
> > there, and flip a switch? Throw the FOTree away and just fill up
> > the AT and re-use that?
>
> Or process the minimal relevant parts of the FO and Area trees in
> parallel.  That is what I am working towards.  I believe that
> page-at-a-time layout with just in time processing of the FOs is
> possible.  Given that, both FOs and Areas can be kept alive while
> required.  (I haven't given any thought to rendering.)

Indeed. When I began thinking about 'borderline-cases', it became clearer
that situations where you need to wait for more than one page to complete
the layout are rather exceptional anyway, so it's most likely the better
option to treat them as what they are: 'an exception to the general
processing flow' (--IOW, not *all* theoretical possibilities implied by the
definitions in the spec should be covered by the *basic* processing
framework).

> Note that forward references are always going to be a problem, but that a
> combination of weak/soft/phantom references and serialization should
> keep memory requirements manageable.
>

That's where your producer-consumer buffers step in, right?

So.. by 'minimal relevant parts' you actually mean something as 'reduced
skeletons of subtrees' that in themselves provide a way to pull the events
generated by their descendants from the buffer, without themselves actually
holding a reference to the descendants, so while the ancestor is being kept
alive, the descendants can be happily collected by our friend GC if no
longer used by another process, while the ancestor remains at our disposal
to re-pull the same events from the buffer if/when they are needed.

Is this close?

Cheers,

Andreas

Re: [PATCH] Support for percentages and table-units

[Peter B. West]

Andreas L. Delmelle wrote:
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]


Thanks Andreas.  Yes, I disagree, but then, so does the spec.  What
information *should* do is not terribly relevant.  We need to work out
and express what information *must* do to get this thing working.


Voila! Without worrying too much about "textbook 'should'-stuff"... It is
after all *XSL*-FO, so I guess the basic compliance rule is also for FO
processors: 'the order of the processing events doesn't matter at all, as
long as the produced output is correct.'

[Me:]
... Would it really be worth a shot to change the design
there, and flip a switch? Throw the FOTree away and just fill up
the AT and re-use that?
Or process the minimal relevant parts of the FO and Area trees in
parallel.  That is what I am working towards.  I believe that
page-at-a-time layout with just in time processing of the FOs is
possible.  Given that, both FOs and Areas can be kept alive while
required.  (I haven't given any thought to rendering.)


Indeed. When I began thinking about 'borderline-cases', it became clearer
that situations where you need to wait for more than one page to complete
the layout are rather exceptional anyway, so it's most likely the better
option to treat them as what they are: 'an exception to the general
processing flow' (--IOW, not *all* theoretical possibilities implied by the
definitions in the spec should be covered by the *basic* processing
framework).
The borderline cases may be very much in the minority (and must be, 
judging by the degree of usage that FOP gets now) but they must be taken 
into account in the design of the solution.  If we go for the 
low-hanging fruit and then discover that the ladder is too short we end 
up back in the workshop.


Note that forward references are always going to be a problem, but that a
combination of weak/soft/phantom references and serialization should
keep memory requirements manageable.


That's where your producer-consumer buffers step in, right?

So.. by 'minimal relevant parts' you actually mean something as 'reduced
skeletons of subtrees' that in themselves provide a way to pull the events
generated by their descendants from the buffer, without themselves actually
holding a reference to the descendants, so while the ancestor is being kept
alive, the descendants can be happily collected by our friend GC if no
longer used by another process, while the ancestor remains at our disposal
to re-pull the same events from the buffer if/when they are needed.
Is this close?

I wasn't thinking of the buffers.  The re-usability of the buffers is 
only relevant to static-content and markers, so I don't see that as a 
major issue, and would expect to keep the static-content buffers for a 
page in memory for the life of the page-sequence.  Markers are a bit 
more problematical, and may well benefit from some "transparent" 
serialization.

I was thinking more of the "historical" parts of the FO and Area trees. 
 At one stage I considered linking all nodes in the FO tree with 
reference objects, but I was concerned about the extra layer of 
reference objects and their impact on memory and performance.  However, 
when we get parallel FO tree, Area tree and rendering working it may pay 
dividends.

I find the language of the java.lang.ref package confusing, but I think 
that phantom references open the possibility of performing serialization 
 "on demand", when the object is queued for GC.

Peter
--
Peter B. West 

Re: [PATCH] Support for percentages and table-units

[Peter B. West]

Finn Bock wrote:
[Peter B. West]

Finn,

When I apply your most recent patch (10366) against a cvs updated HEAD
tree and attempt to compile, I get the following:
[javac]
/usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/LinearCombinationLength.java:60: 


After applying the patch (10366), the following files should be removed:

src/java/org/apache/fop/fo/properties/LinearCombinationLength.java
src/java/org/apache/fop/fo/properties/MixedLength.java
Does anyone know how to include a file-remove in a patch?
From 'man patch' on linux:

You can create a file by sending out a diff that compares /dev/null  or
an empty file dated the Epoch (1970-01-01 00:00:00 UTC) to the file you
want to create.  This only works if the file you want to create doesn't
exist  already  in  the target directory.  Conversely, you can remove a
file by sending out a context diff that compares the file to be deleted
with  an  empty  file dated the Epoch.  The file will be removed unless
patch is conforming to POSIX and the -E or --remove-empty-files  option
is  not  given.  An easy way to generate patches that create and remove
files is to use GNU diff's -N or --new-file option.
From 'man diff' on linux:

-N
--new-file
 In directory comparison, if a file is found in only  one  direc-
 tory, treat it as present but empty in the other directory.
Peter
--
Peter B. West 

RE: [PATCH] Support for percentages and table-units

[Andreas L. Delmelle]

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

> The borderline cases may be very much in the minority (and must be,
> judging by the degree of usage that FOP gets now) but they must be taken
> into account in the design of the solution.  If we go for the
> low-hanging fruit and then discover that the ladder is too short we end
> up back in the workshop.
>

I understand, but what I'm referring to is (taking your analogy a bit
further):
You want an 'extensible' ladder which you can keep short for the low-hanging
fruit, and extend to reach the higher ones. If you get to a tiny tree with a
huge ladder, you're going to be cursing yourself anyway as your big ladder
will make the job more difficult, IYKWIM (--you might not even need that
ladder, but still you carried it all the way down there...).

The point that would concern me is an API that forces the most trivial and
common cases into a processing-model that is actually meant to accommodate
rather complicated structures. So you'd end up having an overhead in 95% of
the cases, overhead which strictly speaking is meant to occur in only 5% of
the possible situations.
If it results in (virtually) no overhead at all, this point of course
dissolves totally... the ladder is then extensible in just the right way.

>
> I wasn't thinking of the buffers.  The re-usability of the buffers is
> only relevant to static-content and markers, so I don't see that as a
> major issue, and would expect to keep the static-content buffers for a
> page in memory for the life of the page-sequence.  Markers are a bit
> more problematical, and may well benefit from some "transparent"
> serialization.
>

Sorry, I'm still a bit misguided, it seems. This part, I already got, but...

> I was thinking more of the "historical" parts of the FO and Area trees.

... putting quotes around there is to beg the question, so, would that be
the parts that have already been processed in some way?

>   At one stage I considered linking all nodes in the FO tree with
> reference objects, but I was concerned about the extra layer of
> reference objects and their impact on memory and performance.  However,
> when we get parallel FO tree, Area tree and rendering working it may pay
> dividends.
>
> I find the language of the java.lang.ref package confusing, but I think
> that phantom references open the possibility of performing serialization
>   "on demand", when the object is queued for GC.
>

Can you elaborate a bit on this? AFAICT, the actual referent of a phantom
reference is itself unreachable through the reference object (the ref's
get() method always returns null), so you could indeed test via isEnqueued()
whether or not the referent of a phantom reference is queued for GC, and
then...? A soft reference at least would allow to get() the object and do
something with it or make it do something with itself before actually
clearing the ref.


Cheers,

Andreas

Re: [PATCH] Support for percentages and table-units

[Peter B. West]

Andreas L. Delmelle wrote:
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]


The borderline cases may be very much in the minority (and must be,
judging by the degree of usage that FOP gets now) but they must be taken
into account in the design of the solution.  If we go for the
low-hanging fruit and then discover that the ladder is too short we end
up back in the workshop.


I understand, but what I'm referring to is (taking your analogy a bit
further):
You want an 'extensible' ladder which you can keep short for the low-hanging
fruit, and extend to reach the higher ones. If you get to a tiny tree with a
huge ladder, you're going to be cursing yourself anyway as your big ladder
will make the job more difficult, IYKWIM (--you might not even need that
ladder, but still you carried it all the way down there...).
The point that would concern me is an API that forces the most trivial and
common cases into a processing-model that is actually meant to accommodate
rather complicated structures. So you'd end up having an overhead in 95% of
the cases, overhead which strictly speaking is meant to occur in only 5% of
the possible situations.
If it results in (virtually) no overhead at all, this point of course
dissolves totally... the ladder is then extensible in just the right way.
There's a lot of subjective judgement in making such calls, which is why 
it's useful to have a number of different opinions kicking ideas around.


I wasn't thinking of the buffers.  The re-usability of the buffers is
only relevant to static-content and markers, so I don't see that as a
major issue, and would expect to keep the static-content buffers for a
page in memory for the life of the page-sequence.  Markers are a bit
more problematical, and may well benefit from some "transparent"
serialization.


Sorry, I'm still a bit misguided, it seems. This part, I already got, but...


I was thinking more of the "historical" parts of the FO and Area trees.


... putting quotes around there is to beg the question, so, would that be
the parts that have already been processed in some way?
Yes.  Candidates would be FOs and areas associated with pages containing 
forward references, and, in general such objects associated with the 
current page sequence, from the point of view of possible layout 
optimisation.


 At one stage I considered linking all nodes in the FO tree with
reference objects, but I was concerned about the extra layer of
reference objects and their impact on memory and performance.  However,
when we get parallel FO tree, Area tree and rendering working it may pay
dividends.
I find the language of the java.lang.ref package confusing, but I think
that phantom references open the possibility of performing serialization
 "on demand", when the object is queued for GC.


Can you elaborate a bit on this? AFAICT, the actual referent of a phantom
reference is itself unreachable through the reference object (the ref's
get() method always returns null), so you could indeed test via isEnqueued()
whether or not the referent of a phantom reference is queued for GC, and
then...? A soft reference at least would allow to get() the object and do
something with it or make it do something with itself before actually
clearing the ref.
As I say, I find the language confusing, but it seemed to me that, as 
long as the object being GC'd contained enough information to determine 
its origins, when it found its way onto the reference queue for disposal 
the thread responsible could serialize it just before it was destroyed, 
and store the information required for its recovery in the appropriate 
place.  The same may be achievable using the other reference types.

Whether the imprecations against finalizers apply also to phantom 
reference finalizers I don't know.

Peter
--
Peter B. West 

RE: [PATCH] Support for percentages and table-units

[Andreas L. Delmelle]

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


> There's a lot of subjective judgement in making such calls, which is why
> it's useful to have a number of different opinions kicking ideas around.
>

Yeah.. it probably is too subjective to settle in a few sentences. Of
course, a whole lot of different 'types' of 'most common cases' are possible
(--depending more on the usage context: 1 or 2 paged, but very
processor-intensive documents vs. 48 pages of plain body-text )

I guess it calls more for a sort of recon approach (checking out the tree
before deciding what ladder to bring :) one trip back to the workshop was
part of the deal...)


> >>I find the language of the java.lang.ref package confusing, but I think
> >>that phantom references open the possibility of performing serialization
> >>  "on demand", when the object is queued for GC.
> >>
> >
> >
> > Can you elaborate a bit on this? AFAICT, the actual referent of
> a phantom
> > reference is itself unreachable through the reference object (the ref's
> > get() method always returns null), so you could indeed test via
> isEnqueued()
> > whether or not the referent of a phantom reference is queued for GC, and
> > then...? A soft reference at least would allow to get() the
> object and do
> > something with it or make it do something with itself before actually
> > clearing the ref.
>
> As I say, I find the language confusing, but it seemed to me that, as
> long as the object being GC'd contained enough information to determine
> its origins, when it found its way onto the reference queue for disposal
> the thread responsible could serialize it just before it was destroyed,
> and store the information required for its recovery in the appropriate
> place.  The same may be achievable using the other reference types.
>

In a way, I was actually wondering whether you were thinking of only using
the phantom ref to *test* for an object being queued, and possibly use the
object itself to do the serialization?
(science-fiction: I was thinking of an object being created and being
phantom referenced, and when being created, also being given a way to access
its own phantom reference to be able to find out whether it is scheduled for
GC, and if so, trigger a serialize() method... seemed a bit 'ridiculous'
when I thought it over --in the sense of: ridiculously unfeasible, my wild
imagination)

> Whether the imprecations against finalizers apply also to phantom
> reference finalizers I don't know.
>

Hmm. IIC the whole idea of Reference objects is to allow more fine-grained
control WRT object finalizing. Where a finalizer is executed *when* an
object is scheduled for GC, period. With the reference types, this control
is left to the programmers --i.e. conditional finalizing.. You could write a
finalizer whose body is totally conditional (enclosed in an if-statement),
but the method would be entered anyway in the case of a 'classic' finalizer,
even if only to perform the test.
By use of the ref types, one can even choose to execute a different kind of
finalizer for different situations, and, more importantly, it separates the
finalizing logic from the logic of the object/class.

So whether the imprecations against finalizers also apply here, depends
totally upon ourselves, it would seem.

Cheers,

Andreas

Re: [PATCH] Support for percentages and table-units

[J.Pietschmann]

Finn Bock wrote:
I don't understand how you propose to solve any of this, but I hope it 
would be Ok to commit the straight forward solution I propose.
Whatever works. I just want to note that given the almost one-
to-one correspondence between FOs and LMs both in classes and
instances (with the exceptions of page, column and line LM),
the only advantages of having LMs is
- code reuse by inheritance
- no layout related data in the FO, for better sharing/reuse
Keeping area dimensions in the FO kills the latter.
For storing reference measurements for resolving in the layout
context, you have only to keep track of inheritable properties,
which are basically font-size, ipd and bpd. References to
specified values (in contrast to computed values) can be handled
by splicing in the parsed property expression for the referenced
property as replacement for the referencing function. This way
the FO tree holds properties (parsed property expressions), while
the layout context and the area tree hold the refined traits.
J.Pietschmann

Re: [PATCH] Support for percentages and table-units

[Finn Bock]

[Finn Bock]

I don't understand how you propose to solve any of this, but I hope it 
would be Ok to commit the straight forward solution I propose.
[J.Pietschmann]

Whatever works. I just want to note that given the almost one-
to-one correspondence between FOs and LMs both in classes and
instances (with the exceptions of page, column and line LM),
the only advantages of having LMs is
- code reuse by inheritance
- no layout related data in the FO, for better sharing/reuse
Keeping area dimensions in the FO kills the latter.
That is not correct. Temporarily storing the area dimension in the FO 
tree just long enough for the getNextBreakPoss() to return does *not* in 
any way prevent reusing the FO tree or the LM tree for an other 
rendering run.

There is also more good reasons for having an LM tree than just code 
reuse. The lineLM and a separate place for the layout logic just to name 
two.

For storing reference measurements for resolving in the layout
context, you have only to keep track of inheritable properties,
which are basically font-size, ipd and bpd. References to
specified values (in contrast to computed values) can be handled
by splicing in the parsed property expression for the referenced
property as replacement for the referencing function. 
I don't know what splicing means, but the issue that I don't understand 
your solution to is when a child fo makes a reference to an computed 
value that is an expression (like "10% of IPD of 'a'") in a parent fo.


   
   

This way
the FO tree holds properties (parsed property expressions), while
the layout context and the area tree hold the refined traits.
I propose to store the specified expression (the "10% of IPD of 'a'") in 
the parent fo. But if that design is chosen, any reference to that 
property in the parent fo must ensure that the base value that is in 
effect for the parent fo is available.

The base values for the parent fo (IPD of 'a') is not currently 
available in the layout context for 'b'. Only the IPD of 'b' value 
exists in the LayoutContext for 'b'. And there is not even a single area 
created yet.

Using the LayoutContext would be a clean design, but first the 
LayoutContexts must be linked together with the LayoutContext from the 
parent fo and the LayoutContext must have a reference to the fo element 
so that the LengthBase can decide how far up the LayoutContext chain it 
should go in order to find the base value that is valid for the parent fo.

I'd be +0 to volunteer  somebody to implement that.

Should we delay my proposed patch until somebody has come up with an 
implementation that pass the LayoutContext to all Length.getValue(lc) calls?

regards,
finn

Re: [PATCH] Support for percentages and table-units

[J.Pietschmann]

Finn Bock wrote:

That is not correct. Temporarily storing the area dimension in the FO 
tree just long enough for the getNextBreakPoss() to return does *not* in 
any way prevent reusing the FO tree or the LM tree for an other 
rendering run.
It prevents overlapping/concurrent runs. Whether these are useful
is quite another matter.
There is also more good reasons for having an LM tree than just code 
reuse. The lineLM and a separate place for the layout logic just to name 
two.
Given that there is a LM class for each FO class, and a LM
object for each FO which basically duplicates most of the FO
data, I don't think the three additional LM classes count
all that much. And I'm not sure why it's an advantage to
separate layout logic from the FO tree while the FOs are
still used to store transient data used in the layout
process.
Code reuse is an issue, but it can also be solved through
delegation.
The real benefit of separating LM and FO would be pluggable
layout engines, but I have the feeling this would also collide
with using the FOs as storage for some layout process data.
I don't know what splicing means,
 

(I have to make up a function because a quick check of section
5.10 indicates there is *no* function which returns the unresolved
value, contrary to what I seemed to remember)
The b block border-start-width is parsed into a tree
  plus
+-- 10mm
+-- my:get
and after the arguments of the function has been parsed,
the calling node is replaced with the parsed tree of the
a block property:
  plus
+-- 10mm
+-- plus
+-- 1mm
+-- 10%
This can be folded into
  plus
+-- 11mm
+-- 10%
if someone feels like implementing constant folding. The 10%
will be resolved when the b block LM looks for break positions,
as usual.



but the issue that I don't understand 
your solution to is when a child fo makes a reference to an computed 
value that is an expression (like "10% of IPD of 'a'") in a parent fo.
Wild pseudocode
  getNextBreak(LayoutContext lc) {
...
BorderAndPadding  bp = propMgr.get(lc); // get and resolve
...
LayoutContext childLC = new LayoutContext(...)
childLC.setBorderAndPadding(bp) // or pass it elsewhere
childLM.getNextBreak(childLC);
Setting *all* potentially inheritable properties (inheritable
via 'inherit', not necessarily automatically inheritable) may
be a bit clumsy, but there could be some refactoring to bundle
it otherwise, or even that
  new LayoutContext(propMgr,lc)
creates all resolved properties in the new layout context.

I'd be +0 to volunteer  somebody to implement that.
Me too :-)

Should we delay my proposed patch until somebody has come up with an 
implementation that pass the LayoutContext to all Length.getValue(lc) 
calls?
I don't see much value in delaying your patch, but let's keep
an eye (or bugzilla entry) on this issue.
J.Pietschmann

DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778

[PATCH] Support for percentages and table-units





--- Additional Comments From [EMAIL PROTECTED]  2004-02-08 20:43 ---
Created an attachment (id=10273)
A unified diff against HEAD.

DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778

[PATCH] Support for percentages and table-units





--- Additional Comments From [EMAIL PROTECTED]  2004-02-14 22:05 ---
Finn,

I have only just started to understand this, but I found a problem when running
the fo file which I will attach next.

Exception in thread "main" java.lang.NullPointerException
at org.apache.fop.fo.expr.NumericOp.addition(NumericOp.java:73)
at
org.apache.fop.fo.properties.IndentPropertyMaker.compute(IndentPropertyMaker.java:117)
at org.apache.fop.fo.properties.PropertyMaker.compute(PropertyMaker.java:588)
at 
org.apache.fop.fo.properties.PropertyMaker.findProperty(PropertyMaker.java:274)
at 
org.apache.fop.fo.properties.PropertyMaker.findProperty(PropertyMaker.java:283)
at org.apache.fop.fo.properties.PropertyMaker.get(PropertyMaker.java:305)
at org.apache.fop.fo.PropertyList.get(PropertyList.java:282)
at org.apache.fop.fo.PropertyList.get(PropertyList.java:268)
at org.apache.fop.fo.PropertyManager.getMarginProps(PropertyManager.java:332)
at 
org.apache.fop.fo.pagination.RegionBody.getViewportRectangle(RegionBody.java:90)
at
org.apache.fop.layoutmgr.PageLayoutManager.makeRegionViewport(PageLayoutManager.java:832)
at
org.apache.fop.layoutmgr.PageLayoutManager.createPageAreas(PageLayoutManager.java:805)
at
org.apache.fop.layoutmgr.PageLayoutManager.createPage(PageLayoutManager.java:744)
at
org.apache.fop.layoutmgr.PageLayoutManager.makeNewPage(PageLayoutManager.java:464)
at 
org.apache.fop.layoutmgr.PageLayoutManager.doLayout(PageLayoutManager.java:216)
at org.apache.fop.layoutmgr.PageLayoutManager.run(PageLayoutManager.java:204)
at org.apache.fop.layoutmgr.LayoutManagerLS.format(LayoutManagerLS.java:113)
at org.apache.fop.apps.Document.foPageSequenceComplete(Document.java:348)
at
org.apache.fop.fo.FOTreeHandler.notifyPageSequenceComplete(FOTreeHandler.java:533)
at org.apache.fop.fo.FOTreeHandler.endPageSequence(FOTreeHandler.java:219)
at org.apache.fop.fo.pagination.PageSequence.end(PageSequence.java:353)
at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:235)
at
org.apache.fop.tools.ProxyContentHandler.endElement(ProxyContentHandler.java:126)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)

elementName: "fo:region-body"
parent elementName: "fo:simple-page-master"
propId = 212: PR_START_INDENT
corresponding: 136, PR_MARGIN_LEFT (in lr_tb)

Retrieving the corresponding property of the parent FO

The property is a RelativeNumericProperty:

main[1] print prop
 prop = "(4000mpt +20.0%)"

main[1] dump prop
 prop = {
operation: 1
op1: instance of org.apache.fop.fo.properties.FixedLength(id=685)
op2: instance of org.apache.fop.fo.properties.PercentLength(id=684)
dimension: 1
org.apache.fop.fo.properties.Property.specVal: null
}

PropertyList:
main[1] print this
 this = "{master-name=simpleA4, margin=[(4000mpt +20.0%)]}"

In IndentPropertyMaker.compute
   RelativeNumericProperty.getNumeric() returns null

In NumericOp.addition:
main[1] locals
Method arguments:
op1 = instance of org.apache.fop.fo.properties.FixedLength(id=773)
op2 = null

DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778

[PATCH] Support for percentages and table-units





--- Additional Comments From [EMAIL PROTECTED]  2004-02-14 22:07 ---
Created an attachment (id=10362)
The fo file that shows the problem

DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778

[PATCH] Support for percentages and table-units





--- Additional Comments From [EMAIL PROTECTED]  2004-02-15 02:32 ---
I am not a XSL-FO expert but is this valid, eg.

For "margin-..." properties percentages in expressions apply to the margins of 
the enclosing block. Does a "simple-page-master" have an enclosing block with 
valid margins? If not the above expression cannot be resolved.

Of course, even if that is the case FOP shouldn't throw a NPE.

DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778

[PATCH] Support for percentages and table-units





--- Additional Comments From [EMAIL PROTECTED]  2004-02-15 16:41 ---
Good catch Simon, thanks for taking time to look at it. The NPE is due to a 
missing implementation of getNumeric() in RelativeNumericProperty (which should 
contain "return this;").

I would guess that your example are using margins in a page context, so I have 
made it return 20% of the page width. But margin-[top,bottom] also used page-
width but they should be using page-height as their base and that isn't handled 
correctly yet.

I'll attach a new patch which fixes the bugs you found and also merges the 
different getters in FObj into a single getLayoutDimension().

DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778

[PATCH] Support for percentages and table-units





--- Additional Comments From [EMAIL PROTECTED]  2004-02-15 16:46 ---
Created an attachment (id=10366)
Unified diff against HEAD (version 2).

DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778

[PATCH] Support for percentages and table-units





--- Additional Comments From [EMAIL PROTECTED]  2004-02-15 20:46 ---
Finn,

I see you also solved another problem, viz. that fo:layout-master-set
did not return a proper IPD. However, I am not happy with your
solution. During the layout process, you feed the page dimensions back
into the FO tree, in PageLayoutManager.createPageAreas. I think it
would be a better design if, in order to resolve the percent-based
properties, you would not climb the FO tree but the Area tree. That
avoids feeding back results from the Area tree into the FO tree.

The XSL spec says (XSL-PR/slice3.html#section-N1208-Conceptual-Procedure):

'The formatting object supplies parameters to its children based on the
traits of areas already in the area tree, possibly including areas
generated by the formatting object or its ancestors.'

Holding those parameters in the FO tree is one solution. Extracting
them from the area tree layed out up to that point is another
solution, which has the advantage that it does not load the FO tree
with information that it does not need to have.

DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778

[PATCH] Support for percentages and table-units

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-02-26 15:59 ---
Applied.

DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778

[PATCH] Support for percentages and table-units





--- Additional Comments From [EMAIL PROTECTED]  2004-02-26 15:58 ---
Further discussions on fop-dev:

http://marc.theaimsgroup.com/?l=fop-dev&m=107688130007968&w=2
http://marc.theaimsgroup.com/?l=fop-dev&m=107687318301307&w=2
http://marc.theaimsgroup.com/?l=fop-dev&m=107627414405846&w=2

DO NOT REPLY [Bug 26778] New: - [PATCH] Support for percentages and table-units

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778

[PATCH] Support for percentages and table-units

   Summary: [PATCH] Support for percentages and table-units
   Product: Fop
   Version: 1.0dev
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This patch add support for percentages and table-units in property values 
and for calculations that involves these values in property expressions.

The patch contain the follow changes to the property sub-system:

- Add a small interface: Numeric which describe the public 
  methods for all types of numerics.
- Make all the length subclasses implement Numeric and Length
- Clean out NumericProperty so it represent an absolute numeric.
- Add class RelativeNumericProperty which represent an exression tree which
  involve relative numeric operand(s).
- Adds a NumericOp class with static calculus methods that does the 
  calculation if the operand(s) are absolute or create an expression node
  so the evaluation will be done when getValue() or getNumericValue() is
  called.

And the following changes to the layout subsystem:

- Add getters for block and referenceArea dimensions and tableUnits to FObj.
- Override getter for block, referenceArea and tableUnits in the fo's
  that define new values for such areas.
- Make the LMs assign values for block, referenceArea and tableUnits 
  just before curLM.getNextBreakPoss() is called.
- Delay evaluation of the final call to Length.getValue() until
  layouting is in progress and the base value are available.

Please note that I'm a bit confused about the exact definition of the areas,
blocks and boxes that are described under 'percentage' for each property in
the spec so it is quite likely that the values assigned in the LMs are
incorrect and/or the properties uses the wrong area/block/box when resolving 
a relative length. I still hope that the patch shows a valid approach for
adding support for relative lengths.

It is likely that more getters must be defined in FObj, f.ex. for the 
padding area.

After applying the patch the following files should be removed:

src/java/org/apache/fop/fo/properties/LinearCombinationLength.java
src/java/org/apache/fop/fo/properties/MixedLength.java

Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

[Simon Pepping]

On Sun, Feb 15, 2004 at 02:32:13AM -, [EMAIL PROTECTED] wrote:
> 
> --- Additional Comments From [EMAIL PROTECTED]  2004-02-15 02:32 ---
> I am not a XSL-FO expert but is this valid, eg.
> 
> For "margin-..." properties percentages in expressions apply to the margins of 
> the enclosing block. Does a "simple-page-master" have an enclosing block with 
> valid margins? If not the above expression cannot be resolved.
> 
> Of course, even if that is the case FOP shouldn't throw a NPE.

I think we agree on the intended behaviour. The point here is the
implementation, which had a small glitch.

The enclosing block is the page. It is not really the enclosing block
of the simple-page-master, nor of the region-body, but of the areas
they generate. Resolution is done w.r.t. the area tree.

Regards, Simon

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

Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

[Simon Pepping]

On Sun, Feb 15, 2004 at 04:41:46PM -, [EMAIL PROTECTED] wrote:
> --- Additional Comments From [EMAIL PROTECTED]  2004-02-15 16:41 ---
> Good catch Simon, thanks for taking time to look at it. The NPE is due to a 
> missing implementation of getNumeric() in RelativeNumericProperty (which should 
> contain "return this;").
> 
> I would guess that your example are using margins in a page context, so I have 
> made it return 20% of the page width. But margin-[top,bottom] also used page-
> width but they should be using page-height as their base and that isn't handled 
> correctly yet.
> 
> I'll attach a new patch which fixes the bugs you found and also merges the 
> different getters in FObj into a single getLayoutDimension().

I like the patch and the way RelativeNumericProperty holds and
evaluates an expression tree (except my different preference for
storing layout information, as discussed). This is really nice and
works well:

  v = "(((0mpt +(4000mpt +20.0%)) +0mpt) +0mpt)"

I found a few things that may need modification:

In LengthBase.java:

/** array of valid percent-based length types */
public static final int[] PERCENT_BASED_LENGTH_TYPES
= { CUSTOM_BASE, FONTSIZE, INH_FONTSIZE, CONTAINING_BOX,
CONTAINING_REFAREA } ;

add BLOCK_WIDTH and BLOCK_HEIGHT

(Is this variable used anywhere?)

Block, BlockContainer, Table, Region, PageLayoutManager: getters and
setters should be removed again?

In LineLayoutManager.java:

private Length iTextIndent;

remove the i from the name; it stands for int.

Regards,
Simon Pepping

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

Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

[Finn Bock]

[Simon Pepping]

I like the patch and the way RelativeNumericProperty holds and
evaluates an expression tree (except my different preference for
storing layout information, as discussed). This is really nice and
works well:
	  v = "(((0mpt +(4000mpt +20.0%)) +0mpt) +0mpt)"

I found a few things that may need modification:

In LengthBase.java:

/** array of valid percent-based length types */
public static final int[] PERCENT_BASED_LENGTH_TYPES
= { CUSTOM_BASE, FONTSIZE, INH_FONTSIZE, CONTAINING_BOX,
CONTAINING_REFAREA } ;
add BLOCK_WIDTH and BLOCK_HEIGHT

(Is this variable used anywhere?)
I don't think so.

Block, BlockContainer, Table, Region, PageLayoutManager: getters and
setters should be removed again?
Yes.

In LineLayoutManager.java:

private Length iTextIndent;

remove the i from the name; it stands for int.
Yes.

regards,
finn

Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

[Peter B. West]

Re-resending...

 Original Message 
Subject: Re: DO NOT REPLY [Bug 26778]  - [PATCH] Support for percentages
and table-units
Date: Fri, 20 Feb 2004 08:05:20 +1000
Simon Pepping wrote:
I like the patch and the way RelativeNumericProperty holds and
evaluates an expression tree (except my different preference for
storing layout information, as discussed). This is really nice and
works well:
	  v = "(((0mpt +(4000mpt +20.0%)) +0mpt) +0mpt)"
Finn,

Can you describe your expression tree in more detail?

Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>

Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

[Finn Bock]

[Simon Pepping]

I like the patch and the way RelativeNumericProperty holds and
evaluates an expression tree (except my different preference for
storing layout information, as discussed). This is really nice and
works well:
  v = "(((0mpt +(4000mpt +20.0%)) +0mpt) +0mpt)"
[Peter B. West]

Can you describe your expression tree in more detail?
The line above is most likely the toString() on the expression that is 
the result of a start-indent calculation from [5.3.2].

Each set of parens represent an algebra operation node in a (mostly) 
binary tree. The expression above is actually stored like this.

v
|
+-ADD
  |
  +--0mpt
  |
  +--ADD
 |
 +--0mpt
 |
 +--ADD
|
+--ADD
|  |
|  +-- 4000mpt
|  |
|  +-- %20 of REFERENCE_IPD
|
+-- 0mpt
The tree is created lazily during the evaluation of expression in the 
property parser. If both the operands to an operation are absolute, the 
operation is performed at parse time, but if either one of the operands 
are relative values, an operation-node is created. The operation node is 
also considered to be a relative value, so the next operation that 
involves an operation node will always create a new operation node.

(Note to self: Perhaps it is worthwhile to detect if one of the operands 
in a ADD and SUB operation is 0? It would perhaps reduce memory for the 
majority of start-indent expressions).

A node on the operation tree is represented by an instance of 
fo.expr.RelativeNumericProperty. The code that creates the tree is 
located in NumericOp and it is called from the PropertyParser.

When a property is retrieved by the LMs, it is the final call to 
Length.getValue() or Numeric.getNumericValue() that triggers the 
evaluation of the operation tree. At that time the REFERENCE_IPD value 
should have been assigned by the LMs to one of the parent fo:elements.

regards,
finn

Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units

[Peter B. West]

Finn,

Nice.  The parser, of course, looks after all of the expression-ordering 
questions for you, and you have only to collect the unresolved items. 
I'll adopt this for alt-design.

Peter

Finn Bock wrote:
[Peter B. West]

Can you describe your expression tree in more detail?


The line above is most likely the toString() on the expression that is 
the result of a start-indent calculation from [5.3.2].

Each set of parens represent an algebra operation node in a (mostly) 
binary tree. The expression above is actually stored like this.

v
|
+-ADD
  |
  +--0mpt
  |
  +--ADD
 |
 +--0mpt
 |
 +--ADD
|
+--ADD
|  |
|  +-- 4000mpt
|  |
|  +-- %20 of REFERENCE_IPD
|
+-- 0mpt
The tree is created lazily during the evaluation of expression in the 
property parser. If both the operands to an operation are absolute, the 
operation is performed at parse time, but if either one of the operands 
are relative values, an operation-node is created. The operation node is 
also considered to be a relative value, so the next operation that 
involves an operation node will always create a new operation node.

(Note to self: Perhaps it is worthwhile to detect if one of the operands 
in a ADD and SUB operation is 0? It would perhaps reduce memory for the 
majority of start-indent expressions).

A node on the operation tree is represented by an instance of 
fo.expr.RelativeNumericProperty. The code that creates the tree is 
located in NumericOp and it is called from the PropertyParser.

When a property is retrieved by the LMs, it is the final call to 
Length.getValue() or Numeric.getNumericValue() that triggers the 
evaluation of the operation tree. At that time the REFERENCE_IPD value 
should have been assigned by the LMs to one of the parent fo:elements.

regards,
finn


--
Peter B. West