Re: [docbook-apps] programlisting page breaks

[maxwell <maxwell@umiacs.umd.edu>]

On Tue, 15 Mar 2011 07:30:42 -0500, David Cramer <david@thingbag.net>
wrote:
> On 03/15/2011 04:08 AM, Dave Pawson wrote:
>> I have both long and short programlistings? 3 to 100 lines and more.
>> I think it rather judgemental to assume all docbook users
>> only have one or the other?
>
> I agree completely. If we put keep-together="always" on example, then 
> we're saying "examples must never span more than one page". 

FWIW, the same problem comes up with tables (and perhaps other things). My
team is actually using another tool chain, dblatex --> XeTeX --> PDF, but
most of the parameters that dblatex uses are the same as the parameters
that the FO tool chain uses.  In particular, you can elect at the document
level when you run dblatex whether tables should float or extend over
multiple pages.  We have documents where some tables need to do one, and
some the other.  While we could use a processing instruction, we have
instead (mis-)used the table@floatstyle attribute, together with some
locally munged xslt code, to set individual tables to "long" or "float"
(with the default still determined at the document level by the parameter
when the XML document is converted).

I guess an issue with using an attribute like this is that it's really
only valid for paginated output (most PDFs), and then only if you don't
change the paper size or even the font size.  IMO, issues like this should
really be left to the discretion of the processor, which (presumably) knows
what the final page size will be (or if there will not even be pages, e.g.
an HTML output).  But today's processors (even LaTeX) aren't smart enough
for that.

A similar issue concerns table widths.  By default, tables usually extend
the width of the page or the column, but this can be overridden in several
ways (by explicitly setting colspec@colwidth in centimeters or inches, by
using the table@width attr, or by a processing instruction). But if we were
producing HTML output on the fly, and the user happened to have a browser
set very wide, 50% might not be appropriate, nor would a setting in terms
of inches or centimeters be appropriate (since it's impossible to know what
the user's physical screen width is).  I suppose a setting in terms of
number of characters might be reasonable (assuming that the table doesn't
contain a bunch of 'W's or '.'s, I guess).

And another issue is the table@orient parameter, which is needed for
output which may be printed, but might be considered irrelevant for HTML
output (where the screen can be scrolled).

I guess it's for these reasons that some of these settings can be
determined by processor instructions.  But processor instructions of course
make for maintenance and archivability problems...

   Mike Maxwell