[rfc-i] use cases for page breaking hints, Re: Update on the plain text thread(s)

Julian Reschke julian.reschke at gmx.de
Fri Jun 27 06:29:30 PDT 2014


On 2014-06-27 15:18, Dearlove, Christopher (UK) wrote:
> Agreed, keep together is not always the right answer. Although if human inserted, the human might have a clue. The question then is how much you trust that the human will have only used it sensibly?
>
> The (incomplete) algorithm I indicated partly covers that. It doesn't allow the text to move onto the next page if that then messes up the table. What it (and I think nothing) can handle is the "if you do this here to avoid a slight nasty, ten pages later something nastier happens". Rare, but possible. (I once deleted some text from Word and the document got longer - that was, IIRC, down to turning a four line paragraph, split 2+2, into a 3 line paragraph, which to avoid a widow or an orphan split 0+3. Then the extra line rippled forwards to eventually causing an extra page of several lines.)
>
> If the table breaks (and at the least, that will happen if it's more than a page long)  a heading rows repeat feature is good. Assuming we can flag what is the heading (maybe just <ttcol> elements?). And ideally, also disallow some breaks in table (which could be done by putting keep on a <c>, for example, or a structure above <c>).

Table header logic has been implemented in rfc2629.xslt since back when 
<texttable> was introduced. It would be really awesome if we could 
switch from a theoretic discussion to actual testing and bug reporting 
of the HTML we already can produce.

I'm pretty sure there's is room for improvement, but these improvements 
will only happen if people review what's there and try it.

> ...

Best regards, Julian


More information about the rfc-interest mailing list