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/
Manuel Mall wrote: On Wed, 4 Jan 2006 03:51 am, Andreas L Delmelle wrote: Sorry to interject into this debate, but I have to say that I agree with Manuel and thought I'd better speak up as this debate doesn't appear to be making any progress. Thanks for trying to improve this important area of the code Andreas, I don't want to appear ungrateful for your efforts, it's just I have similar concerns to Manuel. To sum it up: Our implementation of Donald Knuth's algorithm first creates the element lists for the FOs, and then from those lists it calculates the most favorable break-positions. Subsequently, it adds the areas based on those breaks to the block-area, right? Now, what I mean: If the element-lists for the trailing spaces(*) are modeled appropriately, and we add a forced break (infinite penalty) for the end-of-block, then the algorithm will always create one final pseudo- line-break(**) where those spaces are dissolved if present, just as they would be when it were the first line. The generated pseudo-line (s) will have no content at all. Maybe a minor tweak needed in LineArea to return zero BPD when it has no child-areas, and there we go... In Block.addChildArea, we can then test for zero-BPD line-areas to keep them from effectively being added to the block. Something like that? Or am I still missing important implications? I think the important point is that the Knuth algorithm cannot be made to strip trailing spaces. Only by placing hacky code around the algorithm can this effect been achieved. Code which from my perspective has caused a lot of bugs and unwanted side effects. Bugs which Jeremias and Manuel seem to be constantly fixing in this area. So I think leading and trailing space removal should be kept in the refinement (FO Tree) stage for this reason. Also, as Manuel pointed out, the Knuth algorithm does not handle cross LM space removal. Something which can be achieved more easily in the FO Tree. snip/ Chris
Markers and relative font-sizes
It appears that while the rebinding and evaluation of properties for the children of markers is generally working the feature is broken for the font-size property. This is most likely because font-size is receiving some special treatment in the property system. I have added a test case to demonstrate the problem. Manuel
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/
That proves the point that I shouldn't meddle in things I don't fully understand, yet, and don't have enough time to really get to know. Lesson learnt. On 04.01.2006 13:10:42 Manuel Mall wrote: snip/ 1. The patch is not solving the whitespace handling problem for markers which was one of its initial drivers. We can blame Jeremias here - just to drag in another innocent party :-) - as he suggested factoring out the fo:block specific whitespace refinement so it can be applied to markers. Unfortunately that was a bad idea. snip/ Jeremias Maerki
[PMC:VOTE] Add AFP Renderer to FOP
In November, Manuel proposed [1] to add the AFP Renderer [2] from Pete Townsend and Joe Schmetzer to FOP's sandbox in the Trunk. We already have 5 +1s (3 were PMC members: Chris, Clay, Jeremias), but judging from recent discussions inside the incubator I think we should have a formal PMC vote on this. I'm still watching for Pete's and Joe's ICLAs to come in but something seems to have gone wrong there. Once these two things are done we can follow down the process described at [3]. Manuel is working to port the AFP renderer to FOP Trunk in order to prepare it for the import. Votes from the rest of the PMC members to general@, please. Thanks! [1] http://www.nabble.com/AFP-Renderer-for-FOP-t637253.html [2] http://afp-renderer.sourceforge.net/ [3] http://incubator.apache.org/ip-clearance/index.html Jeremias Maerki
DO NOT REPLY [Bug 38102] - Overflow of output in region-body if there is space-after.optimum
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=38102. 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=38102 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2006-01-04 17:00 --- Bug fixed: http://svn.apache.org/viewcvs?rev=365928view=rev But this only fixes this particular problem with fo:block. I will need to check all the other FOs, too. The problem was that BlockLayoutManager did not promote the space adjust value to its child layout managers via the LayoutContext. If you specify the space-before using only a space-before.optimum, the space may shrink to 0pt if necessary (.minimum is 0pt by default). In your example, the page breaker tried to make the space smaller to make a better page break decision, but the code that generates the areas did not properly respect the breaker's decision. -- 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 38121] New: - border-separation disturbs table layout
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=38121. 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=38121 Summary: border-separation disturbs table layout Product: Fop Version: 0.91 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] When the table property border-separation.b-p-d is greater than 0: 1. the table header is not layed out if the table overflows the first page; 2. in Awt renderer, the vertical space between 2 cells seems to be ignored. -- 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 38121] - border-separation disturbs table layout
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=38121. 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=38121 --- Additional Comments From [EMAIL PROTECTED] 2006-01-04 17:29 --- Created an attachment (id=17323) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17323action=view) This fo file should demonstrate described bug -- 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-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.
DO NOT REPLY [Bug 38102] - Overflow of output in region-body if there is space-after.optimum
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=38102. 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=38102 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-01-04 18:55 --- Wow ... that was really fast :-) I've recompiled FOP from SVN an it works. Now I better understand the handling of space-after.optimum. The text This text should be on the next page in the sample is of course not correct. Thank you. -- 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.
Using fo:marker and fo:retrieve-marker
Hi All! I am having an enormous problematic time trying to get fo:marker and fo:retrieve-marker to work correctly in some tables that continued to a second page. I have reviewed several examples and it still doesnt click. Maybe too much holiday time off! The (Continued) text is displaying on the first occurrence of the table title as well as the second. It should only be displayed on the second occurrence. I have included the XSL snippet below. I really appreciate any help in you can offer. Thanks in advance for your help! S.E. fo:flow flow-name=xsl-region-body font-family=Arial fo:block fo:marker marker-class-name=cont fo:inline(Continued)/fo:inline /fo:marker /fo:block ... /fo:flow fo:table-and-caption space-before=2em fo:table table-layout=fixed width=100% fo:table-header fo:table-row fo:table-cell border-style=solid border-width=1.5pt border-bottom=1.5pt border-left=1.5pt border-right=1.5pt padding-top=1pt padding-bottom=1pt font-size=24pt text-align=center number-columns-spanned=7 fo:block font-weight=bold xsl:value-of select=title/ /fo:block!--Section 4 Title -- fo:block line-height=0pt fo:retrieve-marker retrieve-position=last-starting-within-page retrieve-class-name=cont/ /fo:block /fo:table-cell /fo:table-row /fo:table-header ... /fo:table __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
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 `-
Re: Markers and relative font-sizes
On Jan 4, 2006, at 14:34, Manuel Mall wrote: It appears that while the rebinding and evaluation of properties for the children of markers is generally working the feature is broken for the font-size property. This is most likely because font-size is receiving some special treatment in the property system. I have added a test case to demonstrate the problem. Yep, nasty one! As a clarification: 'some special treatment' means 'font-size is the very first attribute that is converted into a Property' Following the trail: PropertyList.addAttributesToList() - PropertyList.convertAttributeToProperty() - PropertyMaker.make() ... IOW, the relative 'em' is converted into an absolute 'mpt', and the conversion is unconditionally based on FObj.findNearestAncestorFObj (). Further on, the property is only stored as a Length (in CommonFont), whose getValue() always returns the converted value in 'mpt'. As to how to solve this... I'll need to investigate a bit further. Maybe anyone else immediately sees it...? Cheers, Andreas
Re: DO NOT REPLY [Bug 38087] - [patch] force-page-count property implementation
On Wed, Jan 04, 2006 at 02:08:56PM +0100, gerhard oettl wrote: --- Additional Comments From [EMAIL PROTECTED] 2006-01-03 22:23 --- I am not quite happy with the fact that checkForcePageCount is called by the next page sequence. This is an interaction between page sequences, and it is better dealt with by the controlling structure, in this case AreaTreeHandler. In other words, I go with your suggestion in the second *. I had better orderd the open questions - so think them numbered: - 1) - 2) * 2a) * 2b) * 2c) ad 1) If there is no precedence for one of the choices i will change previousPageSeqLM from public to private as proposed in the question. Agreed. ad 2) I think it is the second - what you call the second * ? Because i couldn't think it a good idea to preserve the PageSequenceLayoutManger at layoutmanger level and call it from area level, so i think i shall do the changes 2a, 2b and 2c alltogether. 2c is a must anyway. 2b is the second *. I agree with your proposal to do all three changes 2a-c. There is a little error in the last page sequence but one in your demo file. It says that next is auto-even, which is not true. yes If of any importance i can add a corrected fo to show the possibility of missing pagenumbers in case of force-page-count=no-force. Let me know. 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. .''`. gerhard oettl on Debian/Gnu Linux That's the best, as soon as I find out how to make my mike work. :-) Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
DO NOT REPLY [Bug 38087] - [patch] force-page-count property implementation
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=38087. 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=38087 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #17303|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2006-01-04 23:59 --- Created an attachment (id=17329) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17329action=view) patch 2 (using area tree) ad the now 2c) At the time the checkForcePageCount is called from the AreaTreeHandler the initialPageNumber is already calced by the PageSequence without knowing about eventueally later added pages so it must be recalced. I did this by making the initPageNumber method public. If this should stay private i have to add a public recalcInitPageNumber method that does nothing than call the private initPageNumber method - at your decision. -- 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: 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 4, 2006, at 13:10, Manuel Mall wrote: snip / I am not quite sure what to recommend from here. May be along the following lines: 1. Leave the current status quo including leave Andreas patch in the system. At least it covers the most common scenario - whitespace should be removed for markers. Although it does it in the wrong place but we don't have anything better yet. 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). 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. Thanks Andreas, I'll be happy this with course of action. Cheers, Andreas Manuel
