[rfc-i] widowing controls [was: will <vspace=n> disappear]

Brian E Carpenter brian.e.carpenter at gmail.com
Thu Oct 16 20:43:34 PDT 2014


On 17/10/2014 09:52, Joe Touch wrote:
> 
> On 10/16/2014 1:40 PM, Julian Reschke wrote:
>> On 2014-10-16 22:30, Joe Touch wrote:
>>>
>>> On 10/16/2014 12:39 PM, Brian E Carpenter wrote:
>>> ...
>>>> (I agree that in the new regime we can't have an explicit page
>>>> break. I do wonder whether we don't need something explicit to
>>>> help the widow/orphan logic in some cases.)
>>> There are many cases where it's useful to control such things:
>>>
>>>     - tables (either render it in a single screen/page or
>>>     control where it breaks)
>> So you want to add a hint about what is a good point to break a table?
> 
> Not so much where to break as where NOT to break:
> 
> 	item		break before?	break after?

I can actually see two things I might want to say. They would
both be hints to the rendering algorithm.

<please-do-not-break-if-possible>
important stuff that should be kept together if possible
</please-do-not-break-if-possible>

and

<if-you-must-break-do-it-here/>

    Brian

> 
> 	header		yes		no
> first 2 items		no		yes
> middle items		yes		yes
> last 2 items		no		after last item
> 
> However, it might be useful to control that, for the same reason as with
> hierarchical lists. If you have a table with items that are grouped, you
> might want the same "keep with previous" or "keep with next" identifier
> that is currently useful for paragraphs and lists (though those don't
> appear to be in V3, I use them all the time in modern word processors)
> 
>>>     - lists, especially hierarchical ones
>>>         (it's preferable to break only before toplevel items)
>> I think that rule could be automated, right?
> 
> It could, but it's useful to have user ability to override.
> 
> Joe
> .
> 


More information about the rfc-interest mailing list