DO NOT REPLY [Bug 46160] Automatic breaking of long landscape elements (tables) across multiple pages
https://issues.apache.org/bugzilla/show_bug.cgi?id=46160 taffy-tyler6...@hotmail.co.uk changed: What|Removed |Added CC||taffy-tyler6...@hotmail.co. ||uk -- 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 46160] Automatic breaking of long landscape elements (tables) across multiple pages
https://issues.apache.org/bugzilla/show_bug.cgi?id=46160 Jens Stanstrup j...@nw3.dk changed: What|Removed |Added CC||j...@nw3.dk -- 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 46160] Automatic breaking of long landscape elements (tables) across multiple pages
https://issues.apache.org/bugzilla/show_bug.cgi?id=46160 --- Comment #9 from Vincent Hennebert vhenneb...@gmail.com 2009-05-18 04:18:22 PST --- Hi, (In reply to comment #8) Created an attachment (id=23363) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=23363) [details] Landscape table example Sorry for the delay in getting an example out to you. Attached is an archive containing, DocBook XML source, fo and Apache FOP PDF output for a landscape table example. LandscapeTableExampleWanted.xml.pdf is an example of the type of output I would like to be able to generate. Thanks for the simple example. I've been reading and re-reading the specification for a while and can't find any reason why the rotated block shouldn't be broken over pages. Compared to a 'normal' (non-rotated) block-container, the only additional restriction that applies to a rotated block is that the inline-progression-dimension be specified, which is the case in the sample file. (And that restriction doesn't even look necessary to me, if it were left to 'auto' the ipd could simply be set to the remaining space on the page —but this is another topic.) There is this 'overflow' property, but I don't think it applies here. After all, it doesn't prevent non-rotated blocks from being broken over pages by the layout engine, so I don't see why it should be the case for rotated ones. Actually, I think it /should/ prevent page breaking in /both/ cases, if it is left to its default value of 'auto' (which for a print format can reasonably be re-interpreted into 'visible'). Only when its value is set to 'repeat' would page breaking be allowed. But this is not what any of the formatters I've tried does, and adopting this strict behaviour is likely to puzzle many users anyway. So, I think no extension is necessary at all in this case. The rotated block should simply be broken once it reaches the right margin. This is what XSL Formatter does once the keep-together is reset to auto in the sample file. I would re-qualify this feature request into a bug. That means that its status will be changed from It's not likely to be implemented any time soon to It's likely to be fixed at some point... In practice that doesn't change much about an expectable date for the fix. However, this is an issue that we can keep in mind while working on the new layout engine. Vincent -- 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 46160] Automatic breaking of long landscape elements (tables) across multiple pages
https://issues.apache.org/bugzilla/show_bug.cgi?id=46160 --- Comment #7 from Andreas L. Delmelle adelme...@apache.org 2009-03-09 11:06:32 PST --- (In reply to comment #6) Testing some combinations, I've just noticed a small error in FOP Trunk: reference-orientation is treated as an inherited property, while it most certainly is not. Since a lot of tests seem to be depending on it, it may take a while to fix this, although, purely codewise, it's only a matter of changing a boolean switch in FOPropertyMapping... :-/ I'm currently looking closer into this one, and it seems the related checks in the tests are entirely correct (mainly simple-page-master_reference-orientation_*). Only, somehow the erroneous inheritance of the property has been taken into account when creating the region-viewport/region-reference area pair. Currently, in Page.makeRegionViewport(), an absolute rectangle is created (in page-coordinates) for the viewport-area. When setting the region-reference-area position, however, the 'width/ipd' that is obtained from this absolute rectangle should actually be the 'height/bpd' of the region-reference-area. What happens is that the absolute rectangle takes into account the reference-orientation specified on the simple-page-master. When creating the reference-area, though, we use the same pageCTM, but with the region's reference-orientation (which is 0, meaning no rotation with respect to the viewport). -- 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 46160] Automatic breaking of long landscape elements (tables) across multiple pages
https://issues.apache.org/bugzilla/show_bug.cgi?id=46160 --- Comment #8 from Paul paul.suckl...@gmail.com 2009-03-09 17:19:28 PST --- Created an attachment (id=23363) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=23363) Landscape table example Sorry for the delay in getting an example out to you. Attached is an archive containing, DocBook XML source, fo and Apache FOP PDF output for a landscape table example. LandscapeTableExampleWanted.xml.pdf is an example of the type of output I would like to be able to generate. Paul -- 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 46160] Automatic breaking of long landscape elements (tables) across multiple pages
https://issues.apache.org/bugzilla/show_bug.cgi?id=46160 --- Comment #5 from Vincent Hennebert vhenneb...@gmail.com 2009-03-03 03:29:56 PST --- (In reply to comment #4) Is the solution really that difficult? Portrait-mode tables already break fairly well at page boundaries. It's the landscape ones that don't. It actually depends on how landscape tables are implemented by the DocBook XSLT stylesheets. I believe they use an fo:block-container with a reference-orientation of 90 or -90, in which case I don't even know what the behaviour is supposed to be. But we can always try to have a look. Paul, would you mind attaching a small DocBook document illustrating your request, /and/ the XSL-FO file resulting from the transformation by the DocBook XSLT stylesheets? Thanks, Vincent -- 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 46160] Automatic breaking of long landscape elements (tables) across multiple pages
https://issues.apache.org/bugzilla/show_bug.cgi?id=46160 --- Comment #6 from Andreas L. Delmelle adelme...@apache.org 2009-03-03 14:38:20 PST --- (In reply to comment #5) It actually depends on how landscape tables are implemented by the DocBook XSLT stylesheets. I believe they use an fo:block-container with a reference-orientation of 90 or -90, in which case I don't even know what the behaviour is supposed to be. But we can always try to have a look. A rotated block-container (+/-90) with auto-width/-height and a nested table = the block-container's height/bpd will be equal to the table's height/bpd, but since the block-container is also rotated WRT the page/region-body, we only get possible situations of overflow in inline-progression-direction. Either the block-container's content is too large to fit in the available width --example: table inline-progression-dimension=200%-- or the block-container grows too high --due to added table-rows-- thus exceeding the page width. The governing overflow and clip properties determine what happens with the content exceeding the reference-area boundaries. Once you specify explicit dimensions on the block-container, IIC FOP interprets this to be an unbreakable piece of content. Testing some combinations, I've just noticed a small error in FOP Trunk: reference-orientation is treated as an inherited property, while it most certainly is not. Since a lot of tests seem to be depending on it, it may take a while to fix this, although, purely codewise, it's only a matter of changing a boolean switch in FOPropertyMapping... :-/ -- 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 46160] Automatic breaking of long landscape elements (tables) across multiple pages
https://issues.apache.org/bugzilla/show_bug.cgi?id=46160 --- Comment #4 from Darrell Nelson darrell.nel...@dmiindustries.com 2009-02-05 13:48:54 PST --- Is the solution really that difficult? Portrait-mode tables already break fairly well at page boundaries. It's the landscape ones that don't. -- 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 46160] Automatic breaking of long landscape elements (tables) across multiple pages
https://issues.apache.org/bugzilla/show_bug.cgi?id=46160 --- Comment #3 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-11-23 03:15:25 PST --- I don't mean to get your hopes up, but it seems like in the future, we may not even need an extension... see: http://www.w3.org/TR/2008/WD-xslfo20-req-20080326/#N66228 -- 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 46160] Automatic breaking of long landscape elements (tables) across multiple pages
https://issues.apache.org/bugzilla/show_bug.cgi?id=46160 Paul [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #2 from Paul [EMAIL PROTECTED] 2008-11-07 04:32:31 PST --- Thanks for the feedback about time scales Vincent. I appreciate that there is a lot of much higher priority work on the FOP to-do list, and that it would be a very tricky request to implement. I just thought I'd register the request for the record. Cheers. -- 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 46160] Automatic breaking of long landscape elements (tables) across multiple pages
https://issues.apache.org/bugzilla/show_bug.cgi?id=46160 --- Comment #1 from Vincent Hennebert [EMAIL PROTECTED] 2008-11-07 03:41:56 PST --- Hi, Thanks for taking the time of creating a bug report. However, I must say that you shouldn't expect this feature to be implemented any time soon. It's not trivial and I don't think anybody among the active developers has enough interest to work on this. Moreover, FOP doesn't implement the whole XSL-FO spec yet, so before working on extensions... Vincent -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
