DO NOT REPLY [Bug 40230] New: - Invalid extra page break creates an undesired empty page
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=40230. 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=40230 Summary: Invalid extra page break creates an undesired empty page Product: Fop Version: 1.0dev Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] When there is an fo:block break-after=page/ and nothing after it in the flow, a new page is still created, whereas section 7.19.1 of the recommendation states that it should be the case only if there is material to typeset afterwards. See the attached fo sample. The result is the same if we replace break-after by break-before. Same result also if we remove the indenting such that all the closing tags after the block are sticked together, so this is not a whitespace handling issue. I guess that a Knuth penalty of value -infinity is generated for such a block, and this doesn't play well with the (infinite glue, -infinite penalty) pair which is probably added at the end of the page sequence. The penalty should probably be only generated if there is also some box after it, and before the ending pair. If nobody takes this bug I'll have a look at it after the GSoC. -- 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 40230] - Invalid extra page break creates an undesired empty page
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=40230. 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=40230 --- Additional Comments From [EMAIL PROTECTED] 2006-08-11 08:10 --- Created an attachment (id=18697) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18697action=view) Sample file demonstrating the problem -- 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: [Xmlgraphics-fop Wiki] Update of GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats by VincentHennebert
2006/8/11, Apache Wiki: Dear Wiki user, You have subscribed to a wiki page or wiki category on Xmlgraphics-fop Wiki for change notification. The following page has been changed by VincentHennebert: http://wiki.apache.org/xmlgraphics-fop/GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats The comment on the change is: Difficulties around side-floats Ok guys, I've been searching for 3 days for a simple, elegant, powerful, effective, ligthweight solution to make the total-fit algorithm work with side-floats, but can't seem to find one. This issue is somewhat related to the one regarding differing available ipd in page sequences (solving one might help solve the other one, at least). There is also some similarity with tables, i.e., how to combine several vertical Knuth element lists into just one. Excepted that in the case of side-floats, we may choose several completely different solutions to place them. And this is a case-by-case decision: one time this will be better to differ the float, one other time to break it, one other time to compress it... In some situations, a best-fit approach could even produce better results, as we would have the possibility to consider the differing of a side-float. But it is well-known that best-fit may be much worse than total-fit regarding before-floats and footnote placements. Looking at how tables are handled might give me some ideas for side-floats, but this would require some time and there isn't much left now. I also have some ideas for improving the handling of before-floats and footnotes, and I'd like to implement them while I have time and it's still fresh in my memory. The implementation I propose on the Wiki page has its limitations but should work in most cases. This might give a basis for further improvements. I'm thinking about making a poll on fop-user to know what are their expectations regarding side-floats, and which usage they would make of them. This might help make some design decisions. Well, in one word, I'm a bit lost as for what to do, now. WDYT? Vincent
Re: [GSoC] Auto-table layout questions
Patrick, your ICLA hasn't shown up, yet. The last batch of ICLAs was committed 2006-07-31 so if you sent it after that date, it may show up in the next batch which I hope will be soon. Have you made any progress on your side? Everything working out? On 07.08.2006 02:58:57 Patrick Paul wrote: Jeremias Maerki wrote: BTW, Patrick, when I checked the ICLA status of you and Vincent I saw that you still don't have an ICLA on file with the ASF. Please sign and send (i.e. fax) one to the ASF secretary: http://www.apache.org/licenses/#clas Thanks. Jeremias Maerki Hi Jeremias, I've been offline most of the time this past week. I have faxed my ICLA a few days ago, so I'm hoping it is on file with the ASF by now. Please let me know if its not. Thank you, Patrick Jeremias Maerki
Re: [Xmlgraphics-fop Wiki] Update of GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats by VincentHennebert
On 11.08.2006 13:26:51 Vincent Hennebert wrote: 2006/8/11, Apache Wiki: Dear Wiki user, You have subscribed to a wiki page or wiki category on Xmlgraphics-fop Wiki for change notification. The following page has been changed by VincentHennebert: http://wiki.apache.org/xmlgraphics-fop/GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats The comment on the change is: Difficulties around side-floats Ok guys, I've been searching for 3 days for a simple, elegant, powerful, effective, ligthweight solution to make the total-fit algorithm work with side-floats, but can't seem to find one. This issue is somewhat related to the one regarding differing available ipd in page sequences (solving one might help solve the other one, at least). There is also some similarity with tables, i.e., how to combine several vertical Knuth element lists into just one. Excepted that in the case of side-floats, we may choose several completely different solutions to place them. And this is a case-by-case decision: one time this will be better to differ the float, one other time to break it, one other time to compress it... In some situations, a best-fit approach could even produce better results, as we would have the possibility to consider the differing of a side-float. But it is well-known that best-fit may be much worse than total-fit regarding before-floats and footnote placements. Are you sure that it's much worse? Note that even TeX uses best-fit for page breaking. Looking at how tables are handled might give me some ideas for side-floats, but this would require some time and there isn't much left now. I also have some ideas for improving the handling of before-floats and footnotes, and I'd like to implement them while I have time and it's still fresh in my memory. The implementation I propose on the Wiki page has its limitations but should work in most cases. This might give a basis for further improvements. I'm thinking about making a poll on fop-user to know what are their expectations regarding side-floats, and which usage they would make of them. This might help make some design decisions. That should certainly provide some interesting feedback. Well, in one word, I'm a bit lost as for what to do, now. Hmm, yeah, it's a bit difficult. Best-fit vs. total-fit plays into this. Best-fit will most likely replace total-fit because of the additional features we can cover. If that means some drawbacks on things like footnote placement that could be acceptable if the drawbacks are not too great. ATM, I cannot estimate the impact of the change. Too bad we don't have much theoretical reference material on using the Knuth approach on page breaking. Most of what exists today around page breaking is by M.F. Plass or worked out by us on our Wiki. I would not consider it a bad move if you concentrated the rest of your time of the GSoC on the before-floats and footnotes, especially if it's unlikely that you can finish side-floats in time and if the switch from total-fit to best-fit hangs in the air. Even without an actual implementation the groundwork for a side-float implementation in form of some very good documentation is a very satisfying result. I would consider the goals of the GSoC project met. It might be good to add some best-fit-specific comments, though. How does that sound? Jeremias Maerki
Re: widows and orphans on lists and tables
Such an entry point sounds quite difficult to me. I'm not sure if we'd be able to come up with anything worthwhile. We'd also need a use case or two. I can't think of any right now. What can be done is to replace a LM with a different implementation. However, I don't know of anyone who has done that, yet. In the case at hand, I think this can simply be handled in our own LMs as optional, non-standard hints for FOP. I don't know how I would implement this feature using some plug-in of a sort. But if anyone has some cool ideas, I'm all ears... On 10.08.2006 21:09:31 Andreas L Delmelle wrote: On Aug 10, 2006, at 17:47, Jeremias Maerki wrote: snip / I could imagine properties like orphan-height and widow-height on fo:table and fo:list-block for that purpose. That indeed sounds like a job for extension properties. I have always wondered what would need to be done to implement an arbitrary extension property that has an impact on layout... IIC, there has been talk, way back when, about setting parameters for the Knuth algorithm through extension properties. AFAICT, the foreign attribute is handled when the FO tree is built. If the namespace is registered as non-ignorable, then it is added to the FObj, and fully accessible. The framework is in place. Of course, we are at liberty to implement the use of those foreign attributes *in* the current table/list LMs, but what would someone have to do if he/she wants to make it a literal extension...? Do we already provide an 'entry point' into the layout API that any code related to extension properties can use? If not, then this seems like a perfect opportunity to think about how it should look like. Cheers, Andreas Jeremias Maerki
[EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project xml-fop-maintenance has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 9 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop-maintenance : XSL-FO (Formatting Objects) processor (Maintenance branch) Full details are available at: http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [fop.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes] -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/gump_work/build_xml-fop-maintenance_xml-fop-maintenance.html Work Name: build_xml-fop-maintenance_xml-fop-maintenance (Type: Build) Work ended in a state of : Failed Elapsed: 41 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only gump [Working Directory: /usr/local/gump/public/workspace/xml-fop-maintenance] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-gvt.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-11082006.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-11082006.jar - [style] Processing /x1/gump/public/workspace/xml-fop-maintenance/build/src/codegen/Times-Italic.xml to /x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts/TimesItalic.java [style] Loading stylesheet /x1/gump/public/workspace/xml-fop-maintenance/build/src/codegen/font-file.xsl [style] Warning: the task name style is deprecated. Use xslt instead. [style] Processing /x1/gump/public/workspace/xml-fop-maintenance/build/src/codegen/Times-Bold.xml to /x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts/TimesBold.java [style] Loading stylesheet /x1/gump/public/workspace/xml-fop-maintenance/build/src/codegen/font-file.xsl [style] Warning: the task name style is deprecated. Use xslt instead. [style] Processing
[EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project xml-fop-maintenance has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 9 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop-maintenance : XSL-FO (Formatting Objects) processor (Maintenance branch) Full details are available at: http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [fop.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes] -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/gump_work/build_xml-fop-maintenance_xml-fop-maintenance.html Work Name: build_xml-fop-maintenance_xml-fop-maintenance (Type: Build) Work ended in a state of : Failed Elapsed: 41 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only gump [Working Directory: /usr/local/gump/public/workspace/xml-fop-maintenance] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-11082006/lib/batik-gvt.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-11082006.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-11082006.jar - [style] Processing /x1/gump/public/workspace/xml-fop-maintenance/build/src/codegen/Times-Italic.xml to /x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts/TimesItalic.java [style] Loading stylesheet /x1/gump/public/workspace/xml-fop-maintenance/build/src/codegen/font-file.xsl [style] Warning: the task name style is deprecated. Use xslt instead. [style] Processing /x1/gump/public/workspace/xml-fop-maintenance/build/src/codegen/Times-Bold.xml to /x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts/TimesBold.java [style] Loading stylesheet /x1/gump/public/workspace/xml-fop-maintenance/build/src/codegen/font-file.xsl [style] Warning: the task name style is deprecated. Use xslt instead. [style] Processing
Re: Reconstructed FOP logo for high quality printing
Ok, the gradient bug is gone. Actually, the gradients were fine in the PDFTranscoder. Only when painted inside FO documents they were wrong. Same for links. I've been able to fix both: http://svn.apache.org/viewvc?rev=430777view=rev Now, there's a tiny detail I've just found: In the logo.jpg file (which is also used on our website), the feather lies under the O (of FOP), while in logo2.ai and logo2.svg the feather lies in the foreground. Looking closer at [1] it seems that the original FOP logo also contained a few more details. For example, the ink pot and the shadows seem much finer. Now, the problem is that Scott Hofmann's mail address bounces so I can't ask him for the original anymore. Does anyone know what the original by Tobias Müller looked like. Did he have the same inkpot already? [1] http://www.tkachenko.com/blog/archives/16.html On 04.08.2006 02:04:19 Web Maestro Clay wrote: On Aug 3, 2006, at 8:05 AM, Jeremias Maerki wrote: On 03.08.2006 16:51:20 Web Maestro Clay wrote: +1 from me... nice job. Thanks. (although I would prefer the issues ironed out...) Do you mean the not quite identical font or the gradient bug in PDFGraphics2D? The gradient bug... :-p Clay Leeds [EMAIL PROTECTED] My religion is simple. My religion is kindness. -- HH Dalai Lama of Tibet Jeremias Maerki
Re: [Xmlgraphics-fop Wiki] Update of GoogleSummerOfCode2006/FloatsImplementationProgress/ImplementingSideFloats by VincentHennebert
2006/8/11, Jeremias Maerki: snip/ In some situations, a best-fit approach could even produce better results, as we would have the possibility to consider the differing of a side-float. But it is well-known that best-fit may be much worse than total-fit regarding before-floats and footnote placements. Are you sure that it's much worse? Note that even TeX uses best-fit for page breaking. Oh yes I'm sure ;-) It's a common complaint from users of the LaTeX world that figures are placed in a weird manner. There are plenty of parameters to tweak the output by hand, but this doesn't always give satisfying results. And given that manual intervention isn't really an option in the FO world... Note also that TeX implemented best-fit for page-breaking only because of limited computation resources at that time (you know, those good old 80's). Looking at how tables are handled might give me some ideas for side-floats, but this would require some time and there isn't much left now. I also have some ideas for improving the handling of before-floats and footnotes, and I'd like to implement them while I have time and it's still fresh in my memory. The implementation I propose on the Wiki page has its limitations but should work in most cases. This might give a basis for further improvements. I'm thinking about making a poll on fop-user to know what are their expectations regarding side-floats, and which usage they would make of them. This might help make some design decisions. That should certainly provide some interesting feedback. Well, in one word, I'm a bit lost as for what to do, now. Hmm, yeah, it's a bit difficult. Best-fit vs. total-fit plays into this. Best-fit will most likely replace total-fit because of the additional features we can cover. If that means some drawbacks on things like footnote placement that could be acceptable if the drawbacks are not too great. ATM, I cannot estimate the impact of the change. Too bad we don't Well, to me switching to best-fit is out of the question. Total-fit is a killer feature for technical documents with lots of figures and footnotes (the current implementation is already better than Xep...). This would give Fop a big advantage over concurrent implementations. Rather, we might consider implementing both strategies. Ideally there would be an option in the config file ( optimize-for-books vs optimize-for-fancy-layouts or something like that). The generation of Knuth elements would be the same, only the breaking algorithm would differ. But abandoning total-fit is not an option, IMO. Moreover... have much theoretical reference material on using the Knuth approach on page breaking. Most of what exists today around page breaking is by M.F. Plass or worked out by us on our Wiki. ... I'm still hoping to find a solution compatible with the total-fit approach. The glue/box/penalty model is simply not powerful enough to represent tables, side-floats and the like. All we have to do is find another model... I would not consider it a bad move if you concentrated the rest of your time of the GSoC on the before-floats and footnotes, especially if it's unlikely that you can finish side-floats in time and if the switch from total-fit to best-fit hangs in the air. Even without an actual implementation the groundwork for a side-float implementation in form of some very good documentation is a very satisfying result. I would consider the goals of the GSoC project met. It might be good to add some best-fit-specific comments, though. Ok, will do. How does that sound? Well, now I know what to do ;-) I'll first work on footnotes and before-floats improvements. I'll also try to implement the simplified solution for side-floats. Depending on the results I'll write the suitable documentation. Thanks! Vincent
