bradymiller wrote on Saturday, October 06, 2012:
Hi Tony,
Did you even test the code/feature out? This is actually a commit with very minimal intrusive code in addition to a separate class module that fulfills a highly demanded feature(I actually consider it a bug to not be able to include multi-page pdfs in the report, which this code fixes).
-brady
OpenEMR
bradymiller wrote on Saturday, October 06, 2012:
Additionally,
The benefit of not needing to convert pdf’s to images (which don’t print out anyways if more than one page) is a huge performance improvement.
-brady
sunsetsystems wrote on Saturday, October 06, 2012:
In any case you can still generate the old report the same as before. There’s absolutely no downside.
I’m happy to create the better solution that you are asking for if you are willing to sponsor the work.
sunsetsystems wrote on Sunday, October 07, 2012:
Width fixes for arnabnaha’s problem and some others have been pushed to sf.
sunsetsystems wrote on Sunday, October 07, 2012:
I never really responded to Kevin’s observation that “the webpage in general wastes a lot of paper when printed.” That’s not much different from the old report. Anyway I’d like to point out that it will be common to produce these PDFs without ever printing them, but instead putting them on a CD or memory stick for the patient to take with them. This was a primary need for my client, and for these cases paper is not an issue - the important thing is to easily dump the data in a convenient format.
bradymiller wrote on Monday, October 08, 2012:
Hi,
I’d like to finalize(ie. ensure the community is ok with it) this commit/feature by Rod that provides the following improvements:
1. Allows inclusion of multi-page pdfs in the Patient Report.
2. Doesn’t require conversion of pdfs to images in the Patient Report(can literally take hours).
3. Doesn’t require ImageMagick dependence (huge pain for windows users).
I review/committed this code and it seemed to be a no-brainer commit, so I suggested it was ready for commit after some minor changes. The comments in this thread before Rod posted the link to his code seemed rather non-specific and did not address the above 3 improvements. Is there a reason why we should not be offering these 3 improvements to the community?
-brady
OpenEMR
bradymiller wrote on Monday, October 08, 2012:
Clarification above,
I did not commit the above code, but suggested it was ready for commit.
sunsetsystems wrote on Monday, October 08, 2012:
There’s also:
4. Generates the report as a single downloadable PDF (nothing special required on the client side) that can be saved as a file.
yehster wrote on Monday, October 08, 2012:
Rod,
Please explain why:
It would be difficult for a user to install them otherwise.
Is there more to it than simply copying the packages files into an appropriate directory? Have you made any changes to the distributed files? What is your maintenance strategy for keeping current?
Then for a PDF the features of the FPDI class (which I integrated into HTML2PDF)
Making changes directly to third party libraries is something that should generally be discouraged.
arnabnaha wrote on Monday, October 08, 2012:
Hi…
I get this error when trying to use the DOWNLOAD PDF option in patient report…
ERROR n�1
File : C:\xampp\htdocs\openemr\library\html2pdf\html2pdf.class.php
Line : 1103
The tag <IFRAME> does not yet exist.
If you want to add it, you must create the methods o_IFRAME (for opening) and c_IFRAME (for closure) by following the model of existing tags.
If you create these methods, do not hesitate to send me an email to webmaster@html2pdf.fr to included them in the next version of HTML2PDF.
arnabnaha wrote on Monday, October 08, 2012:
Made another observation right now…
The download pdf works nicely when there are no documents involved in the patient report like - I have patient lab reports and radiographs attached to the encounter. They appear automatically in the report section and if I do check all, and then download PDF, there is this error as stated in my previous post. But, when I donot select the documents, everything works fine…
NB. The documents in the patient records are pdf records and a single photograph…
arnabnaha wrote on Monday, October 08, 2012:
OK….Sorry…Now the error is showing whenever I click DOWNLOAD PDF irrespective any pdf file or photograph or anything…it just got universal!!
sunsetsystems wrote on Monday, October 08, 2012:
Hi Kevin, The changes to the HTML2PDF and FPDI packages are here. Basically adding one line and changing two. Neither of these is available through standard Linux repositories, you have to get them from their respective project sites.
Maintenance strategy is discussed here.
sunsetsystems wrote on Monday, October 08, 2012:
Hi arnabnaha,
Could you reproduce on the demo site? Thanks….
sunsetsystems wrote on Monday, October 08, 2012:
Hi arnabnaha - or if that’s too difficult, there’s probably one report component (checkbox) that’s the problem, so try to narrow it down to find out which one.
arnabnaha wrote on Monday, October 08, 2012:
Hi Rod…
Pointed it out….
Everything works fine if I dont select “Scanned Notes” in the encounter & Forms section….
Even the documents are showing fine….
sunsetsystems wrote on Monday, October 08, 2012:
Scanned Notes comes from the contrib area, so you have to copy it over from there to get the one that’s distributed with OpenEMR. I did make a minor change to that and have tested it successfully… however it kinda sounds like the one you have is customized? If so it will need to be fixed to not generate iframes from its report.php.