🇬🇧 / 🇫🇷 Need some help with WeasyPrint? You’re in the right place to ask :)
Flight of the Scions. The first three of my books are on my website and Creative Commons: Sand and Blood, Sand and Ash, and Sand and Bone. https://fedran.com/sand-and-blood/
Also, all of the books at https://typewriter.press/ are formatted with WeasyPrint and the cause of every issue I've reported for years. 😄
Naturally, nothing I write is in Python, so I'm forking, but WeasyPrint works very well with Nix so it works out.
I'm forking out an
exec to call WeasyPrint...
Plus I use a lot of tkpdf to handle splicing together the chapter pages since it isn't easy to do a "first page" in the middle of a block. So this system (mfgames-writing) basically creates each chapter as a separate PDF and then merges them together to handle the pre-first-chapter headers and footers and then pulling everything together.
Well... a little more complicated than that, but it still produces the best PDFs for what I'm doing. 🙂
You can try to play with named pages, maybe it’s possible to get what you want in pure CSS (but if it works with tkpdf, there’s no need to change anything 😊)
Hi Team, I have run into an odd problem (possibly a bug in WeasyPrint but not enough evidence yet to make a call). Over the last few months we have moved up from Python 3.7 - Python 3.9, Django 3.2 to 4.0, WeasyPrint 52 to 55 (and then last night to try test if it was a known fixed bug to 56.1) however the templates have remained the same. The PDF's built by WeasyPrint 52 (Py3.7, Django 3.2) print fine (showing generated by Cairo 1.16.0 and PDF version 1.5) all through the path (windows network print server and Ricoh copiers) and the PDF's built by WeasyPrint 55 (and 56.1) (Py3.9, Django 4.0) appear to print successfully at every stage however the print log on the Ricoh Copiers say that it successfully printed 0 pages of the document (windows print server log shows it detected it was a one page document to print not 0 pages) (showing generated by WeasyPrint 55.0 / 56.1 and PDF version 1.7). No error is generated by any devices in the chain including the copier at the end. The files do print fine if "print as image" selected (so I am suspecting something is in there that triggers a problem in the RIP on the copier causing it to not generate a page from the data received however again only a suspicion not confirmed yet) It happens with two different templates however they both contain SVG images linked to them and their designs, while different, were done by the same employee but at different times so there will be commonalities. Two main questions, is anyone aware of a known incompatibility or place to start exploring deeper that is more likely to be the area to try get a simply reproducible example? and has anyone experienced anything similar in the past with a printer that wouldn't throw an error but would "successfully" print no pages?
3 replies
Salut @liZe ! Qu’est-ce que tu penses de transférer le dépôt css-parsing-tests vers github.com/CourtBouillon ?
Hello @/all ! As it’s soon our 2-year anniversary as CourtBouillon, we launched a survey to know about you and your expectations https://thym.courtbouillon.org/1. It’s opened until October 10th :)
Hey folks, not an issue I don't think so won't raise it yet.
I'm having some fun where for some reason the HTML preview of my pages seems like the origin is off compared to the PDF output from Weasyprint.
If the PDF origin for example is 0,0 - I'm seeing the PDF origin in the HTML preview as something like -50,-50. It's like I have to shift up and left in HTML to get to the top left corner in weasyprint PDF...
Is there something obvious I could be doing wrong? It makes designing pages difficult as I have stuff missing in the HTML preview that lines up fine in the resulting PDF :')
There are page margins, that’s why there’s an empty space between your content and the edges of the page
If you don’t want to use them, you can remove them with
@page { margin: 0 } in your CSS
That could be fun
You can only keep the bottom margin for example, if it’s easier for you
(If you remove the right margin, you’ll have to use
@bottom-right instead of @bottom-right-corner)
Good shout, merci!
Btw, I don’t if you’ve seen it, we launched a survey about WeasyPrint just here https://thym.courtbouillon.org/1 :)
Weasyprint was one of the few actual open source licensed libraries we could find
And I was very glad to go back to python to use it rather than the java day job :')
Me again with another question :sweat_smile:
We have table rows with inner tables :grimacing: and on the html preview, I get:
the above*
On the PDF, it doesn't seem to respect the spacing
I would expect the columns in the latter image to both take 50% of the right hand column of the main table