Subject: [Xml-sg-cmt] Ugly pdf hack

From: "John R Levine" <[email-masked]>
Date: 28 Feb 2022 16:02:19 -0500

I tried adding

<t><br/><t>

above the sourcecode and it did indeed make the headers stack up on one 
page as you might hope.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "John R Levine" <[email-masked]>
Date: 28 Feb 2022 16:16:39 -0500

It occurs to me that it looks good enough that when rendering a PDF 
xml2rfc could stick the equivalent of an empty text block in front of 
sourcecode or artwork if it's the first thing in a section.

Kludgefully,
John

> I tried adding
>
> <t><br/><t>
>
> above the sourcecode and it did indeed make the headers stack up on one page 
> as you might hope.
>
> Regards,

Regards,

---

From: Alice Russo <[email-masked]>
Date: Mon, 28 Feb 2022 13:37:14 -0800

Hi John,

>> <t><br/><t>

Right; it also works with simply empty <t/>. To confirm, do you consider that acceptable to include in the published XML?  

i.e., one extraneous <t/> in XML for the sake of avoiding several blank pages in the PDF.  (Note: this does not get rid of *all* the mostly blank pages in this PDF.)

Thanks,
Alice

> On Feb 28, 2022, at 1:16 PM, John R Levine <[email-masked]> wrote:
> 
> It occurs to me that it looks good enough that when rendering a PDF xml2rfc could stick the equivalent of an empty text block in front of sourcecode or artwork if it's the first thing in a section.
> 
> Kludgefully,
> John
> 
>> I tried adding
>> 
>> <t><br/><t>
>> 
>> above the sourcecode and it did indeed make the headers stack up on one page as you might hope.
>> 
>> Regards,
> -- 
> Xml-sg-cmt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml-sg-cmt
>

---

From: Sandy Ginoza <[email-masked]>
Date: Mon, 28 Feb 2022 14:40:22 -0800

Hi John,

My take away from the call today was it’s worth trying to avoid the bad page breaks in this case.  Your reply here would be helpful in that it determines when the doc can be published today or whether it moves to March (so we can discuss potentially adding text with the authors).

Thanks,
Sandy 

> On Feb 28, 2022, at 1:37 PM, Alice Russo <[email-masked]> wrote:
> 
> Hi John,
> 
> Re:
>>> <t><br/><t>
>

---

From: "John R Levine" <[email-masked]>
Date: 28 Feb 2022 17:45:02 -0500

> My take away from the call today was it’s worth trying to avoid the bad page breaks in this case.  Your reply here would be helpful in that it determines when the doc can be published today or whet…

My preference would be to fix xml2rfc to put in pretend <t/> when 
rendering PDF, both so we don't have to mess with the XML, and so it'll do 
a better job rerendering previous RFCs.  Can we see how long that would 
take to do?

Also, when I put in those <t> elements, xml2rfc complained that they 
were missing "pn" from the prep tool.  Did you have that too?

---

From: Alice Russo <[email-masked]>
Date: Mon, 28 Feb 2022 16:06:35 -0800

Hi John,

> On Feb 28, 2022, at 2:45 PM, John R Levine <[email-masked]> wrote:
> 
> My preference would be to fix xml2rfc to put in pretend <t/> when rendering PDF, both so we don't have to mess with the XML, and so it'll do a better job rerendering previous RFCs.  Can we see how long that would take to do?

Do you want to create a ticket so Kesara can take a look?

Also, a ticket would mean there's something to point the authors to, if the decision is to hold this document pending that change to PDF rendering.

> 
> Also, when I put in those <t> elements, xml2rfc complained that they were missing "pn" from the prep tool.  Did you have that too?

Did not see any warning. That is, when changed to <t/> there was no warning when running xml2rfc 3.12.2 to render each of the 3 outputs, or simply with --prep option.

FWIW, <t/> became <t indent="0" pn="section-appendix.a.1.1.1-1"/> in the prepped file.

Thanks,
Alice

---

From: Kesara Rathnayake <[email-masked]>
Date: Tue, 1 Mar 2022 14:30:28 +1300

On 1/03/22 11:45 am, John R Levine wrote:
>> My take away from the call today was it’s worth trying to avoid the 
>> bad page breaks in this case.  Your reply here would be helpful in 
>> that it determines when the doc can be published today or whether it 
>> moves to March (so we can discuss potentially adding text with the 
>> authors).
> 
> rendering PDF, both so we don't have to mess with the XML, and so it'll 
> do a better job rerendering previous RFCs.  Can we see how long that 
> would take to do?
PDF renderer and HTML renderer use the same code to generate HTML.
Because of that adding `<t/>` just for PDF is an issue.

These page breaks happen because CSS rules stop `sourcecode` from breaking.
When `sourcecode` is large enough, render chooses to use the whole page 
for `sourcecode`.

Another way to fix this form xml2rfc is:

Option 1. Remove CSS rule that avoid inside breaks for `sourcecode`.

Option 2. xml2rfc can add a class that allows `sourcecode` to break 
inside when `sourcecode` is larger than 80 lines or so.

Option 3. Schema change. We can introduce a new attribute to 
`sourcecode` element to tell it's okay to break inside. So xml2rfc can 
use a different class for that.

   --Kesara
>>> Right; it also works with simply empty <t/>. To confirm, do you 
>>> consider that acceptable to include in the published XML?
>>>
>>> i.e., one extraneous <t/> in XML for the sake of avoiding several 
>>> blank pages in the PDF.  (Note: this does not get rid of *all* the 
>>> mostly blank pages in this PDF.)
>>>
>>> Thanks,
>>> Alice
>>>
>>>> xml2rfc could stick the equivalent of an empty text block in front 
>>>> of sourcecode or artwork if it's the first thing in a section.
>>>>
>>>> Kludgefully,
>>>> John
>>>>
>>>>> I tried adding
>>>>>
>>>>> <t><br/><t>
>>>>>

-- 
Kesara Rathnayake
Senior Software Development Engineer - IETF LLC
[email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 28 Feb 2022 20:40:57 -0500

On Tue, 1 Mar 2022, Kesara Rathnayake wrote:
> When `sourcecode` is large enough, render chooses to use the whole page for 
> `sourcecode`.
>
> Option 2. xml2rfc can add a class that allows `sourcecode` to break inside 
> when `sourcecode` is larger than 80 lines or so.
>
> Option 3. Schema change. We can introduce a new attribute to `sourcecode` 
> element to tell it's okay to break inside. So xml2rfc can use a different 
> class for that.

If option 2 isn't too hard that seems like a reasonable thing to try.  Not 
sure 80 lines is the right number, but we can try some experiments.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 28 Feb 2022 21:07:24 -0500

> Do you want to create a ticket so Kesara can take a look?

It's issue #739

Regards,

---

From: Sandy Ginoza <[email-masked]>
Date: Mon, 28 Feb 2022 21:47:42 -0800

Hi John,

Ok, it sounds like we should move RFC 9189 to TI (tooling issue) state and notify the authors of the status of their document.  

Thanks,
Sandy 

> On Feb 28, 2022, at 6:07 PM, John R Levine <[email-masked]> wrote:
>