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

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

fo:block id=a border-start-width=10%
  fo:block id=b border-start-width=inherit
  /fo:block
/fo:block
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

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

2004-02-21 Thread 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: 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: [PATCH] Support for percentages and table-units

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

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


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

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


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