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

2004-02-21 Thread 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

2004-02-21 Thread 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 http://www.powerup.com.au/~pbwest/resume.html


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

2004-02-20 Thread 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

2004-02-19 Thread 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

2004-02-19 Thread 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

2004-02-15 Thread 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.
 fo:simple-page-master master-name=simpleA4 margin=4pt+20%
 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