Re: [Xml-sg-cmt] Odd table breaks (odd breaks within a row)

[Kesara Rathnayake <[e-mail]>]

Current behaviour on xml2rfc is correct because, according to CSS 
specification, default values for `orphans` and `widows` attributes are 
2 lines [1, 2].
`orphans` and `widows` values determined the number of lines that must 
be shown on the bottom and top of a page.

One of the suggestions from WeasyPrint developers is to set these values 
to 1 [3].

I have attached the rendered PDFs with these values set to 1.
I think this creates more issues. For example, see "Table 14" in RFC9053.

Cheers,
Kesara

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/orphans
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/widows
[3] https://github.com/Kozea/WeasyPrint/issues/1712#issuecomment-1227147155

On 25/08/22 4:54 pm, Kesara Rathnayake wrote:
> Hi Sandy,
> 
> I have a CSS fix by explicitly avoiding making any page breaks inside 
> rows [1].
> 
> I have attached two PDF renderings that I generated for RFC9053 & RFC9054.
> 
> Note on RFC9053, Table 10's first row doesn't break anymore, so this 
> avoids the original issue on Table 16.
> 
> Change is apparent on RFC9054.
> 
> Cheers,
> Kesara
> 
> [1] https://github.com/ietf-tools/xml2rfc/pull/879/files
> 
> On 25/08/22 2:47 pm, Kesara Rathnayake wrote:
>> Hi Sandy,
>>
>> This is an issue on WeasyPrint.
>> I've already created a bug report [1].
>> I'll investigate if there's anything that can be done on xml2rfc to 
>> avoid this issue.
>>
>> [1] https://github.com/Kozea/WeasyPrint/issues/1712
>>
>> Cheers,
>> Kesara
>>
>> On 25/08/22 9:31 am, Sandy Ginoza wrote:
>>> Hi all,
>>>
>>> While prepping 2 docs for pub, we noticed a couple of odd table 
>>> breaks in RFCs-to-be 9053 and 9054.  Some info within a row appears 
>>> on one page, and some info in the same row appears on the next page.  
>>> Please see:
>>>
>>> https://www.rfc-editor.org/authors/rfc9053.pdf
>>> Table 16 on pages 26-27
>>>
>>> https://www.rfc-editor.org/authors/rfc9054.pdf
>>> Table 2 on pages 6 and 7
>>>
>>> Is this something that can be fixed?  Is there some workaround here? 
>>> I imagine we’ll see this with some frequency.
>>>
>>> FYI: These are Jim Schaad’s last documents (afaik).  There is *some* 
>>> urgency to get these docs published in that they have been stuck in 
>>> AUTH48 for over a year and were released for pub last week at the 
>>> urging/override of the AD.  They have been delaying publication of 
>>> another cluster for some time.
>>>
>>> Thanks!
>>> Sandy
>>
> 
> 

-- 
Kesara Rathnayake
Senior Software Development Engineer - IETF LLC
[e-mail]