Enable HTML header and footer
c4ffein opened this issue · 14 comments
I made a PR ( #34 ) to enable the addition of a html header and footer to all pages, taking most code from Weasyprint documentation.
I made the code work on my machine, did it for my own needs, but decided to share it in case it is helpful.
But now, there is a dependency error on the CI...
https://travis-ci.org/github/jmaupetit/md2pdf/jobs/706486615
I wanted to make a valid PR before asking for review, and I still didn't ask if that functionality is worthy or not, as I already wrote the code I preferred to share it directly. So :
Would you merge that PR? If yes, do you know what makes the CI fail (I don't know tox...)? Otherwise I can still try to fix it, but I'd prefer to do it after you tell me if you would accept the PR or keep your repo as simple as possible.
How would you use Jinja in the context of that project?
I hesitated about the headers and footers, maybe it is better to accept Markdown than HTML... I can change my PR that way.
The main objective was to offer the possibility of a more complex header / footer than what is allowed by the @page and @bottom-left / @bottom-right selectors, for example when used like that : https://stackoverflow.com/questions/34654071/print-page-count-with-total-number-of-pages-using-css
I realised that with my actual code, it is not possible to use content, counter(page) and counter(pages) to make a page counter using CSS in the headers and footers. So, if I modified my code to make it work, would you consider it mergeable as is, or do you want to support Jinja for another reason I didn't understand?
Just in case, I actually fixed my PR #34 as the footer height calculation from the Weasyprint doc didn't seem to work, made CSS counters for page and pages work in both headers and footers, and refactored the code a little bit.
If you still think the header / footer functionality would be better implemented using a template mechanism, you can close my PR, otherwise you can tell me if you want me to implement some changes :)
By using a template engine, header/footer fragments support would not be hard-coded. Users would be free to include partial templates in a core template for their documents. Those templates could mix Markdown and HTML as Markdown supports raw HTML. WDYT?
I still don't really understand : the md2pdf workflow, on master, is Markdown => HTML => pdf.
My PR enables the definition of HTML headers and footers (that could be written using Markdown instead) that are added on every page using WeasyPrint functionalities (as WeasyPrint is actually used for HTML to pdf conversion) : this is what they recommend in their documentation.
The headers and footers are computed, if present, to WeasyPrint BlockBoxs, and placed where they should be on each page of the document (the place reserved for the actual content is diminished according to header and footer height computation).
My implementation, in the end, differs from the one recommended by the WeasyPrint documentation by recomputing headers and footers from each page, and setting page and pages counter so that they can be used by CSS content.
If you wanted to solve the same problem using a template engine, if I understand correctly, that template engine would intervene before the HTML to pdf conversion. I didn't find a way to have a repeatable header / footer with WeasyPrint using only HTML and CSS : the <footer> tag was only present at the end of the document, even when trying to use CSS @page to reproduce its content at the end of each page. So :
- Are you sure there is a way for one pure HTML and one or multiple CSS files to generate a pdf with repeating headers through WeasyPrint? If yes can you show me? (I litterally made this PR because I couldn't find one)
- Am I missing the point entirely?
Hi @c4ffein thank you for this explanation. I've to admit that I read your PR/issue too quickly and I totally missed your point 😅 Sorry for that 🙏
I'll need more time to review your work, but it looks pretty smart. Thank you again for this. ❤️
I keep most of my documentation, both technical and commercial, in Restructured text format.
Since Gitlab wiki and other few tools I use (notably, Joplin: https://joplinapp.org) require Markdown, I'm considering using this instead, for better integration.
For my needs, adding an header and footer to all pages in the final document is a must, so I've forked @c4ffein 's repo.
Please consider accepting PR #34.
Thank you for sharing
I've seen you've just forked my repo, actually I planned to maintain it if @jmaupetit didn't work on it anymore, but I've seen there was a release in January. Do you think you will include that functionality @jmaupetit ?
Otherwise, would you be ok if I made some adjustments on it, like dropping python2 support, or you would rather keep using your fork or the original tool @morlandi ? I'll probably keep using mine but I don't know if there would be any use for me to publish my changes
@c4ffein , I'm just looking around to consider replacing RestructuredText with Markdown for my own documentation; at the moment, I have no clear plan on how far I will proceed in this direction.
In case, I will rather follow your fork than the original project, since adding an header and footer is crucial for my needs.
Unless @jmaupetit would merge your PR #34
Should you remove support for Python 2, I'm fine with it.
I might occasionally send you a PR ... feel free to reject if useless .. I don't mind at all.
Perfect, actually the evolution I would make would be to have one tool to generate pdfs from any "rich" text format, that would include .rst on the long term. I have too many other things going on for now, but I'll probably do some of the things I already have in mind anyway, and your PRs would be greatly appreciated!
@c4ffein may I ask: is there a simple way to add the current / total number of pages in the footer ?
also, what about enabling the "Issues" tab in your fork ?
Cheers
Actually, it happens that was one of my main goals with that PR : you can just use that CSS
footer::after {
content: "Page " counter(page) " of " counter(pages);
}
I enabled the issues tab, but I'm actually creating a new repo as txt2pdf
@morlandi I published my first changes on https://github.com/c4ffein/txt2pdf/
I also included the PR you made on my old repository, but changed the arg name as I want to reserve debug for future purposes, and I also uploaded it on PyPI.
I think it is good to keep this repository as is, because I used f-strings and so my codebase is no more compatible with Python <3.6, but you can link your repository to mine if you want @jmaupetit
@jmaupetit As I see you worked on this project again, would this feature be something you would consider?
I could do a new PR and archive my own project, recommending to use yours instead