Printing Methods
As we further conceptualize the
complex requirements, there must be:
- something enabling selection of information-wanted-to-be-printed and forwarding that to ...
- something being able to turn information-wanted-to-be-printed into printable data and forwarding that to ...
- something talking to the printer (say, a print manager like kdeprint or a system level print tool like lpr)
The individual responsibilities of the above may overlap, shift, and intersperse as we see fit. Examples:
- GNUmed / LaTeX / kprinter-or-equivalent
- GNUmed:
- the user can be given control over what to print (such as only certain medication list entries)
- it can easily generate LaTeX and hand that over to LaTeX proper to be turned into, say, PDF
- it can take the output of 2 and hand it to 3
- LaTeX:
- TeX is a well-defined, easily programmatically scriptable output definition format (think HTML for printing)
- it can easily produce PDF and PS with its default tools, see Latex to PDF and Export To Other Formats
- it lends itself well to template definition with placeholders such as are defined in
client/wxpython/gmMacro.py
- a very basic sample was posted to the devel list here
- at the point where we may need to embed fonts to better allow PDFs to be used in other systems, revisit this guide
- kprinter
- it can be called on the command line with a (list of) file(s) to print
- it allows the user to select a print target
- it talks to the print target to get the data printed
- can have its functionality extended http://tuxradar.com/answers/364
- has a non-KDE alternative, gtklp
- for lack of Mac and Windows equivalents, the
lp
(Mac) or lpr
(Windows or Mac) command will work, albeit less flexibly
- see also PrintingMethodsMac and PrintingMethodsWin
- GNUmed / Open Office / Open Office (Jerzy's method)
- GNUmed: control what to print
- get an XSLT template with associated query
- Open Office: HTML format, which overlaps with…
- Open Office: interface to CUPS or Windows printing
- yet another approach
- GNUmed: control what to print
- GNUmed/wxPython: internal description of print job or use of, say, PDF files
- Generation of PDF files may be done (in Python) using ReportLab. The printing system native to platforms (or at least readily available) should be able to process PDF layouts easily.
- GNUmed/wxPython: interface to the platform printing framework
- UNO bridge to ODF in OOo
- this method was established for GmManualLettersForms
- the UNO bridge, being not well-tended on some platforms (e.g Pyuno on Windows), poses problems
- even if the problems were resolved, it would take some time to learn to extend or create a table programmatically inside an ODF document
It
is possible to keep our hands off the "print this" business entirely and simply invoke a
/usr/bin/gm-print_doc <the_file(s)_to_print>
in which the local admin can do whatever to get things printed. Of course, we'd release with a default
gm-print_doc
which hands things to kprinter just as well. After all, that's what we do for
printing/faxing/emailing documents already anyway. Using the
gm-print_doc
idea would decouple step 2 from step 3 even more:
- GNUmed would still select the data to print
- GNUmed would generate a printout in a well-defined layout definition language (html, xml/xslt, tex, you name it) and hand it to the step 2 printable-output generator
- GNUmed would, again, take the output of 2 but then hand it to an admin-/user-definable script by way of which the local user has full control over what happens to that output
One advantage of LaTeX is that it comes in nicely packaged distributions for all relevant platforms. A drawback is that it is a somewhat large package.
See also:
DbFormsStorage,
GmManualLettersForms
External links: