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.
