/show_bug.cgi?id=26778
[PATCH] Support for percentages and table-units
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
/show_bug.cgi?id=26778
[PATCH] Support for percentages and table-units
--- Additional Comments From [EMAIL PROTECTED] 2004-02-26 15:58 ---
Further discussions on fop-dev:
http://marc.theaimsgroup.com/?l=fop-devm=107688130007968w=2
http://marc.theaimsgroup.com/?l=fop-devm=107687318301307w=2
[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
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
-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
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
-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
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
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
[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
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
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
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
Finn,
Nice. The parser, of course, looks after all of the expression-ordering
questions for you, and you have only to collect the unresolved items.
I'll adopt this for alt-design.
Peter
Finn Bock wrote:
[Peter B. West]
Can you describe your expression tree in more detail?
The line above
[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
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
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
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)
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
Re-resending...
Original Message
Subject: Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages
and table-units
Date: Fri, 20 Feb 2004 08:05:20 +1000
Simon Pepping wrote:
I like the patch and the way RelativeNumericProperty holds and
evaluates an expression tree
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
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
On Sun, Feb 15, 2004 at 04:41:46PM -, [EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2004-02-15 16:41 ---
Good catch Simon, thanks for taking time to look at it. The NPE is due to a
missing implementation of getNumeric() in RelativeNumericProperty (which
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
[Simon Pepping]
I like the patch and the way RelativeNumericProperty holds and
evaluates an expression tree (except my different preference for
storing layout information, as discussed). This is really nice and
works well:
v = (((0mpt +(4000mpt +20.0%)) +0mpt) +0mpt)
I found a few things that
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
-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
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
--- 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
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
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
[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
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
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
--- 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
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
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, 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
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
-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
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
/show_bug.cgi?id=26778
[PATCH] Support for percentages and table-units
--- Additional Comments From [EMAIL PROTECTED] 2004-02-15 16:41 ---
Good catch Simon, thanks for taking time to look at it. The NPE is due to a
missing implementation of getNumeric() in RelativeNumericProperty (which
/show_bug.cgi?id=26778
[PATCH] Support for percentages and table-units
--- Additional Comments From [EMAIL PROTECTED] 2004-02-15 16:46 ---
Created an attachment (id=10366)
Unified diff against HEAD (version 2).
On Sun, Feb 15, 2004 at 02:32:13AM -, [EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2004-02-15 02:32 ---
I am not a XSL-FO expert but is this valid, eg.
fo:simple-page-master master-name=simpleA4 margin=4pt+20%
For margin-... properties percentages
/show_bug.cgi?id=26778
[PATCH] Support for percentages and table-units
--- Additional Comments From [EMAIL PROTECTED] 2004-02-15 20:46 ---
Finn,
I see you also solved another problem, viz. that fo:layout-master-set
did not return a proper IPD. However, I am not happy with your
solution
[Simon Pepping]
Finn,
I see you also solved another problem, viz. that fo:layout-master-set
did not return a proper IPD.
Correct. There are, I'm certain, many more cases where the layout
managers does not yet set all the dimensions needed to resolve all the
different percentages.
However, I
/show_bug.cgi?id=26778
[PATCH] Support for percentages and table-units
--- Additional Comments From [EMAIL PROTECTED] 2004-02-14 22:05 ---
Finn,
I have only just started to understand this, but I found a problem when running
the fo file which I will attach next.
Exception in thread main
/show_bug.cgi?id=26778
[PATCH] Support for percentages and table-units
--- Additional Comments From [EMAIL PROTECTED] 2004-02-14 22:07 ---
Created an attachment (id=10362)
The fo file that shows the problem
/show_bug.cgi?id=26778
[PATCH] Support for percentages and table-units
--- Additional Comments From [EMAIL PROTECTED] 2004-02-15 02:32 ---
I am not a XSL-FO expert but is this valid, eg.
fo:simple-page-master master-name=simpleA4 margin=4pt+20%
For margin-... properties percentages
Quite a piece of work. I will try to understand it.
A small correction:
On Sun, Feb 08, 2004 at 10:03:57PM +0100, Finn Bock wrote:
margin-[top,bottom]:
width of containing block, except for page context where it
^
height (I suppose).
Regards, Simon
--
Simon Pepping
[Simon Pepping]
Quite a piece of work. I will try to understand it.
A small correction:
margin-[top,bottom]:
width of containing block, except for page context where it
^
height (I suppose).
Well, not according to the spec:
/show_bug.cgi?id=26778
[PATCH] Support for percentages and table-units
Summary: [PATCH] Support for percentages and table-units
Product: Fop
Version: 1.0dev
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
/show_bug.cgi?id=26778
[PATCH] Support for percentages and table-units
--- Additional Comments From [EMAIL PROTECTED] 2004-02-08 20:43 ---
Created an attachment (id=10273)
A unified diff against HEAD.
Hi,
I just uploaded a patch which add support for percentages and
calculations on percentages to bugzilla.
I don't think that the patch is quite right in its attempt to find the
correct base length to combine with the percentage. Some of my confusion
comes from the fact that I can't tell
that
was most awkward is precised below.
Peter B. West wrote:
Original Message
Subject: Percentages + absolute lengths
Date: Fri, 07 Feb 2003 02:21:32 +1000
From: Peter B. West [EMAIL PROTECTED]
To: xsl-editors [EMAIL PROTECTED]
Please clarify the editors' expectation
FYI
Peter
Original Message
Subject: Percentages + absolute lengths
Date: Fri, 07 Feb 2003 02:21:32 +1000
From: Peter B. West [EMAIL PROTECTED]
To: xsl-editors [EMAIL PROTECTED]
Please clarify the editors' expectation for the resolution of
an expression like 25% + 3pt an FO
56 matches
Mail list logo