Read about OpenEMR's Response to the COVID-19 Pandemic at

Project - Standardize PDF Tools

OpenEMR currently uses several different PDF tools and libraries, which complicates code development. Goal is to standardize all PDF output from a common PDF library.


Hi @brady.miller @sjpadgett mentors

I am interested in this project idea, I found Open-EMR used dompdf/dompdf, mpdf/mpdf and rospdf/pdf-php in currently project, Mainly using mpdf/mpdf and rospdf/pdf-php,
It’s really not easy to develop and maintain.

Can you tell detail about each document to generate to PDF file, Their require format, such as Fonts, Style. Thank you.

Hi @stu01509 ,

There’s some related information on the wiki here, which should provide some good historical context:

The hope in the past was only having mPDF (nicely support UTF8, internationalization, RTL), but as you can see from the wiki page, still have a ways to go (we did at least get rid of tcpdf/html2pdf :slight_smile: ).

Check out demographics_print.pdf script and you’ll see the general settings/font (and RTL support mechanism) when initiating the mPDF class there.


I would also be interested in helping out with this project. From what I have read mPDF, is what we are trying to move towards? Is there by chance, a list of all the places/documents that require pdf printing?

I know of the top of my head that there are some billing documents that print to pdf along with in the demographics…

Hi @Julie_b ,

The following wiki link provides rough outline of where pdf is done:

And can search in the codebase for where mPDF class is initiated to see where most of the pdf creation is done.

As to the goal PDF package, mPDF seems reasonable unless other folks know of something that is better for OpenEMR.

Something I also didn’t mention is the special use of the wkhtmltopdf package for the UB04 PDF creation, which I’ll have to defer to @sjpadgett as to whether that can be consolidated to the chosen standard PDF package.


mPdf has issues(or use to) with absolute positioning which UB04 is built. So need to leave as is.
Still, wkhtmltopdf is very handy and could be useful especially for documents that need precise formating.
To bad it’s binary but I put in a class to make life easier.


This is something that I used for my handwritten notes contribution that might be better: GitHub - MrRio/jsPDF: Client-side JavaScript PDF generation for everyone.


Hello Respected Mentors @brady.miller @sjpadgett ,

I would like to show my intrest in this project. As previously i have done many tasks related to pdf generation with dompdf and with basic html as well. Fun fact: my first project was related to generating bills in pdf.

IMO mpdf will be easier to use as it is a PHP based rather than jsPDF. Still confused what should we keep as standard ?

hi @yashrajbothra ,

Short answer is agree sticking with mPDF , since need something that will work on the back end (for api calls, for example).

Also since wkhtmltopdf is so dependent on the operating system, will make sense to consider also migrating use of that to mPDF also (wkhtmltopdf is only used in one spot, UB04, where absolute positioned is critical and it is quite possible that converting that one spot to mPDF may not be successful, though).