RE: JAXP question
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] I tried a little bit more, but was unsuccessful. XMLFilter + setParameter() unfortunately isn't currently available with JAXP, and I suspect the just-use-a-transformer alternative proposed by Michael Kay here: http://www.xslt.com/xsl-list/2002-08/msg00312.html will slow things down for non-parameter using people. (I'm also not sure if your suggestion would work, as the getContentHandler() is set later, in apps.Driver.) Well, I wouldn't stare myself too blind on it for the moment... Could well be that my suggestion won't work --as it was more based on vague ideas than on actual experiments (maybe should've tried out first, sorry for that) I modified the JAXP example to show the setting of a parameter, so FOP users will be OK for embedded usage, at least. Getting this right *was* the more important of the two IMHO. When using XML/XSLT input via the command-line, one can indeed easily break up the transformation, supply the params to the XSL processor in question, and run the resulting FO through FOP. Thanks for the effort! Cheers, Andreas
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.
[PATCH] Support for percentages and table-units
[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 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. 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. 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. regards, finn
cvs commit: xml-fop/src/java/org/apache/fop/area BlockArea.java Area.java
pbwest 2004/02/15 16:15:29
Modified:src/java/org/apache/fop/datastructs Tag:
FOP_0-20-0_Alt-Design SyncedNode.java
src/java/org/apache/fop/area Tag: FOP_0-20-0_Alt-Design
BlockArea.java Area.java
Log:
Extended some comments
Revision ChangesPath
No revision
No revision
1.1.2.2 +9 -9
xml-fop/src/java/org/apache/fop/datastructs/Attic/SyncedNode.java
Index: SyncedNode.java
===
RCS file:
/home/cvs/xml-fop/src/java/org/apache/fop/datastructs/Attic/SyncedNode.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- SyncedNode.java 1 Feb 2004 08:12:00 - 1.1.2.1
+++ SyncedNode.java 16 Feb 2004 00:15:29 - 1.1.2.2
@@ -40,8 +40,8 @@
}
/**
- * @param parent
- * @param index
+ * @param parent codeNode/code of this
+ * @param index of this in children of parent
* @param sync the object on which synchronization for this
* node will occur
* @throws IndexOutOfBoundsException
No revision
No revision
1.1.2.4 +5 -5 xml-fop/src/java/org/apache/fop/area/Attic/BlockArea.java
Index: BlockArea.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/Attic/BlockArea.java,v
retrieving revision 1.1.2.3
retrieving revision 1.1.2.4
diff -u -r1.1.2.3 -r1.1.2.4
--- BlockArea.java1 Feb 2004 08:12:00 - 1.1.2.3
+++ BlockArea.java16 Feb 2004 00:15:29 - 1.1.2.4
@@ -28,8 +28,8 @@
public class BlockArea extends Area {
/**
- * @param parent
- * @param index
+ * @param parent of this node
+ * @param index of this in children of parent
* @throws IndexOutOfBoundsException
*/
public BlockArea(Node parent, int index, Object areaSync)
@@ -39,7 +39,7 @@
}
/**
- * @param parent
+ * @param parent of this node
* @throws IndexOutOfBoundsException
*/
public BlockArea(Node parent, Object areaSync)
1.1.2.4 +3 -3 xml-fop/src/java/org/apache/fop/area/Area.java
Index: Area.java
===
RCS file: /home/cvs/xml-fop/src/java/org/apache/fop/area/Area.java,v
retrieving revision 1.1.2.3
retrieving revision 1.1.2.4
diff -u -r1.1.2.3 -r1.1.2.4
--- Area.java 2 Feb 2004 02:01:44 - 1.1.2.3
+++ Area.java 16 Feb 2004 00:15:29 - 1.1.2.4
@@ -37,8 +37,8 @@
protected Integer bPDimMin = null;
/**
- * @param parent
- * @param index
+ * @param parent codeNode/code of this
+ * @param index of this in children of parent
* @throws IndexOutOfBoundsException
*/
public Area(Node parent, int index, Object areaSync)
@@ -48,7 +48,7 @@
}
/**
- * @param parent
+ * @param parent codeNode/code of this
* @throws IndexOutOfBoundsException
*/
public Area(Node parent, Object areaSync)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
XML Graphics PMC discussion - Wiki page created
As promised I've started a Wiki page with all the things I collected about the XML Graphics PMC (Batik and FOP moving closer together). This is to move on the discussion that started earlier. Once the board is satisfied with the federation proposal and this XML Graphics idea doesn't face opposition I'd like to create a concrete proposal that will be voted on by the Batik and FOP projects (and probably the XML PMC) and the approved by the board. I'd like again to invite everybody to participate in the discussion. Unless you haven't done so already please subscribe to [EMAIL PROTECTED] as this is the right place to discuss this (it's not so high-volume after all). I'd like the XML PMC to be able to follow the discussion, too. Thanks. If anybody considers this a bad idea, please speak up. There might be issues because this proposal essentially only replicates the XML project down to a smaller scale but I think this can still satisfy the board's wishes. I'm curious to your comments. http://nagoya.apache.org/wiki/apachewiki.cgi?XMLProjectPages/XMLGraphicsPMCDiscussion Jeremias Maerki
