I have an update on this issue, which has come from necessity (like most things).
I recently decided to go mostly all in with Linux as my OS. So now I’m running OpenEMR on my laptop client through Ubuntu. I was sitting pretty until I realized that there is no app in Linux that’s as good as Winprint HylaFAX Reloaded for Windows, to print any document straight to HylaFAX for faxing out. So I really needed to figure out how to use the OpenEMR GUI itself to send out faxes. We scan everything to pdf; the format is just more versatile in different settings, compared to tiffs. But the problem, again, is that I couldn’t fax out pdfs without an error, because of the size issue. But I figured out how to do it:
@psoas talked about how fax_dispatch.php works here. But the explanation doesn’t exactly capture how a fax is supposed to get sent. Here’s my breakdown, for anything that starts from a pdf:
-
An image cache gets built from the pdf that goes into the faxcache directory (/var/www/openemr/sites/default/faxcache). If you hit “dispatch” from Faxes In, the cache is built into the subfolder /fax; it you hit “dispatch” from Scanner In, the cache is built into the subfolder /scan. Each page of the pdf gets a .tif file and a .jpg file (each labeled xaaa.tif/xaaa.jpg, xaab.tif/xaab.jpg, and so on). It’s the jpeg files that you see in the preview section of the pop-up dispatch window.
-
The individual tiff files get merged into a temp.tif file through tiffcp, around this line:
- If you copy the pages into a patient chart, the temp.tif gets converted back to a pdf through tiff2pdf, here:
- Otherwise, if you’re ready to fax, it’s the temp.tif file that gets faxed.
The critical line that causes the problem is in step 1:
The comment here says that convert’s default density for pdf-to-tiff conversion is 72 dpi which isn’t very good, so this line upgrades it to “fine mode” fax quality. But the line creates a tiff file that’s huge! And the individual tiff files for each page that the subsequent command tiffsplit creates remain huge. Look at the sizes of the tiff files in your faxcache directory: they’re on the order of >10 MB. Tiff2pdf can’t handle a 16-bit-per-sample tiff file so you can’t copy to chart, and the tiff file is too big to fax out. These errors can all be found in the relevant subfolder of the doneq directory (/var/spool/hylafax/doneq).
The above is also why you can’t sometimes scan a document to tiff and then fax out. If in the scanning process you create a huge tiff file, it won’t work. Incoming faxes are fine because the tiff files are small.
The solution is to change line 432 to create a smaller tiff file. I first tried this:
$tmp0 = exec(“convert -compress JPEG ‘$filepath’ ‘$faxcache/deleteme.tif’”, $tmp1, $tmp2);
The generated tiff files become much smaller with this change. Now, the fidelity of the jpeg preview images is going to be worse with the change, but you can still see the pages decently. And faxes did start going out! But it wasn’t consistent. With some original pdfs, the fax wasn’t going out because of errors like these, seen in the error.log at /var/log/apache2:
JPEGLib: Bogus input colorspace.
temp.tif: Error, can’t write strip 0.
TIFFVStripSize64: Invalid td_samplesperpixel value.
TIFFReadDirectory: Cannot handle zero strip size.
I did some searching and changed the line to this:
$tmp0 = exec(“convert -compress JPEG ‘$filepath’ -background white -alpha remove -alpha off ‘$faxcache/deleteme.tif’”, $tmp1, $tmp2);
With this change, some of the preview jpeg images inverted to black pages with white text. But who cares…the tiff files all looked passable. I have yet to see how the faxes are looking on the receiving end, but so far so good on all faxes going out!
I still haven’t figured out fax_view.php, which is what’s in charge of the hyperlinks in Faxes In and Faxes Out not working. For another day…
–Venu
P.S. When you test the change, make sure you clear the faxcache directory of subfolders with old, huge generated tiff files of the document you’re trying to fax; otherwise a new image cache doesn’t get built.