DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778 [PATCH] Support for percentages and table-units [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-02-26 15:59 --- Applied.
DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/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 http://marc.theaimsgroup.com/?l=fop-devm=107627414405846w=2
Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units
Finn, Nice. The parser, of course, looks after all of the expression-ordering questions for you, and you have only to collect the unresolved items. I'll adopt this for alt-design. Peter Finn Bock wrote: [Peter B. West] Can you describe your expression tree in more detail? The line above is most likely the toString() on the expression that is the result of a start-indent calculation from [5.3.2]. Each set of parens represent an algebra operation node in a (mostly) binary tree. The expression above is actually stored like this. v | +-ADD | +--0mpt | +--ADD | +--0mpt | +--ADD | +--ADD | | | +-- 4000mpt | | | +-- %20 of REFERENCE_IPD | +-- 0mpt The tree is created lazily during the evaluation of expression in the property parser. If both the operands to an operation are absolute, the operation is performed at parse time, but if either one of the operands are relative values, an operation-node is created. The operation node is also considered to be a relative value, so the next operation that involves an operation node will always create a new operation node. (Note to self: Perhaps it is worthwhile to detect if one of the operands in a ADD and SUB operation is 0? It would perhaps reduce memory for the majority of start-indent expressions). A node on the operation tree is represented by an instance of fo.expr.RelativeNumericProperty. The code that creates the tree is located in NumericOp and it is called from the PropertyParser. When a property is retrieved by the LMs, it is the final call to Length.getValue() or Numeric.getNumericValue() that triggers the evaluation of the operation tree. At that time the REFERENCE_IPD value should have been assigned by the LMs to one of the parent fo:elements. regards, finn -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units
Re-resending... Original Message Subject: Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units Date: Fri, 20 Feb 2004 08:05:20 +1000 Simon Pepping wrote: I like the patch and the way RelativeNumericProperty holds and evaluates an expression tree (except my different preference for storing layout information, as discussed). This is really nice and works well: v = (((0mpt +(4000mpt +20.0%)) +0mpt) +0mpt) Finn, Can you describe your expression tree in more detail? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units
On Sun, Feb 15, 2004 at 04:41:46PM -, [EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2004-02-15 16:41 ---
Good catch Simon, thanks for taking time to look at it. The NPE is due to a
missing implementation of getNumeric() in RelativeNumericProperty (which should
contain return this;).
I would guess that your example are using margins in a page context, so I have
made it return 20% of the page width. But margin-[top,bottom] also used page-
width but they should be using page-height as their base and that isn't handled
correctly yet.
I'll attach a new patch which fixes the bugs you found and also merges the
different getters in FObj into a single getLayoutDimension().
I like the patch and the way RelativeNumericProperty holds and
evaluates an expression tree (except my different preference for
storing layout information, as discussed). This is really nice and
works well:
v = (((0mpt +(4000mpt +20.0%)) +0mpt) +0mpt)
I found a few things that may need modification:
In LengthBase.java:
/** array of valid percent-based length types */
public static final int[] PERCENT_BASED_LENGTH_TYPES
= { CUSTOM_BASE, FONTSIZE, INH_FONTSIZE, CONTAINING_BOX,
CONTAINING_REFAREA } ;
add BLOCK_WIDTH and BLOCK_HEIGHT
(Is this variable used anywhere?)
Block, BlockContainer, Table, Region, PageLayoutManager: getters and
setters should be removed again?
In LineLayoutManager.java:
private Length iTextIndent;
remove the i from the name; it stands for int.
Regards,
Simon Pepping
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units
[Simon Pepping]
I like the patch and the way RelativeNumericProperty holds and
evaluates an expression tree (except my different preference for
storing layout information, as discussed). This is really nice and
works well:
v = (((0mpt +(4000mpt +20.0%)) +0mpt) +0mpt)
I found a few things that may need modification:
In LengthBase.java:
/** array of valid percent-based length types */
public static final int[] PERCENT_BASED_LENGTH_TYPES
= { CUSTOM_BASE, FONTSIZE, INH_FONTSIZE, CONTAINING_BOX,
CONTAINING_REFAREA } ;
add BLOCK_WIDTH and BLOCK_HEIGHT
(Is this variable used anywhere?)
I don't think so.
Block, BlockContainer, Table, Region, PageLayoutManager: getters and
setters should be removed again?
Yes.
In LineLayoutManager.java:
private Length iTextIndent;
remove the i from the name; it stands for int.
Yes.
regards,
finn
DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/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 should contain return this;). I would guess that your example are using margins in a page context, so I have made it return 20% of the page width. But margin-[top,bottom] also used page- width but they should be using page-height as their base and that isn't handled correctly yet. I'll attach a new patch which fixes the bugs you found and also merges the different getters in FObj into a single getLayoutDimension().
DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/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).
Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units
On Sun, Feb 15, 2004 at 02:32:13AM -, [EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2004-02-15 02:32 --- I am not a XSL-FO expert but is this valid, eg. fo:simple-page-master master-name=simpleA4 margin=4pt+20% For margin-... properties percentages in expressions apply to the margins of the enclosing block. Does a simple-page-master have an enclosing block with valid margins? If not the above expression cannot be resolved. Of course, even if that is the case FOP shouldn't throw a NPE. I think we agree on the intended behaviour. The point here is the implementation, which had a small glitch. The enclosing block is the page. It is not really the enclosing block of the simple-page-master, nor of the region-body, but of the areas they generate. Resolution is done w.r.t. the area tree. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/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. During the layout process, you feed the page dimensions back into the FO tree, in PageLayoutManager.createPageAreas. 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, which has the advantage that it does not load the FO tree with information that it does not need to have.
DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/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 java.lang.NullPointerException
at org.apache.fop.fo.expr.NumericOp.addition(NumericOp.java:73)
at
org.apache.fop.fo.properties.IndentPropertyMaker.compute(IndentPropertyMaker.java:117)
at org.apache.fop.fo.properties.PropertyMaker.compute(PropertyMaker.java:588)
at
org.apache.fop.fo.properties.PropertyMaker.findProperty(PropertyMaker.java:274)
at
org.apache.fop.fo.properties.PropertyMaker.findProperty(PropertyMaker.java:283)
at org.apache.fop.fo.properties.PropertyMaker.get(PropertyMaker.java:305)
at org.apache.fop.fo.PropertyList.get(PropertyList.java:282)
at org.apache.fop.fo.PropertyList.get(PropertyList.java:268)
at org.apache.fop.fo.PropertyManager.getMarginProps(PropertyManager.java:332)
at
org.apache.fop.fo.pagination.RegionBody.getViewportRectangle(RegionBody.java:90)
at
org.apache.fop.layoutmgr.PageLayoutManager.makeRegionViewport(PageLayoutManager.java:832)
at
org.apache.fop.layoutmgr.PageLayoutManager.createPageAreas(PageLayoutManager.java:805)
at
org.apache.fop.layoutmgr.PageLayoutManager.createPage(PageLayoutManager.java:744)
at
org.apache.fop.layoutmgr.PageLayoutManager.makeNewPage(PageLayoutManager.java:464)
at
org.apache.fop.layoutmgr.PageLayoutManager.doLayout(PageLayoutManager.java:216)
at org.apache.fop.layoutmgr.PageLayoutManager.run(PageLayoutManager.java:204)
at org.apache.fop.layoutmgr.LayoutManagerLS.format(LayoutManagerLS.java:113)
at org.apache.fop.apps.Document.foPageSequenceComplete(Document.java:348)
at
org.apache.fop.fo.FOTreeHandler.notifyPageSequenceComplete(FOTreeHandler.java:533)
at org.apache.fop.fo.FOTreeHandler.endPageSequence(FOTreeHandler.java:219)
at org.apache.fop.fo.pagination.PageSequence.end(PageSequence.java:353)
at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:235)
at
org.apache.fop.tools.ProxyContentHandler.endElement(ProxyContentHandler.java:126)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
elementName: fo:region-body
parent elementName: fo:simple-page-master
propId = 212: PR_START_INDENT
corresponding: 136, PR_MARGIN_LEFT (in lr_tb)
Retrieving the corresponding property of the parent FO
The property is a RelativeNumericProperty:
main[1] print prop
prop = (4000mpt +20.0%)
main[1] dump prop
prop = {
operation: 1
op1: instance of org.apache.fop.fo.properties.FixedLength(id=685)
op2: instance of org.apache.fop.fo.properties.PercentLength(id=684)
dimension: 1
org.apache.fop.fo.properties.Property.specVal: null
}
PropertyList:
main[1] print this
this = {master-name=simpleA4, margin=[(4000mpt +20.0%)]}
In IndentPropertyMaker.compute
RelativeNumericProperty.getNumeric() returns null
In NumericOp.addition:
main[1] locals
Method arguments:
op1 = instance of org.apache.fop.fo.properties.FixedLength(id=773)
op2 = null
DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/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
DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/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 in expressions apply to the margins of the enclosing block. Does a simple-page-master have an enclosing block with valid margins? If not the above expression cannot be resolved. Of course, even if that is the case FOP shouldn't throw a NPE.
DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26778. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/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.
