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