DO NOT REPLY [Bug 38098] [patch] allow some xsl-function calls with omitted args
https://issues.apache.org/bugzilla/show_bug.cgi?id=38098 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #8 from Glenn Adams gl...@skynav.com 2012-04-01 06:58:07 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 38098] - [patch] allow some xsl-function calls with omitted args
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38098. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38098 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #17306|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2006-01-12 11:14 --- Created an attachment (id=17399) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17399action=view) testcase -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 38098] - [patch] allow some xsl-function calls with omitted args
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38098. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38098 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-01-12 21:41 --- Patch and test file committed. Thanks. Simon -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: DO NOT REPLY [Bug 38098] - [patch] allow some xsl-function calls with omitted args
On Jan 11, 2006, at 20:52, gerhard oettl wrote: Hi Gerhard, snip / Only to be shure that i have not missed anything. - Is there any work open from my side that holds back the patch? Not really. I have this on my TODO list, going to have a look at those darn' column-numbers again anyway ;-) Later, Andreas
DO NOT REPLY [Bug 38098] - [patch] allow some xsl-function calls with omitted args
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38098. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38098 --- Additional Comments From [EMAIL PROTECTED] 2006-01-11 22:18 --- This is a fine patch. Can you supply a test case for each function for which you have implemented this? Simon -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: DO NOT REPLY [Bug 38098] - [patch] allow some xsl-function calls with omitted args
On Wed, Jan 11, 2006 at 09:00:59PM +0100, Andreas L Delmelle wrote: On Jan 11, 2006, at 20:52, gerhard oettl wrote: Is there any work open from my side that holds back the patch? Not really. Thanks that all I want to know. I have this on my TODO list, going to have a look at those darn' column-numbers again anyway ;-) They do not affect this patch - only the not implemented from-table-column function which I have (more or less) ready for descendants of table-cell, but I want to wait because it overlaps with this one. Later, No problem gerhard ps: Testcases in progress -- .''`. gerhard oettl on Debian/Gnu Linux : :' : `. `'` gpg key: 1024D/D59131AA 2002-06-18 `-
Re: DO NOT REPLY [Bug 38098] - [patch] allow some xsl-function calls with omitted args
On Wed, Jan 04, 2006 at 08:37:31PM +0100, Andreas L Delmelle wrote: On Jan 4, 2006, at 20:22, Andreas L Delmelle wrote: On Jan 4, 2006, at 14:55, gerhard oettl wrote: as far as i can see this cannot be assurred for table-cell with the current code at the point this function is called. Hmmm... The columns will always be available To expand, a little remark: try '((TableCell) pInfo.getFO ()).getColumnNumber()' This was the beginning of my illness some days ago ;-) It always ends with a NullPointerExection. The following is much suspection, because i only get slowly familiar with that powerfull concepts of mapping, events, event-like triggers and so on (especialy about the order and the exact time when they are called)so that i am not quite shure about the followint, but my tests confirm my sight: When running into the FromTableColumnFunction we are at the stage of collecting properties long before the binding [1]. For the order i see two possibilities: a) left to right in the property-string b) unorederd in the sense that the sax engine decides in whitch order it delivers the properties (may be you could clarify, but only if possible in some words - otherwise dont matter, the time and the source will bring light ...) Now I'm thinking that perhaps the column-number property does need to be bound first in TableCell.bind() for this to work properly... this does not help because of [1] A call to PropertyList.get(PR_COLUMN_NUMBER) for the table-cell should take care of resolving the column-number for that cell, if it wasn't already initialized. a test with the following fo-fragment arges against it: fo:table-body fo:table-row fo:table-cell display-align=from-table-column() column-number=3 reports a column-number of 1, what would make case a) possible/likely. In other words, at the thime the from-table-column() is evaluated the PropertyList does not know about the following _explicit_ column-number. A additional side-effect is that the call makes the wrong column-number 1 permanent and i get a OverlapExeception when the cell with the realy explicit column-number 1 arises in the fo-file. That let me see two ways (in that order): 1) Only handle descendants of table-cell, which is not a great restriction for me, because - as shown in a previos fo-snippet - i primary want to use table-column as info container for properties of fo:block elements. At this time the full table-cell (expecialy the column-number) is available. 2) Defer all properties that need a call to FromTableColumnFunction to be evaluated at the end of the property-collecting / parsing stage. This is a little too tricky for me with my current knowledge of the code and a source for later improvement. and yes 3) I hope i am wrong with my pessimistic sight and you could lead me out of the misery ;-)) gerhard -- .''`. gerhard oettl on Debian/Gnu Linux : :' : `. `'` gpg key: 1024D/D59131AA 2002-06-18 `-
Re: DO NOT REPLY [Bug 38098] - [patch] allow some xsl-function calls with omitted args
On Jan 5, 2006, at 11:42, gerhard oettl wrote: On Wed, Jan 04, 2006 at 08:37:31PM +0100, Andreas L Delmelle wrote: On Jan 4, 2006, at 20:22, Andreas L Delmelle wrote: To expand, a little remark: try '((TableCell) pInfo.getFO ()).getColumnNumber()' This was the beginning of my illness some days ago ;-) It always ends with a NullPointerExection. The following is much suspection, because i only get slowly familiar with that powerfull concepts of mapping, events, event-like triggers and so on (especialy about the order and the exact time when they are called)so that i am not quite shure about the followint, but my tests confirm my sight: When running into the FromTableColumnFunction we are at the stage of collecting properties long before the binding [1]. And you're right again... I must admit that I don't yet fully grasp the depths of the Property system myself. More and more every day, but still far from complete, especially the interaction with the FOTree building/creation. For the order i see two possibilities: a) left to right in the property-string b) unorederd in the sense that the sax engine decides in whitch order it delivers the properties (may be you could clarify, but only if possible in some words - otherwise dont matter, the time and the source will bring light ...) It's b), AFAIU. The SAX parser presents the properties as a list of Attributes. Except for the font-size attribute, the Attributes are converted into Property objects in the order they are encountered in the list. (see: PropertyList.addAttributesToList()) Now I'm thinking that perhaps the column-number property does need to be bound first in TableCell.bind() for this to work properly... this does not help because of [1] A call to PropertyList.get(PR_COLUMN_NUMBER) for the table-cell should take care of resolving the column-number for that cell, if it wasn't already initialized. a test with the following fo-fragment arges against it: fo:table-body fo:table-row fo:table-cell display-align=from-table-column() column- number=3 reports a column-number of 1, what would make case a) possible/ likely. Not really. See: ColumnNumberPropertyMaker.make(). If I get it correctly, the reason is that parent.getCurrentColumnIndex() will, at that point, always return the initial value of columnIndex, since the cell-node hasn't been added to the parent yet. addChildNode() will not have been called, and that is the point where currently the index is increased with each addition of a new TableCell node. In other words, at the thime the from-table-column() is evaluated the PropertyList does not know about the following _explicit_ column- number. Have you tried putting the properties in reverse-order: fo:table-cell column-number=3 display-align=from-table-column() If that works, then it's a combination of a) and b), in the sense that it's the SAX parser that does a), and then passes the list as such to the PropertyList, which does b). A additional side-effect is that the call makes the wrong column- number 1 permanent and i get a OverlapExeception when the cell with the realy explicit column-number 1 arises in the fo-file. I remember raising the question of whether the whole column-number initialization logic shouldn't be moved to the ColumnNumberPropertyMaker. Never received an answer to it, but it seems my suspicion was right: I put the right code in the wrong places... In fact, the prospect of facilitating an implementation for from- table-column() was what drove me to move it from the layoutmgr package to the fo.flow package. It seems I didn't go far enough, and it needs to be moved to the properties package. That let me see two ways (in that order): 1) Only handle descendants of table-cell, which is not a great restriction for me, because - as shown in a previos fo-snippet - i primary want to use table-column as info container for properties of fo:block elements. At this time the full table-cell (expecialy the column-number) is available. 2) Defer all properties that need a call to FromTableColumnFunction to be evaluated at the end of the property-collecting / parsing stage. This is a little too tricky for me with my current knowledge of the code and a source for later improvement. and yes 3) I hope i am wrong with my pessimistic sight and you could lead me out of the misery ;-)) If the move I described above is carried out, then I think the problem can be solved for table-cells as well as their descendant nodes. It's not going to be a trivial task though... unless I'm the one who's being too pessimistic here ;-) Cheers, Andreas
Re: [patch] allow some xsl-function calls with omitted args
On Thu, Jan 05, 2006 at 07:57:07PM +0100, Andreas L Delmelle wrote: On Jan 5, 2006, at 11:42, gerhard oettl wrote: Have you tried putting the properties in reverse-order: fo:table-cell column-number=3 display-align=from-table-column() If that works, then it's a combination of a) and b), in the sense that it's the SAX parser that does a), and then passes the list as such to the PropertyList, which does b). Never rely on the order of the attributes. Usually they will be delivered in the order of the XML file. But if a user uses a SAX parser that delivers them in a different order, the code must still work. From org.xml.sax.Attributes documentation: The order of attributes in the list is unspecified, and will vary from implementation to implementation. Simon -- Simon Pepping home page: http://www.leverkruid.nl
DO NOT REPLY [Bug 38098] - [patch] allow some xsl-function calls with omitted args
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38098. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38098 --- Additional Comments From [EMAIL PROTECTED] 2006-01-04 18:04 --- Created an attachment (id=17324) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17324action=view) patch 2 (considering the hints of Andreas L. Delmelle) additional (resolving the todo of the first patch) Changes common to 1) FromParentFunction.java: 2) FromTableColumnFunction.java: 3) InheritedPropFunction.java: 4) NearestSpecPropFunction.java: - let the padArgsWithPropertyName method return true to indicate that filling up the number of args with the property name for which the expression is being evaluated. Changes common to 1) MergePropsFunction.java: 2) SystemFontFunction.java: - ATTENTION - NONEXISTENT! Though the PropertyParser calls does a call to new MergePropsFunction() and new SystemFontFunction() greping through the codebase i cannot find such classes. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: DO NOT REPLY [Bug 38098] - [patch] allow some xsl-function calls with omitted args
On Jan 4, 2006, at 14:55, gerhard oettl wrote: snip / [Me:] given: a) that the column-numbers are all properly initialized as far as i can see this cannot be assurred for table-cell with the current code at the point this function is called. Hmmm... The columns will always be available, with properly initialized column-numbers, by the time you get to processing the cells. A call to PropertyList.get(PR_COLUMN_NUMBER) for the table-cell should take care of resolving the column-number for that cell, if it wasn't already initialized. The controlling object for dealing with implicit column-numbers is always the Table (for TableColumns) or the TableBody/TableRow (for TableCells). I'm not sure what you mean here, but this doesn't strike me as a problem. Could be that I'm missing something here, though... and b) the limited number of properties applicable to table-columns. Mybe i see something in the spec because i want to see it ;-) but read from the following: Inheritable properties may also be specified on the fo:table-column. These can be referenced by the from-table-column() function in an expression. that table-columns is a countainer for _all_ inheritable properties and i can use it in the following manner: snip / Yes! You are absolutely right, and this complicates matters somewhat. That's one thing I always seem to forget: any property can be specified on any FO regardless of whether it is applicable or not. [*] ... so it may be possible to map it to a call to the appropriate method in fo.flow.TableColumn... example: from-table-column(1, 'border-start-width') would trigger a call to ((TableColumn) Table.getColumns().get(0)).getBorderWidth (CommonBorderPaddingBackground.START) This way i didn't know - i'll hava a look at it. But only usable for props that apply to fo:table-column, since TableColumn has no accessors for non-applicable properties. Two ways to solve this: 1) look for the nearest ancestor to which the property in question does apply 2) as stated earlier, keep the PropertyLists for the columns alive until the end of the table The first has the benefit of being a bit more memory efficient, since PropertyLists are rather large. The second is convenient, because it allows a simple mapping of the function-call to: pList.get(PR_PROPERTY_ID) Cheers, Andreas [*] Funny side-effect is that specifying an inherited property on a FO to which it doesn't apply will have no effect on that FO itself (since it will refer to the value it inherited of its ancestor) while it does affect the descendant FOs: fo:block fo:inline linefeed-treatment=preserve fo:block#x0A;/fo:block /fo:inline /fo:block The two linefeeds inside the inline are treated as spaces, while the one in the inner-block is preserved.
Re: DO NOT REPLY [Bug 38098] - [patch] allow some xsl-function calls with omitted args
On Jan 4, 2006, at 20:22, Andreas L Delmelle wrote: On Jan 4, 2006, at 14:55, gerhard oettl wrote: as far as i can see this cannot be assurred for table-cell with the current code at the point this function is called. Hmmm... The columns will always be available, with properly initialized column-numbers, by the time you get to processing the cells. A call to PropertyList.get(PR_COLUMN_NUMBER) for the table-cell should take care of resolving the column-number for that cell, if it wasn't already initialized. The controlling object for dealing with implicit column-numbers is always the Table (for TableColumns) or the TableBody/TableRow (for TableCells). I'm not sure what you mean here, but this doesn't strike me as a problem. Could be that I'm missing something here, though... To expand, a little remark: try '((TableCell) pInfo.getFO ()).getColumnNumber()' Now I'm thinking that perhaps the column-number property does need to be bound first in TableCell.bind() for this to work properly... Cheers, Andreas
Re: DO NOT REPLY [Bug 38098] - [patch] allow some xsl-function calls with omitted args
Changes common to 1) MergePropsFunction.java: 2) SystemFontFunction.java: - ATTENTION - NONEXISTENT! Though the PropertyParser does a call to new MergePropsFunction() and new SystemFontFunction() greping through the codebase i cannot find such classes. oops - didn't look closely to the output of grep. The mentioned calls are alredy commented out. sorry for the false alarm. gerhard -- .''`. gerhard oettl on Debian/Gnu Linux : :' : `. `'` gpg key: 1024D/D59131AA 2002-06-18 `-
DO NOT REPLY [Bug 38098] - [patch] allow some xsl-function calls with omitted args
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38098. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38098 [EMAIL PROTECTED] changed: What|Removed |Added Summary|[patch] allow some xsl- |[patch] allow some xsl- |function calls with omitted |function calls with omitted |args|args --- Additional Comments From [EMAIL PROTECTED] 2006-01-03 22:59 --- Gerhard, Again, a nice little addition! To help you out a bit further with the TODO, and minimize the searching: all those functions reside in the package org.apache.fop.fo.expr (apart from system-font()). They have slightly different names, but easily recognizable. For example: from-nearest-specified-value = NearestSpecPropFunction. Come to think of it, maybe this should be renamed as a matter of style to FromNearestSpecValFunction or something like that... (?) from-table-column() is currently unimplemented, but it shouldn't be particularly hard, given: a) that the column-numbers are all properly initialized and b) the limited number of properties applicable to table-columns. If you already know your way around the properties package well enough: the PropertyList for a TableColumn will, IIC, no longer be available at the time this function is called, so it may be possible to map it to a call to the appropriate method in fo.flow.TableColumn... example: from-table-column(1, 'border-start-width') would trigger a call to ((TableColumn) Table.getColumns().get(0)).getBorderWidth(CommonBorderPaddingBackground.START) Either that, or references to the columns' PropertyLists need to be kept alive during the whole lifecycle of the Table object. Cheers, Andreas -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 38098] - [patch] allow some xsl-function calls with omitted args
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=38098. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=38098 --- Additional Comments From [EMAIL PROTECTED] 2006-01-02 16:11 --- Created an attachment (id=17307) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17307action=view) a fo-file to show the effect -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
