DO NOT REPLY [Bug 41282] New: - FOP compliance page contains broken links
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=41282. 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=41282 Summary: FOP compliance page contains broken links Product: Fop Version: all Platform: All URL: http://xmlgraphics.apache.org/fop/compliance.html OS/Version: All Status: NEW Severity: minor Priority: P4 Component: documentation AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] The tables in the FOP compliance web page (http://xmlgraphics.apache.org/fop/compliance.html) contains contain links which are no longer valid and which lead to a W3C error page only. More precisely, the URLs http://www.w3.org/TR/xsl/slice5.htm, http://www.w3.org/TR/xsl/slice6.htm and http://www.w3.org/TR/xsl/slice7.htm don't exist any more. -- 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 41272] - Memory problem in 0.93
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=41272. 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=41272 --- Additional Comments From [EMAIL PROTECTED] 2007-01-03 07:34 --- (In reply to comment #0) I am currently having problem compiling a 420 page document, with about 50 figures. The problem sees to be memory related, however the debugging information is insufficient for me to identify the problem. Using th fop ant task, I get Exception in thread main java.lang.NoSuchMethodError: main When using the commandline tool, the a bit more infomation is released, such as WARNING: Line 1 of a paragraph overflows the available area. (fo:block, location: 4794/406) Exception in thread main java.lang.OutOfMemoryError Note, this document compiled just fine with FOP 0.20.5 It's normal, FOP 0.92 beta needs more memory because it cheks much more the XSL-FO format than the FOP 0.20.5 was doing. So just enables more memory to the JVM and it will be ok. It could also be that something is now detected as wrong because of the new test, but it wouldn't be this error message, I think. -- 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 41282] - FOP compliance page contains broken links
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=41282. 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=41282 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2007-01-03 07:39 --- I believe this is fixed now. Just needs a website synchronization to complete *** This bug has been marked as a duplicate of 41228 *** -- 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: Open issue: table-columns from first row?
On Jan 3, 2007, at 10:17, Vincent Hennebert wrote: Hi Vincent, snip / fo:table fo:table-body fo:table-cell width=2in number-columns-spanned=2 ... In this case, two implicit columns are created, but the cell's width is not yet distributed over the two columns. I'll add a testcase demonstrating what still goes wrong, but the issue probably needs to put in a slightly different wording, indicating that it works apart from the above reservation. I'm curious about your testcase, actually, because after quick testing I haven't been able to reproduce it (attached fo file, first table, works fine). I see two possibilities: Either the layoutengine fully compensates for this, or it just happens to go unnoticed since you have a specified absolute width of 7.5cm for the whole table. I think I'll put my money on the latter. Explanation: By the time layout starts, we'll actually have three table-columns, all with a default width of 'proportional-column-width(1)' (= FOP's proprietary default, as this is not mandated by the XSL-FO Rec; the Rec says the initial value is 'auto' which comes down to the same thing). Try setting the table's width to 10cm. If all would go as expected, we'd have to end up with two columns of 2.5cm and one of 5cm. FOP currently makes them all about 3.33cm, I think... In the meantime, I've locally patched FOP to correctly deal with this. Patch consists of a few changes in TableBody, TableRow and PercentLength. The latter only because I needed to have some way to be able to get the percentage value of the cell-width, divide it by the number of columns spanned, and construct a new PercentLength with the percentage distributed over the number of columns. Full patch below. No objection, some code was obviously lacking at that place, anyway (nothing done when colspan != 1). For absolute widths, it is not so much of a hassle to distribute the widths. When it came to the percentages, however, I began to slow down... It seems a pesky job to create correct relative-numerics: the percentages themselves are actually rather simple --percentage value of the original cell divided by the column-span. It's creating the LengthBase to go with it that I'm still struggling with (a percentage of what?) Not unsolvable, but a bit more work than that tiny patch I proposed at first. That made me think of the testcase showed in the second table in the attached file. There is a colspan on the first row, which sets the width of the first two columns. But we might want to refine that on the second row, by specifying a different width for each column individually. That testcase fails... WDYT? Interesting idea, BUT... One of the key intentions of the fixed table-layout algorithm is precisely that a formatter is able to determine the column-widths for the whole table based on the first row. Strictly speaking, the behaviour you describe --to take into account the second row as well-- would even violate the rules prescribed by CSS. In 17.5.2, it says: In the fixed table layout algorithm, the width of each column is determined as follows: 1) A column element with a value other than 'auto' for the 'width' property sets the width for that column. 2) Otherwise, a cell in the first row with a value other than 'auto' for the 'width' property sets the width for that column. If the cell spans more than one column, the width is divided over the columns. 3) Any remaining columns equally divide the remaining horizontal table space (minus borders or cell spacing). In your example, I'd say that following the Rec means ignoring any width attributes on cells that are not in the first row. The widths in the second row are not supposed to have any effect. Cheers, Andreas
DO NOT REPLY [Bug 41272] - Memory problem in 0.93
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=41272. 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=41272 --- Additional Comments From [EMAIL PROTECTED] 2007-01-03 12:02 --- (In reply to comment #2) I have constantly read statements, which claimed Trunk was able to process much larger documents, which I also interpreted as a much smaller memory food print. It's not that simple, I'm afraid... Although most reports we have received so far indeed indicate that 0.9x is generally faster and uses less resources, this greatly depends greatly on the structure of your FO document. The use of multiple, relatively small page-sequences is a key factor here. If a document is divided nicely into sequences of 10 pages maximum, then the total number of pages becomes irrelevant. We've had feedback from users processing 12000 paged documents without complaints (although the heap still grows to about 0.5GB). -- 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 41271] - PDF is not default mode for ant task fop in 0.93
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=41271. 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=41271 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2007-01-03 12:40 --- (In reply to comment #4) Also, a fix for the default format seems easy, so I committed it in revision 491926 to the trunk. If you can test it positively, I will add it to the branch as well. Done. The fix will be in release 0.93. -- 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.
[VOTE] Release of FOP 0.93
I have again prepared the release files for the FOP 0.93 release. They were created from the tag https://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-0_93. You can find them at http://people.apache.org/~spepping/. They are signed with the same PGP key as this message. You can find this key in the KEYS file in the distribution. The MD5 checksums are: 800d0a4e02e762179d9a424c187e4b3d fop-0.93-bin-jdk1.3.tar.gz 63838dad67cbd02614eca1919e797c79 fop-0.93-bin-jdk1.3.zip 69696c6ca0095e35719d9282db44fe48 fop-0.93-bin-jdk1.4.tar.gz 8c3d9726193fddd7e1edc81dcfc812d6 fop-0.93-bin-jdk1.4.zip 184c578a6269a8287ed150e0fc12868d fop-0.93-src.tar.gz 7cc7bfe0f452412a4f037fdf727ed69d fop-0.93-src.zip Herewith I start a vote on this release. The vote will end in 72 hours, that is, on Sunday 7 January 2007 at 0.00hrs UTC. If the vote passes the release files will be moved to the main Apache website, we will wait 24 hours for the mirrors to catch up, and then announcements will be sent to appropriate mailing lists. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.eu signature.asc Description: Digital signature
DO NOT REPLY [Bug 41272] - Memory problem in 0.93
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=41272. 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=41272 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2007-01-03 21:06 --- I am a longer list of documents and the way fop is used depends upon the memory requirements of the individual document. By default, I use the fop ant task, but when there are specific memory requirements that is not possible (since the ant task does not have a maxmemory attribute like the ant java task - IT SHOULD). For these documents, I instead use the ant task java class= maxmemory=200M ... In in 0.20.5 the class name was org.apache.fop.apps.Fop That does not work in 0.93, where one should use the class org.apache.fop.cli.Main That change in the API should be listed in docs/0.93/upgrading.html -- 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.
