Re: svn commit: r360083 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ test/layoutengine/standard-testcases/
Andreas L Delmelle wrote: On Jan 4, 2006, at 13:10, Manuel Mall wrote: snip/ Ouch! This was one thing I indeed completely lost track of: the properties governing white-space-treatment and the like for the corresponding retrieve-marker... To add to all the fun, there is indeed no way at all to solve this during refinement stage in a generic way, taking into account alternating static-contents (page- break context is needed for this). This is a tricky problem to solve. snip/ To be on the safe side, it seems better if I revert at least partly. I think extracting the handleWhiteSpace() method into a separate class is still a good idea, even if only to avoid code-duplication and to have all the related logic together in one spot --no need to blame Jeremias for this thought :-) Combine this with the previous approach using the RecursiveCharIterators. I haven't removed much of that code anyway, didn't even rename the classes just yet, while they are currently never used recursively (=only deal with FOText and Characters). Agreed I see a remote possibility to exclude the markers whose class-name corresponds to at least one retrieve-marker that has an ancestor with non-default white-space-treatment/-collapse. If no such retrieve- marker exists, the white-space can be collapsed during refinement. All possible retrieve-markers in a page-sequence will, in any case, always be available at the point where a given marker is processed (and through them, also their ancestor-block's white-space related props). I'll see what I can do about this ASAP, although I'm not sure whether this will gain us much. The FOs are readily available, but they need to be reached all the same. Now I'm not sure I follow your thinking here. How will you find retrieve-markers from a marker FO when retrieve-boundary=document ??? Chris
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: xsl-functions on doc compliance
gerhard oettl wrote: I always found the compliance page of the documentation a excelent help when to decide who is to blame: fop or me. What i am missing is the status of the xsl-funtions [from-parent(), etc]. If there is no objection i'll try to create a patch against xdocs/compliance.ihtml to append them. Good idea. A patch will be welcome ;) Chris
FOP 0.90.1 Gaps (Was Re: xsl-functions on doc compliance)
This page does clearly document the two biggest remaining gaps in 0.90.1: table Basic 6.7.3 partial partial [0.91 beta] Only border-collapse="separate" is supported and there's no support for automatic column widths. and (a smaller, but significant gap): text-align Basic 7.15.9 partial partial Only start, end, center and justify are supported text-align-last Extended 7.15.10 partial partial Only start, end, center and justify are supported [The gap being the lack of the string option for text alignment to attain alignment to a decimal separation character.] -- Jess Holle gerhard oettl wrote: I always found the compliance page of the documentation a excelent help when to decide who is to blame: fop or me. What i am missing is the status of the xsl-funtions [from-parent(), etc]. If there is no objection i'll try to create a patch against xdocs/compliance.ihtml to append them. gerhard
DO NOT REPLY [Bug 38135] New: - [PATCH] Support for data urls (rfc 2397)
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=38135. 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=38135 Summary: [PATCH] Support for data urls (rfc 2397) Product: Fop Version: 1.0dev Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: images AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] Adds support for inline images in the form of base64 encoded data urls. This is particularly useful for displaying FO files generated from Word docs. Requires commons-codec. For details of word to fo conversion see: http://www.microsoft.com/downloads/details.aspx?FamilyId=E0FAA0AF-A185-4296-B74D-A9FE870C92CCdisplaylang=en For details of the data url scheme see: http://www.ietf.org/rfc/rfc2397 -- 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 38135] - [PATCH] Support for data urls (rfc 2397)
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=38135. 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=38135 --- Additional Comments From [EMAIL PROTECTED] 2006-01-05 14:07 --- Richard, thanks for the patch. I'd prefer not to add a dependency on a whole new library for just one class. Would you mind rewriting your patch to use Batik's org.apache.batik.util.Base64DecodeStream? I'll gladly apply your patch then. Some time ago I also posted a generic solution to this problem, found here: http://marc.theaimsgroup.com/?l=fop-userm=110875657902117w=2 (Just for completeness) We might switch to Batik's ParsedURL infrastructure in the future which automatically gives us RFC2397 support, but your solution will certainly help in the meantime. -- 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: xsl-functions on doc compliance
On Thu, Jan 05, 2006 at 11:47:51AM +, Chris Bowditch wrote: gerhard oettl wrote: If there is no objection i'll try to create a patch against xdocs/compliance.ihtml to append them. Good idea. A patch will be welcome ;) Ok i'll start the work. BTW is there a conformance level available for them? Are they all basic? As far as i can see the rec only speaks about objects and properties and most of the functions can be use for many properties so it is not possible to inherit from there. 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: svn commit: r360083 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ test/layoutengine/standard-testcases/
On Jan 5, 2006, at 18:48, Andreas L Delmelle wrote: snip / To summarize this thread (it has taken long enough :-)) I thought it over a bit more, and what I'm currently working on (and will most likely finish during the weekend) is the following: 1) Basically keep the algorithm the way I recently altered it, but containing some additional processing for trailing inline FOs that end with a sequence of white-space. Determining this last bit is easy enough, since it just means that XMLWhiteSpaceHandler.inWhiteSpace will be false after handleWhiteSpace(). At the end of the block, we will do one more pass over all those trailing inlines, if any. IMO, in the vast majority of use-cases there will be either zero, one or at most two of those, but theoretically this could be any number... If there are any, then if white-space-collapse has the default value of true there will be only one trailing white-space character left at that point, so this additional bit of processing will cost virtually nothing. 2) Simplify the CharIterator structure, in the sense that we'll still only need an iterator over FOText and Characters. Unless layout needs access to the iterators, I think charIterator() can be pushed down to be specific to FObjMixed, and then the overrides of this method can be removed from all other FOs apart from FOText and Character. For 1), it could turn out handy if I add the possibility to iterate backwards until the last non-white-space is encountered... 3) Exclude markers (and their descendants) from white-space handling during refinement, for the mentioned reasons: * retrieve-marker's ancestor's white-space properties govern the treatment in this case * possibly page-break context is needed when dealing with alternating static-contents * retrieve-markers with retrieve-boundary=document 3) of course means the recently enabled marker_bug.xml testcase will have to be disabled again until we find a way to tackle this in layout. I had thought of using XMLWhiteSpaceHandler itself for this, but the tricky part is that, once a Marker (and its descendants) have been white-space-treated, the stripped white-space is permanently gone, and since that same Marker can again be retrieved in a different context etc. [end-of-thread, I hope ;-)] 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
Re: [patch] force-page-count property implementation
On Thu, Jan 05, 2006 at 12:19:26PM +0100, gerhard oettl wrote: It would be good if you could turn it into a test file for the layoutengine tests, which highlights all relevant combinations of force-page-count and initial-page-number. Otherwise I will do it. If have idea how which xslt paths to use for testing, but if you could lead me by sending me one (or two) examples with the first page-sequences of my current (not automated) testfile (may be via PM or so that i check it out with the next svn up and point me to the file) i'll do the rest. I will send you some tests, tomorrow or over the weekend. Simon -- Simon Pepping home page: http://www.leverkruid.nl
