Re: [Xml-sg-cmt] WeasyPrint Update

[Sandy Ginoza <[e-mail]>]

Hi all,

I looked at a handful of random PDFs.  Note that I did not compare these side by side with the published RFCs, but I did spot check if I wanted to see how something was handled with the earlier version of weasyprint.  I was under the impression we were going to accept that formatting changes will occur as weasyprint is updated, so I mostly just scanned the newer files for oddities.  

1) page break between toc header and the toc contents; seemingly bc content fits on one page or two pages perfectly (diff from pub version); looks odd.  
https://devbox.amsl.com/weasyprint55/rfc8650.pdf
https://devbox.amsl.com/weasyprint55/rfc8670.pdf
https://devbox.amsl.com/weasyprint55/rfc8681.pdf


2) made me wonder about table breaks; should a table be kept together when it can?  Afaik, no change from current handling.  Example: Table 4 is ugly, but I also imagine it could be just as ugly to try to force a table onto one page, so maybe no change.
https://devbox.amsl.com/weasyprint55/rfc8651.pdf 


3) table on p10 —> seemingly breaks header from content (not broken in pub version)
https://devbox.amsl.com/weasyprint55/rfc8670.pdf


4) blank p15 (pub version has blank p14)
https://devbox.amsl.com/weasyprint55/rfc8681.pdf 


5) OK; nothing stood out as better or worse
https://devbox.amsl.com/weasyprint55/rfc8706.pdf
https://devbox.amsl.com/weasyprint55/rfc8740.pdf
https://devbox.amsl.com/weasyprint55/rfc8790.pdf
https://devbox.amsl.com/weasyprint55/rfc9000.pdf


Thanks,
Sandy 



> On Jun 30, 2022, at 3:19 PM, Alice Russo <[e-mail]> wrote:
> 
> Hi Robert,
> 
> Re:
>> I'm not sure we can do a real comparison without running these through the pdfaPilot step, which essentially rewrites the pdf.
>> 
>> Alice - is it easy to script running all the things at [3] through pdfaPilot? If not, could you run 8779 through (as that's the semi-random one I chose to look at first).
> 
> Posted here: https://www.rfc-editor.org/v3test/test8779.pdf
> 
> The command used was:
> pdfaPilot --collection --embedinto=A3u,rfc8779wp55.pdf --embedfile=No,Source,rfc8779.xml --outputfile=test8779.pdf
> (where rfc8779wp55.pdf is https://devbox.amsl.com/weasyprint55/rfc8779.pdf)
> 
> They look the same to me, as expected (more below on that topic). The PDF diff tool draftable shows only one change repeatedly (apparently a draftable bug; it's tripping on the characters 'fi'): https://draftable.com/compare/IAdOLoZDctSw
> 
> Perhaps more relevant is comparing rfc8779.pdf (as published) vs. rfc8779wp55.pdf:
> https://draftable.com/compare/PRHdkYkTIoHP
> (My take is nothing egregious there. Differences to page breaking expected; it's unfortunate that a one-line <t> preceding <artwork> no longer stays on the page with the artwork -- pages 11/12 and 13/14. FWIW, the source XML does not contain keepWithNext; the published rendering was good without 'forcing' it.)
> 
> Re:
>> On Jun 29, 2022, at 2:48 PM, Kesara Rathnayake <[e-mail]> wrote:
>> 
>>>> I'm not sure we can do a real comparison without running these through the pdfaPilot step, which essentially rewrites the pdf.
>>> It's not likely to change the appearance unless the PDF is depending on fonts other than the standard ones or ones included in the PDF which would be a bug.  PDF/A mostly fills in defaults and divides some internal data structures into smaller chunks.
> 
> I agree re: "not likely to change the appearance". At the time of the format change, we were told (and have found  during limited visual checks) that there are no changes to appearance after running pdfaPilot.  For each RFC, the PDF from before running pdfaPilot is archived internally; can post if needed.
> 
> 
> That said, to Kesara's point about looking at PDFs of more recent RFCs (produced by WeasyPrint 52.5), I'll do some comparing of a few recent ones vs. files in [3] and report back.
> 
> Thanks,
> Alice
> 
>> 
>> I'm already seeing the differences in figure/table layout that can affect where pagebreaks lie.
>> 
>> Most of the other differences I see are in indentation, spacing between paragraphs, etc - makes me wonder if the css is being honored as intended. These add up over pages to change the overall length of the document in pages (though the pagebreak algorithm change makes that unavoidable). Again, I'm curious to see if these go away when run through pdfaPilot.
>> 
>> 
>> On 6/28/22 8:28 PM, Kesara Rathnayake wrote:
>>> Hi all,
>>> 
>>> I have draft PR [1] for the WeasyPrint update.
>>> This updates WeasyPrint from 52.5 to 55.0.
>>> Since WeasyPrint 53.0, they have moved the PDF generation from cairo to pypdf [2].
>>> I have generated PDFs from RFC 8650 to RFC 9260 [3].
>>> 
>>> There are some differences from my random checks.
>>> 
>>> Let me know your thoughts.
>>> 
>>> Note that these PDFs haven't gone through the pdfaPilot step to convert to PDF/A-3 with the XML source file embedded.
>>> 
>>> [1] https://github.com/ietf-tools/xml2rfc/pull/802
>>> [2] https://github.com/CourtBouillon/pydyf
>>> [3] https://devbox.amsl.com/weasyprint55/
>>> 
>>> Cheers,
>>> Kesara
>> 
>> -- 
>> Xml-sg-cmt mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/xml-sg-cmt
>> 
> 
> -- 
> Xml-sg-cmt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xml-sg-cmt