Is ImageMagick and GhostScript still relevant in OEMR 4.0? If yes, what exactly is their role? I have never noticed the difference when they are (not) installed.
"convert" and "mogrify" from the ImageMagick package are needed for image processing in the fax/scan module and perhaps elsewhere. I don't know offhand about GhostScript.
Imagemagick is used by the Patient "Report" from inside demographics to automatically convert PDF to JPG for inline document viewing. However it may not actually be working in version 4. needs testing (or updating) as the feature is very useful.
The patient 'report' conversion feature should still work. Version 4(included in the 3.2 patch also) actually improved this feature by supporting it in windows also:
This is all I ever get…. Imagemagick is installed, but something is not correct, I have not had time to figure out what is missing.
NOTE: Document 'nameofdoc.pdf' cannot be converted to JPEG. Perhaps ImageMagick is not installed?
I don't (can't) use the packaged installers as I have to run many instances of OpenEMR that are not in the default installers path model. Some assumption is being made in the installer that is not necessarily true all the time.
I'm going to poke at this a bit tonight.
PS: these are Ubuntu 10 and CENTOS 5 installations.
Here's my issue: patient_file/report/print_custom_report.php doesn't appear to be handlng the new sites/ directory structure.
# grep convert error.log
convert: unable to open image `/opt/emr_demo/openemr/documents/1/cms1500.pdf': No such file or directory @ blob.c/OpenBlob/2480.
convert: missing an image filename `/opt/emr_demo/openemr/documents/1/cms1500_converted.jpg' @ convert.c/ConvertImageCommand/2838.
The culprit appears to be: custom_report not print_custom_report
Starting at line 334 ..
$from_patientid = array_pop($from_all);
$from_file = $GLOBALS["fileroot"].'/documents/'.$from_patientid.'/'.$from_filename;
$to_file = substr($from_file, 0, strrpos($from_file, '.')) . '_converted.jpg';
if (! is_file($to_file)) exec("convert -density 200 \"$from_file\" -append -resize 850 \"$to_file\"");
This is a patch to fix this problem.
I'll deliver this to the master -dev branch tonight late if there are no objections.
This won't be very helpful. You need to remember to send the file via /controller.php?document&retrieve&patient_id=&document_id= (like the code your removing does). Otherwise, only installations that are insecure will be able to view these (and you'll be removing a bug I fixed awhile back regarding this issue).
I just did exactly what is already being done in printed_custom_report.php. I don't have a clue how to use controller on document that is not in the database. These documents are converted on the fly they don't have document id's. If this is wrong then both should be considered bugs, in which case it should be a common function call in the library for all cases.
Would you mind explain how converting a pdf to jpg and viewing it using normal html img tag is a security issue? That's one thing that has always baffled me.
If $from_file = $d->get_url_filepath(); is an invalid or insecure way to get a document path then the option should be removed from the library.
A secure OpenEMR installation will not allow direct viewing of anything in the documents directory (this is covered in one of the installation steps). Just consider the ramifications if you don't have apache protect these directories (ie. anybody can fish for patient documents in these directories without even being logged into OpenEMR). You went through all this with the patient photos on the patient summary page. Looking through your code, it looks like the correct call is there, but has been removed:
echo "<img src='" . $GLOBALS['webroot'] . "/controller.php?document&retrieve&patient_id=&document_id=" . $document_id . "&as_file=false&original_file=false'><br><br>";
echo "<img src='" . $GLOBALS['webroot'] . "/sites/" . $_SESSION['site_id'] . "/controller.php?document&retrieve&patient_id=&document_id=" . $document_id . "&as_file=false&original_file=false'><br><br>";
May suffice here. Note there is a parameter here call original_file which is set to false. Also note I added that feature to fix the bug you're about to revert to :) Also, as an aside ifs the printed_custom_report.php even be used anywhere (I haven't grepped for it or anything, just wondering).
Forget my advice above(that line will not likely work). The only line to fix I think is where you convert the image:
$from_file = $GLOBALS["fileroot"].'/documents/'.$from_patientid.'/'.$from_filename;
$from_file = $GLOBALS['fileroot'] . "/sites/" . $_SESSION['site_id'] . '/documents/'.$from_patientid.'/'.$from_filename;
(note I'm doing this off the top of my head; can't get to a development environment right now)
Also note an additional bug your including in this code (that has previously been fixed) is reliance on the path $d->get_url_filepath(); . Note this will break if you move the installation somewhere that the directory structure changes (such as rom drive c to drive d etc.); note this is why the code you removed only collects the filename and patient id from the url instead of the full path. I think that my above modification in the original code should get the correct functionality (or at least lead you down the right direction).
Thanks Brady, as you can see I'm not the only one confused by this part of the document process :-) I'll post an updated commit later today . based your suggestion.
$from_file = $GLOBALS['fileroot'] . "/sites/" . $_SESSION['site_id'] .
Sounds good, but test it first (I don't have access to a development environment right now). After you commit it to master, I'll then cherry-pick it to the rel-400 branch).
Also, this code brings to light a critical bug in Ken's rename document code. These converted documents are kept around, so changing document names can obviously screw things up. simplest option is to remove previously converted before doing the conversion. This will dramatically slow down report generation since can never use previously converted files. Other more complicated option is to work the fix into ken's code; remove any converted files when change name that either have initial or new name.
The error "NOTE: Document'xxxxxxxxxxxx_1_01172013.pdf' cannot be converted to JPEG. Perhaps ImageMagick is not installed?" seems to still be present.
This is with Windows 7x86,Firefox, imagemagick,OpenEMR 4.1.1 patch , all with latest versions,
The pdf file displays fine in the Documents section.
Is a fix available or in the works?
I have the same issue. But my install is Ubuntu 12.04 Server OpenEMR 4.1.1(9).
I also have the problem in the Scanned Notes form on Ubuntu 12.04 OpenEMR 4.1.0(13).
No problems with PDFs but doesnt like JPGs.
Oddly enough you can upload a JPG but you need to rename it with a PDF extension. Then it works (annoyingly) just fine.
Regarding windows, there is a faq item on this here:
Regarding ubuntu, was this working for you on the previous OpenEMR version(s)?
Yup it sure was.
And as far as the scanned documents form….
It uploads properly but when one goes to view it you get a "client denied by server configuration" . I checked the permissions and they are good to go.
Any thing else to look at?
BTW: I was able to reproduce this in a test environment with stock install. Plain simple ubuntu server install, deb and patched. Just copied over the db and sites folders..
What are the filenames that are not working. I just tried it on the development codebase and noted that filenames containing an _ don't seem to be working. I had a filename, blood12.pdf work.
The displaying of PDF files in the report section is now working. I am not sure why it is now working. I ran Ccleaner and cleaned up the system in general, including the registry. There were two copies of Imagemagick installed. The oldest one was uninstalled.
1 - PDFs on the scanned docs form work just fine. jpg is what's off. I never noticed the file name being an issue.
2 - I will check what doggmd stated about the reporting thingy and see if that clears it up.
Hi I am getting
"Perhaps ImageMagick is not installed?" error.
Has a solution been posted for this yet?
Imagemagick is installed and can be convert executed form within php is able to write to folder with appropriate permissions.
So what should the output folder be and with what permissions?
$to_url = $GLOBALS['webroot'] . "/sites/" . $_SESSION['site_id'] ."/documents/$pid/" . basename($to_file);
So annoying to have to open each PDF and print them. All my consents are PDF.
Any help would be appreciated.
It works on a clean install of 4.1.2....
Back to the investigative work.
Perhaps David's post 1 and post 2 will help.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.