--- Comment #9 from Vincent Hennebert <vhenneb...@gmail.com> 2009-05-18
04:18:22 PST ---
(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
> 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.
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.