Configuring Hylafax

Hi All,

I’m having trouble seeing received and sent faxes in the Fax/Scan section of OpenEMR. I have Hylafax+ on the same server and am running Ubuntu 16.04. I’m getting confused on what I should be setting in Globals as the Hylafax directory and the server hostname. For the directory I’ve tried /var/spool/hylafax, which is where all the received and sent folders are. I have noticed that the sendq folder and the documents themselves in the recvq folder have only root permissions to view. Is this the issue for the directory? And as far as server hostname, where should that point to?

Thanks,
Venu

Okay, I’ve gotten further. I can see Faxes In and Faxes Out, and the Scanner In is now a samba shared folder.

When I click on the document (a tiff file) in Faxes In, I get this error:

TIFFAppendToStrip: Maximum TIFF file size exceeded.
tiff2pdf: Error writing encoded strip to output PDF -.
TIFFAppendToStrip: Maximum TIFF file size exceeded.
TIFFWriteDirectorySec: Error flushing data before directory write.
tiff2pdf: Error writing virtual directory to output PDF -.
tiff2pdf: An error occurred creating output PDF file.
TIFFWriteDirectoryTagLongLong8Array: Attempt to write value larger than 0xFFFFFFFF in Classic TIFF file…

When I open a Job ID in Faxes Out, I get this error:

/var/spool/hylafax/docq/doc23.ps.20: Not a TIFF or MDI file, bad magic number 8485 (0x2125).
tiff2pdf: Can’t open input file /var/spool/hylafax/docq/doc23.ps.20 for reading.

(This was a fax I sent from the command line.)

When I try to dispatch and fax out a pdf in the scanner directory, I get this error:

couldn’t open EPS file “faxtitle.eps”: No such file or directory
[ 1 page * 1 copy ] left in /tmp/fax2LiBvtf

I can fax out tiff files fine. And I can create a pdf from a tiff file at the command line with tiff2pdf (using sudo though).

So there seems to be an issue at the least with tiff to pdf conversion. I think I have all the right packages (libtiff, Ghostscript). But I’m getting lost deciphering exactly what’s going on.

Thanks for any help.
Venu

I’ve figured it out. The problem lies in tiff2pdf not being able to convert the huge temporary tiff file that fax_dispatch.php generates in the faxcache folder. The issue is specifically discussed in these two threads:

Scanned Documents Dispatch not working https://sourceforge.net/p/openemr/discussion/202505/thread/502c8806/

David Eschelbacher in the second thread breaks it down beautifully. I tried his fix for fax_dispatch.php, which is to bypass tiff2pdf altogether. It works, but the problem with the kludge is it creates huge pdf files (because its source is the huge temp.tif file). So my workaround is going to be to scan everything in tiff format, which skips step 1 in David Eschelbacher’s breakdown. I’m more used to pdfs in patients’ charts, but fax_dispatch will nicely convert the tiffs to pdfs on dispatch anyway. Hopefully without a hitch for all my scanned tiffs.

The document links from Faxes In are coming from the recvq directory, and the job ID links from Faxes Out are coming from the docq directory. I still can’t open documents from these links; the problem is the same - tiff2pdf. This line from fax_view.php is the issue:

passthru(“tiff2pdf ‘$ffname’”);

I tried to manipulate that line with my zero PHP knowledge but couldn’t get my rudimentary fixes to work. And I still don’t understand why the apache error log is saying “Maximum TIFF file size exceeded” when the tiff files to be converted and viewed are tiny. But if someone knows how to manipulate fax_view.php to be able to view the received and sent faxes, I’d be grateful.

This isn’t make or break, because you can still use Dispatch to see the documents (and it’s more efficient doing that too) and can use Faxes Out simply to verify that a fax was sent successfully. But it’s counterintuitive to staff (and me) to have blue hyperlinks that you just want to push, versus a drab non-hyperlink-looking Dispatch.

Also FYI, the files in the doneq directory were very instrumental to figure out what was going on (clearer than the apache error log).

–Venu

2 Likes

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:

  1. 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.

  2. The individual tiff files get merged into a temp.tif file through tiffcp, around this line:

image

  1. If you copy the pages into a patient chart, the temp.tif gets converted back to a pdf through tiff2pdf, here:

  1. 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.

Well…after much effort I have ultimately failed in this project. I haven’t been able to get Fax Dispatch to work optimally. The trouble lies in the convert process. Whether you use Imagemagick (convert) or GraphicsMagick (gm convert), and no matter what arguments you use to change how a pdf file is converted to tiff, the faxes don’t come out right on the receiving end. The conversion tiff file itself looks fine, but something about interfacing with Hylafax makes it too tiny on the receiving end. If I try to resize it up, the output becomes nearly unreadable.

Hylafax is passable with the pdf (with some modifications in the Ghostscript dithering process) if I use sendfax to send the fax directly without conversion. And I still wish to deal in pdfs because they can be previewed when scanned into patient documents, written on with other software, and ultimately handled in the digital domain without dropping down to paper. So the solution I’ve settled on for my work flow is to take a received document (say, a prescription refill request), open it with GIMP, annotate it however I need to, export it with GIMP to a pdf, sendfax it directly from the command line using a kindergarten-level script that I wrote (faxcover or no, re:, comments, etc.), and save it to patient Documents. I can do all this fairly efficiently, and I can still watch its status going out from within OpenEMR. The fidelity of the received fax would be much better if I could export the modified file in GIMP to tiff, but GIMP unfortunately doesn’t allow for export to multi-page tiffs. So that’s that.

The ideal would be to take a received fax, annotate it from within OpenEMR, and then resend it through Fax Dispatch with good fidelity on the receiving end. That’s just not possible as it currently stands.

I was able to fix fax_view.php. You just have to get rid of tiff2pdf; it’s too buggy, for reasons mentioned before. Just change this line:

image

to this:

passthru(“gm convert ‘$ffname’ PDF:-”);

(I’m using GraphicsMagick which is supposed to be more efficient than ImageMagick; if you stick with ImageMagick then the command would just be convert instead of gm convert.)

This change will allow you to open and view faxes/scanned files with the hyperlinks in the Fax/Scan module.

Happy faxing,
Venu

1 Like

Hi,

If your not able to send fax with openemr existing feature then I had developed third party feature in OpenEMR for sendfax. Below are the attached file need to include into your OpenEMR directory just need to execute file using “shell_exec” command and need to pass two arguments to this file one is fax number and another is the document need to fax.
for example: shell_exec(“perl sendfaxhyla.pl $fax_number $doc_file”);

sendfaxhyla.pl (470 Bytes)

Hello Friends,

For the two other people in the world who really want to use Hylafax from within OEMR itself :laughing:…I’ve finally gotten it to work!!

(I’m using Linux as OS on the server.)

In summary, the process as it works in fax_dispatch.php (see above for details):

  1. A pdf gets converted to a tif; //through “convert” command
  2. The tif gets split by page into individual tifs; //through “tiffsplit” command
  3. The individual tifs get converted to individual jpgs ; //through “mogrify” command
  4. The individual tifs get combined to a temp.tif; //through “tiffcp” command
  5. The temp.tif gets faxed out; //through “sendfax” command
  6. Or the temp.tif gets copied to the chart by getting converted to a pdf again. //through “tiff2pdf” command.

Note that if you use a scanner to scan to tif, step 1 is bypassed.

The errors I would keep getting were with tiff2pdf when trying to copy to patient chart, with sendfax sometimes when trying to fax out, and with mogrify oftentimes when the jpg images were to be shown on the preview screen in Fax Dispatch.

The trouble is with convert: it creates huge files. I mean, really really, really huge. That’s where it all breaks bad. Many times, the file becomes too huge to go through subsequent conversion processes and/or fax-outs.

Convert and mogrify are from Imagemagick. I switched from Imagemagick to GraphicsMagick, which uses the command “gm convert.” This is much better in that it creates a significantly smaller tif file. But sometimes it can still be too big, especially with multi-page pdfs. So part one of the solution is to completely avoid step 1 above. To do that, always scan to a tif – not to a pdf.

Now you have a small tif getting tiffsplit to small individual-page tiffs, mogrified to jpgs, and getting tiffcp to a small temp.tif. With a small temp.tif, tiff2pdf works perfect, creating manageable-sized pdfs. You don’t even need the -j option to compress the file. But you do have to add an option which is not in the original code: -F. This expands the tif to fill the pdf page. Tifs now get nicely converted to pdfs, to be copied to chart!

Mogrify still wasn’t always working though, because of memory exceeded issues which I didn’t totally understand. Which meant the preview jpg images wouldn’t always show. Which meant you couldn’t select any images to send to chart as a pdf.

Part two of the solution turned out to be quite simple: GraphicsMagick also has “gm mogrify.” Just using that in the code had every preview image getting created and loading like a charm.

One final problem: Sending out faxes starting as pdfs went weird. Everything we store as documents is in pdf form (so that the doc preview box works as it should), so all send-out faxes start as pdfs. And sometimes I need to annotate pdfs, say, for prescription refill requests that are faxed in (I do not use e-scripting). But the crazy convert/gm convert would lead to weird fax outputs, like shrinking the image to just the lower left-hand corner of the page (it strangely only seems to happen with prescription refill requests – maybe something about the bar codes on them??). Part three of the solution was to have sendfax bypass using the temp.tif (downstream from convert) and just use the original pdf itself. No more funky fax outputs. The compromise here is that you can’t deselect individual pages before the faxing out (because you’re no longer using temp.tif). But I have no practical reason for deselecting pages on a fax-out; that only makes sense on bulk scan-ins to sort, or fax-ins to crop pages before copying to chart…which still works fine, because scan-ins and fax-ins are all tifs.

One last piece: the Job ID hyperlinks on the Faxes Out tab wouldn’t always open, so I added code in fax_view.php to get that to work with all different file types.

TL;DR

For fax_dispatch.php:

  1. Modify line 159 to
    $tmp0 = exec("tiff2pdf -p letter -F -o " . escapeshellarg($target) . " " . escapeshellarg($faxcache.’/temp.tif’), $tmp1, $tmp2);
  2. Modify line 327 to
    "sendfax -A -n " . escapeshellarg($form_finemode) . " -d " .
    escapeshellarg($form_fax) . " " . escapeshellarg($tmpfn2) . " " . escapeshellarg($filepath),
    $tmp1,
    $tmp2
    );
  3. Modify line 432 to
    $tmp0 = exec("gm convert -density 203x196 " . escapeshellarg($filepath) . " " . escapeshellarg($faxcache.’/deleteme.tif’), $tmp1, $tmp2); //But you really want to bypass this command.

(Be sure to install GraphicsMagick first.)

  1. Modify line 448 to
    $tmp0 = exec("cd " . escapeshellarg($faxcache) . “; gm mogrify -resize 750x970 -format jpg *.tif”, $tmp1, $tmp2);

For fax_view.php:

  1. Add between line 41 and 42
    elseif (substr($line, 0, 5) == ‘!pdf:’) {
    $ffname = $GLOBALS[‘hylafax_basedir’] . ‘/’. substr($line, strrpos($line, ‘:’)+1);

elseif (substr($line, 0, 6) == ‘!tiff:’) {
$ffname = $GLOBALS[‘hylafax_basedir’] . ‘/’ . substr($line, strrpos($line, ‘:’)+1);

That’s it. I hope this helps. For someone who knew absolutely nothing about Linux or coding just two years ago when I started on OEMR, it is such an awesome feeling to figure all this out. I feel like Neo in The Matrix. I know kung fu. Thanks to this community of Morpheuses.

Cheers,
Venu

1 Like

congrats @vrjula, thanks for taking the time to share your approach and fixes, you’re probably ready for a pull request to formalize this contribution :wink:

we could update the wiki as well:
https://www.open-emr.org/wiki/index.php/OpenEMR_Wiki_Home_Page#Supplementary
https://www.open-emr.org/wiki/index.php/FAQ#What_is_ImageMagick.3F

Hi @stephenwaite, after further review, the ruling on the field has changed. The above works okay, but I’d like to see if I can improve it so that concatenated pages are shown. Working hard on it…

-Venu

1 Like

@stephenwaite, I was hoping you could help me get out of a dumb bind. I’ve gotten everything to work well on my server. However, when the same php file executes in OEMR installed on another server (Ubuntu 18.04 OS), there’s a bug. I’ve isolated it to no exec() functions running in the php file. It’s got to have something to do with permissions (I can exec(sudo …) with a simple php script). I seem not to have exec permissions in php on this server. All permissions of relevant files/folders seem to be equivalent between the two servers.

Why can’t I run exec in PHP??

No matter, I finally figured it out. Linux and permissions…at times, downright maddening.

Prerequisites: ghostscript, graphicsmagick, and libtiff.

I’ll submit to github. :sweat_smile:

1 Like

Ok, submitted changes from my branch. See what y’all think…

Cheers,
Venu