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

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

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

2004-02-24 Thread 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,
 fo:block id=a border-start-width=1mm+10%
fo:block id=b border-start-width=10mm
   +my:get('a:border-start-width)
(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 wink 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


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

2004-02-23 Thread Andreas L. Delmelle
 -Original Message-
 From: Peter B. West [mailto:[EMAIL PROTECTED]

Some babbling about trees and ladders ...
snip /
 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...)

snip /
 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

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

2004-02-22 Thread Andreas L. Delmelle
 -Original Message-
 From: Peter B. West [mailto:[EMAIL PROTECTED]

snip /
 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

2004-02-22 Thread Peter B. West
Andreas L. Delmelle wrote:
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]
snip /

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


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

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

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'.
[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

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

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

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

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:

fo:flow flow-name=xsl-region-body
  fo:block leader-length=30% leader-pattern=rule
fo:leader/
fo:block margin-left=60pt margin-right=60pt
  fo:leader/
  fo:blockThis 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./fo:block
/fo:block
  /fo:block
/fo:flow

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

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

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

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

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'.


[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

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

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

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'.
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

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

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

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

2004-02-18 Thread Andreas L. Delmelle

snip /
 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

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

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

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'.

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

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

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

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

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

2004-02-17 Thread 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-devm=107503563018878w=2
[2]
http://marc.theaimsgroup.com/?l=fop-devm=107688130007968w=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

2004-02-16 Thread Andreas L. Delmelle
 -Original Message-
 From: Finn Bock [mailto:[EMAIL PROTECTED]

 [Simon Pepping]

snip /
  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?

snip /
  [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

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

2004-02-16 Thread 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]
 
 snip /
   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

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

2004-02-16 Thread Andreas L. Delmelle
 -Original Message-
 From: Simon Pepping [mailto:[EMAIL PROTECTED]

snip /
 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

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