Not sure about the value of html printing. Root object for all actions should be the output of prescription’s mpdf object, perhaps a temporary file. Existing print options look to be there to speed up workflow. E.g. fax printing eliminates need to enter fax printer in the print dialog.
There seems to be intentions to connect hylafax to the prescriptions function to fax. Now it only outputs a PDF Line 797. More than likely this should be hooked into jerry’s faxsms or medex for faxing outside of the US.
I can’s see a purpose for the HTML print it is essentially the same as the PDF.
hi @juggernautsei ,
The html option was added to all places where creating pdf many years ago in order to support internationalization (since was unable to support non latin characters in PDF output at that time). This is one of reasons why migrating all PDF creation to mPDF would be helpful since it can output non latin characters.
Thanks @brady.miller I can understand that. So, if I understand correctly the HTML does not need to be carried over.
@juggernautsei , If the pdf output supports internationalization (ie. things like utf8 and greek characters etc.), then the html can be dropped.
I have been doing some reading on the mPDF. Here is what it says in the documentation I noticed that the most current version of mpdf is 5.7 in the code base.
Indic languages always require special handling (cf. Indic fonts).
Other than this, whether you need to do anything special is determined by the choice of fonts you use in the document, and whether they contain the necessary characters to display your text. The DejaVu fonts distributed with mPDF will usually display most Western and Eastern European languages, Cyrillic text, Baltic languages, Turkish, and Greek.
Languages which usually need special consideration are: CJK (chinese - japanese - korean) languages, Vietnamese, Thai, and Arabic languages. With these, you need to tell mPDF to select a suitable font.