DO NOT REPLY [Bug 51935] FOP does not properly handle the xsl:attribute name=keep-with-next.within-pagealways/xsl:attribute option
https://issues.apache.org/bugzilla/show_bug.cgi?id=51935 --- Comment #5 from Alberto Perri ape...@operamail.com 2011-10-29 08:17:36 UTC --- Created attachment 27864 -- https://issues.apache.org/bugzilla/attachment.cgi?id=27864 keep-with-next-problem.zip containing files to examine keep-with-next problem Hi Glenn, i have created a new project to run tests against the keep-with-next.within-page=always property on an FO object. The XSL-FO for the project is included in the keep-with-next-problem.zip called mytest.fo. To help narrow down the fo:block keep-with-next.within-page=always.../fo:block where i believe there is a problem i have extracted from the mytest.fo file, with my limited knowledge about Appache FOP, as well as i could two places where the problem occurs. These blocks i have saved to the files keep-with-next-problem1.fo and keep-with-next-problem1.fo. These files are also included in the keep-with-next-problem.zip file. In mytest.pdf file the keep-with-next problem can be viewed in two locations. The first location 1.1. MySubstaion SLD Diagram. The second location is where 2.1.1. Bay: Bay1. In both places you will see that the section heading is segregated from its image. According to the Keeps and Breaks Properties in the W3C XSL-FO 1.1 standard compliance table my understanding of the keep-with-next property is that it supposed to keep both the section heading and image together providing that the implemented block-level FOs are not inline-level FOs or integer specified. I have run my tests with the keep-together property and this does not seem to be the case. To get a real sense of how the keep-with-next and keep-together i have run my tests against RenderX XEP (Vrsn: xep-4.19-20110414) XSL-FO and sure enough both the section heading and image together are keep together. Despite the fact that you have created a wonderful template where i can insert the problematic blocks to be run against the keep-with-next.within-page=always test case I am not experienced enough to know how to do this yet, and if so doing whether or not i am doing it right to determine whether indeed there is a problem. Please let me know if the information and files i have included in this report is sufficient for you to examine this matter. Regards, Alberto Perri -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51935] FOP does not properly handle the xsl:attribute name=keep-with-next.within-pagealways/xsl:attribute option
https://issues.apache.org/bugzilla/show_bug.cgi?id=51935 --- Comment #6 from Alberto Perri ape...@operamail.com 2011-10-29 08:20:44 UTC --- For additional comments see keep-with-next-problem.zip containing files to examine keep-with-next problem Details -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 51935] FOP does not properly handle the xsl:attribute name=keep-with-next.within-pagealways/xsl:attribute option
https://issues.apache.org/bugzilla/show_bug.cgi?id=51935 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|NEEDINFO|NEW -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Merge branch Temp_ComplexScripts into trunk
Ideally, the merge is performed in subversion. Earlier I noted that that gives a large number of document and tree conflicts. I do not have time to resolve them. If no team member picks this task up, a patch from Glenn is a good alternative solution. Glenn, can you attach it to the Bugzilla report? Can you indicate how you proceeded, and how you guarantee that the patch has the same result as a merge in Subversion? Simon Pepping On Sat, Oct 29, 2011 at 09:02:42AM +0800, Glenn Adams wrote: Let me know how I may most expeditiously accomplish this work. In the mean time, I will prepare a patch against trunk from the Temp_CS branch, which I imagine Simon will be the one to apply. G.
