enabling page numbers for pdfs?

[jamie]

Has anyone found a simple way todo this? i try with css it gets the current page, though it doesn't get the total pages

[emillod]

You can simply use this: Page {pageNumber}/{totalPageNumber}

[yuri]

We do not have the total page number since we moved to the Dompdf library

[emillod]

Ahh, okay, we have too many templates in PDF and we didn't switch to Dompdf yet, haha

[jamie]

You can simply use this: Page {pageNumber}/{totalPageNumber}

nice that works for pageNumber, but not totalPageNumber

[emillod]

jamie yeah, you probably use Dompdf, it's working in tcpdf

[yuri]

I don't recommend to switch to Tcpdf, to whomever reading. More problems than benefit and it will eventually won't work at all, as we don't support it, and the library seems is not mantained.

[emillod]

Yeah, yuri is right in regard DomPDF vs TCPDF. We just didn't switched over because DomPDF have also a lot of limitations. We want to switch to Gotenberg, which is even better than DomPDF. The problem is that we have a lot of templates which are simply not working after switching PDF engine to DomPDF. If we have to rewrite them, we prefer to do it ofr Gotenberg. This is just our preference.

[jamie]

Yeah, yuri is right in regard DomPDF vs TCPDF. We just didn't switched over because DomPDF have also a lot of limitations. We want to switch to Gotenberg, which is even better than DomPDF. The problem is that we have a lot of templates which are simply not working after switching PDF engine to DomPDF. If we have to rewrite them, we prefer to do it ofr Gotenberg. This is just our preference.

i feel ya, its like we can see the better horizon, but we have done so much to deal with the current dompdf weirdness but i think its worth it, dompdf is just too many workarounds and strangeness

[shalmaxb]

I follow this duscussion quite a long time already. I am still with TCPDF, becaus I have a lot of templates and moving them to DOMPDF would cost me a lot of work.
I researched a bit and came to mPDF. I would be interested in your opinions about this engine/libary.

[ThomasB]

Well, mPDF has this note on their website:

About CSS support and development state

mPDF as a whole is a quite dated software. Nowadays, better alternatives are available, albeit not written in PHP.

Use mPDF if you cannot use non-PHP approach to generate PDF files or if you want to leverage some of the benefits of mPDF over browser approach – color handling, pre-print, barcodes support, headers and footers, page numbering, TOCs, etc. But beware that a HTML/CSS template tailored for mPDF might be necessary.

If you are looking for state of the art CSS support, mirroring existing HTML pages to PDF, use headless Chrome.

mPDF will still be updated to enhance some internal capabilities and to support newer versions of PHP, but better and/or newer CSS support will most likely not be implemented.

[jamie]

Headless Chrome might be the way forward, ThomasB is there a composer package for it?

[ThomasB]

Sorry, I'm not a dev. You mean something like this?

https://github.com/chrome-php/chrome

Not sure, if headless chrome would be better, just different or might have other issues.

There are many different solutions available to create PDFs, but they might not be free, have licence issues or privacy concerns or add additional maintainance burden. Free php PDF libaries are quite limited. I saw only 4.

[shalmaxb]

I used Gemini Ki for research, her the conclusion on headless chromium:

"That requirement changes things significantly. If you need to attach PDFs to emails and save them to a folder automatically (server-side), the "Browser Print" method becomes much more complex because there is no "user" to click the print button.

To use the browser engine for background tasks, you would need a Headless Chrome setup. Here is a breakdown of how that works compared to the PHP-native options.

---

1. The Headless Browser Path (Puppeteer / Browsershot)


This is likely what the EspoCRM forum user was hinting at for automated processes. You use a library (like Spatie/Browsershot in PHP) that tells a installed version of Chrome on your server to:

1. Open your HTML template.
2. "Print" it to a PDF file in the background.
3. Return the file path so you can attach it to an email.

• Pros: Perfect rendering; your tables will look exactly as they do in Chrome.
• Cons: Requires node.js and npm installed on the server, and the ability to run chrome/chromium executables. Many shared hosting environments don't allow this."

I have a lot of templates, made with TCPDF, and I use automatic processes to create PDF, attach to email and save them back to the respected user record.
What exactly does that mean: "better alternatives are available". Which ones?

[ThomasB]

Ask the mdpf devs. They wrote it. I guess it's just a general statment that there are better PDF generators available but maybe not as PHP library.
Saw different projects with java script, node,js, java, or you send you data via api to a server.

[shalmaxb]

cIt seems, that a newer version of TCPDF is in development: https://github.com/tecnickcom/tc-lib-pdf

[jamie]

reason i'd go for headless chrome or some sort of full browser render is that it should fully support modern css and html