Position, Leaf/NonLeafPosition, wrapping positions
Hi, I have some questions regarding the handling of Position elements. I'm not familiar with that part of the code yet, and as there is little or no javadoc for those it's a bit difficult to guess their purposes just by looking at the code. What's the purpose of a LeafPosition? Of a NonLeafPosition? What's the purpose of the wrapPositionElements method in BlockStackingLayoutManager? Subsidiary question: why would one sometimes force the wrapping, sometimes not? Hope someone can answer those questions... Thanks, Vincent
DO NOT REPLY [Bug 41778] New: - [PATCH] fop.bat is broken due to old xmlgraphics-commons jar file reference
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=41778. 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=41778 Summary: [PATCH] fop.bat is broken due to old xmlgraphics-commons jar file reference Product: Fop Version: 1.0dev Platform: Other OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] fop.bat is broken due to old xmlgraphics-commons jar file reference -- 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.
fop.bat needs patching
This is a quicky.. Our fop.bat is currently broken, someone needs to update fop.bat to reflect the recently added new xmlgraphics-commons-1.2svn.jar on the trunk. I have added this patch to the patch list (http://issues.apache.org/bugzilla/show_bug.cgi?id=41778). --- fop.bat Wed Mar 07 09:32:31 2007 +++ fop.bat.origWed Mar 07 09:31:50 2007 @@ -60,7 +60,7 @@ set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xalan-2.7.0.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\serializer-2.7.0.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\batik-all-1.6.jar -set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xmlgraphics-commons-1.1.jar +set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xmlgraphics-commons-1.2svn.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\avalon-framework-4.2.0.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\commons-io-1.1.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\commons-logging-1.0.4.jar
FW: svn commit: r515217 - in /xmlgraphics/fop/trunk/src/documenta tion/content/xdocs: ./ conf/ dav/ db/ db/revprops/ db/revs/ db/transactio ns/ hooks/ locks/
Jay, I am confused by this and your following check-in. These look like SVN control files and not actual sources. Manuel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, 7 March 2007 02:18 To: fop-commits@xmlgraphics.apache.org Subject: svn commit: r515217 - in /xmlgraphics/fop/trunk/src/documentation/content/xdocs: ./ conf/ dav/ db/ db/revprops/ db/revs/ db/transactions/ hooks/ locks/ Author: jbryant Date: Tue Mar 6 09:18:24 2007 New Revision: 515217
DO NOT REPLY [Bug 41778] - [PATCH] fop.bat is broken due to old xmlgraphics-commons jar file reference
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=41778. 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=41778 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2007-03-07 02:34 --- Hi Adrian, thanks for reporting the problem. Fixed in revision 515520. -- 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: Position, Leaf/NonLeafPosition, wrapping positions
On Mar 7, 2007, at 09:07, Vincent Hennebert wrote: Hi Vincent, I have some questions regarding the handling of Position elements. I'm not familiar with that part of the code yet, and as there is little or no javadoc for those it's a bit difficult to guess their purposes just by looking at the code. I think you're not the only one with this problem... :/ Note that there is also an illustrious resetPosition() method, which currently seems to be used nowhere. All references to it seem to be circular. BlockLayoutManager.resetPosition() is only called by AbstractLayoutManager.reset(), which in turn is only called by one of the other LM's resetPosition(), etc. The closest understanding that I have of those Positions is still a bit limited, I'm afraid, so I'm hoping others chime in to correct my mistakes or offer further clarification. (Just noticed that Luca already did; will share my thoughts in any case, to see if I may have misinterpreted something) Anyway, AFAIU, a Position can be viewed as a kind of a pointer to a position within the FObj. The significance is roughly: - when the initial element list is constructed, each generated ListElement receives a Position - after the breaking is done, and the areas get added, the Position is used to get to the 'part' of the FO that corresponds to that particular ListElement (and the right AreaInfos) Auxiliary elements get null as a Position, since they generally do not correspond to anything in the FO source. They are only added to 'steer' the breaking-algorithm in a certain direction. Each break possibility can be said to correspond to such a Position. In the addAreas() phase, IIC, the set of chosen break-points will be presented as a List of Positions which are then iterated over (see: PositionIterator, which is passed to addAreas()) Perhaps this is easiest to follow by means of an example: When the TextLM creates the base element list, each Position it generates and associates with one of its ListElements --a LeafPosition in this case-- will correspond roughly to an index in the character array... Actually, that's an index into the List of AreaInfos, and those ultimately point to an index in the char array. The AreaInfos correspond to words or fragments of hyphenated words. The line-layout algorithm relies solely on the generated ListElements, and does not deal with the Positions in the content directly, nor with the AreaInfos. Preserved linefeeds, for example, are 'translated' into separate KnuthInlineSequences by the TextLM. All the LineLayoutManager gets to see (collectInlineKnuthElements()) is a one-element sequence containing nothing but a penalty (forced break), which it interprets as a signal to end the current Paragraph, adding only an auxiliary glue to generate an empty line if the Paragraph contains nothing but the forced break. Come to think of it, maybe this is a bad example, precisely because no Position corresponds to the linefeed. :/ There is no AreaInfo, the index is simply skipped. (see: TextLM.getNextKnuthElements() line 709) Anyway, as far as I get the picture, the whole breaking-algorithm operates entirely upon the ListElements, and ultimately translates the set of chosen break-possibilities (= positions in the element lists) into a List of Positions (associated to the ListElements), and this latter list serves as base list for the PositionIterator that is passed to addAreas(). What's the purpose of a LeafPosition? Of a NonLeafPosition? IIC, then the key difference between them is that a LeafPosition will have no sub-positions. They only have a position-index within a NonLeafPosition. If that clarifies anything...? What's the purpose of the wrapPositionElements method in BlockStackingLayoutManager? Subsidiary question: why would one sometimes force the wrapping, sometimes not? Judging from the code, in general this only has effects if the calling LM is not the LM that is associated with a given ListElement. The only exception seems to be ListItemLayoutManager, which forces wrapping regardless of the base LM. The purpose seems to be to create auxiliary Positions, such that an element associated with a LeafPosition from one LM's point of view, can be transformed into one that is associated with a NonLeafPosition without losing the original Positions' info. That is all: as far as I get it... Cheers, Andreas
Re: Position, Leaf/NonLeafPosition, wrapping positions
On 07.03.2007 15:28:37 Andreas L Delmelle wrote: On Mar 7, 2007, at 09:07, Vincent Hennebert wrote: Hi Vincent, I have some questions regarding the handling of Position elements. I'm not familiar with that part of the code yet, and as there is little or no javadoc for those it's a bit difficult to guess their purposes just by looking at the code. I think you're not the only one with this problem... :/ Note that there is also an illustrious resetPosition() method, which currently seems to be used nowhere. All references to it seem to be circular. BlockLayoutManager.resetPosition() is only called by AbstractLayoutManager.reset(), which in turn is only called by one of the other LM's resetPosition(), etc. That's a left-over from the Keiron's and Karen's first approach before we introduced Knuth's algorithm. The resetting was used to go back to a certain position after deciding line/page breaks. When I merged in Luca's Knuth code I mostly removed most of this resetting because I thought we wouldn't need it anymore. Turns out I could have been wrong (changing available IPD topic). But maybe it's also good I didn't remove everything so we still know that there was such a mechanism. At some point we obviously have to resurrect it (if we need it again) or to remove it for good. The closest understanding that I have of those Positions is still a bit limited, I'm afraid, so I'm hoping others chime in to correct my mistakes or offer further clarification. (Just noticed that Luca already did; will share my thoughts in any case, to see if I may have misinterpreted something) snip/ That is all: as far as I get it... Oh, I think you pretty much got it. Jeremias Maerki
Re: fop.bat needs patching
Grr, I actually changed it but forgot to commit. Thanks for handling it. On 07.03.2007 10:42:38 Adrian Cumiskey wrote: This is a quicky.. Our fop.bat is currently broken, someone needs to update fop.bat to reflect the recently added new xmlgraphics-commons-1.2svn.jar on the trunk. I have added this patch to the patch list (http://issues.apache.org/bugzilla/show_bug.cgi?id=41778). --- fop.bat Wed Mar 07 09:32:31 2007 +++ fop.bat.orig Wed Mar 07 09:31:50 2007 @@ -60,7 +60,7 @@ set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xalan-2.7.0.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\serializer-2.7.0.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\batik-all-1.6.jar -set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xmlgraphics-commons-1.1.jar +set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\xmlgraphics-commons-1.2svn.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\avalon-framework-4.2.0.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\commons-io-1.1.jar set LOCALCLASSPATH=%LOCALCLASSPATH%;%LIBDIR%\commons-logging-1.0.4.jar Jeremias Maerki
Re: svn commit: r515217 - in /xmlgraphics/fop/trunk/src/documenta tion/content/xdocs: ./ conf/ dav/ db/ db/revprops/ db/revs/ db/transactio ns/ hooks/ locks/
I've reverted the two strange revisions. I wonder what happened. On 07.03.2007 10:44:11 Manuel Mall wrote: Jay, I am confused by this and your following check-in. These look like SVN control files and not actual sources. Manuel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, 7 March 2007 02:18 To: fop-commits@xmlgraphics.apache.org Subject: svn commit: r515217 - in /xmlgraphics/fop/trunk/src/documentation/content/xdocs: ./ conf/ dav/ db/ db/revprops/ db/revs/ db/transactions/ hooks/ locks/ Author: jbryant Date: Tue Mar 6 09:18:24 2007 New Revision: 515217 Jeremias Maerki
Re: svn commit: r515217 - in /xmlgraphics/fop/trunk/src/documenta tion/content/xdocs: ./ conf/ dav/ db/ db/revprops/ db/revs/ db/transactio ns/ hooks/ locks/
Jeremias Maerki wrote: I've reverted the two strange revisions. I wonder what happened. Jay's password hash is still in one of the commit mails, now irrevocably spread all over the mail archives of the world. I recommend changing the svn password immediately. J.Pietschmann
Re: fop.bat needs patching
On Wed, Mar 07, 2007 at 03:58:18PM +0100, Jeremias Maerki wrote: Grr, I actually changed it but forgot to commit. Thanks for handling it. On 07.03.2007 10:42:38 Adrian Cumiskey wrote: This is a quicky.. Our fop.bat is currently broken, someone needs to update fop.bat to reflect the recently added new xmlgraphics-commons-1.2svn.jar on the trunk. I have added this patch to the patch list (http://issues.apache.org/bugzilla/show_bug.cgi?id=41778). Keep it broken, so people are going to use the cmd or js startup scripts. Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: fop.bat needs patching
On Mar 7, 2007, at 22:49, Simon Pepping wrote: On Wed, Mar 07, 2007 at 03:58:18PM +0100, Jeremias Maerki wrote: Grr, I actually changed it but forgot to commit. Thanks for handling it. On 07.03.2007 10:42:38 Adrian Cumiskey wrote: This is a quicky.. Our fop.bat is currently broken, someone needs to update fop.bat to reflect the recently added new xmlgraphics-commons-1.2svn.jar on the trunk. I have added this patch to the patch list (http://issues.apache.org/bugzilla/show_bug.cgi? id=41778). Keep it broken, so people are going to use the cmd or js startup scripts. :-) Seriously: Is it possible/feasible/desirable to change the .bat file to use one of the cmd or js startup scripts maybe? Or promote their usage in other ways? Has their usage info already been added to the docs? Cheers, Andreas
Re: [2007/02/11] fop.bat needs patching
Andreas L Delmelle wrote: On Mar 7, 2007, at 22:49, Simon Pepping wrote: On Wed, Mar 07, 2007 at 03:58:18PM +0100, Jeremias Maerki wrote: Grr, I actually changed it but forgot to commit. Thanks for handling it. On 07.03.2007 10:42:38 Adrian Cumiskey wrote: This is a quicky.. Our fop.bat is currently broken, someone needs to update fop.bat to reflect the recently added new xmlgraphics-commons-1.2svn.jar on the trunk. I have added this patch to the patch list (http://issues.apache.org/bugzilla/show_bug.cgi? id=41778). Keep it broken, so people are going to use the cmd or js startup scripts. :-) Seriously: Is it possible/feasible/desirable to change the .bat file to use one of the cmd or js startup scripts maybe? Or promote their usage in other ways? Has their usage info already been added to the docs? Cheers, Andreas Well, consider this. I know what a .bat file is; I know how to use one. I don't know what a cmd or a js startup script is. If I need to modify the .bat file, I can read it, understand it, and use it without looking something up online. A lot of Windows users who would be interested in FOP are in pretty much the same boat. So what would be gained from using a relatively obscure script format rather than a .bat file? -- View this message in context: http://www.nabble.com/fop.bat-needs-patching-tf3361048.html#a9366292 Sent from the FOP - Dev mailing list archive at Nabble.com.
