Re: Printing was Re: Feedback Re: [Gnumed-devel] GNUmed Release 0.6.rc1

[Karsten Hilbert]

On Tue, Nov 24, 2009 at 04:41:46PM -0800, Jim Busser wrote:

> >> If wxWidgets will *not* be involved, how will output get to the printer or 
> >> into a "print as PDF" alternative?
> > 
> > Another possibility would be to keep our hands off the
> > "print this" business entirely and simply invoke a
> > 
> >     /usr/bin/gm-print.sh <the file to print>
> > 
> > in which the local admin can do whatever to get things
> > printed. Of course, we'd release with a default gm-print.sh
> > which hands things to kprinter just as well.
> > 
> > After all, that's what we do for faxing/emailing documents
> > already anyway ;-)
> 
> Does Latex remain relevant to the above

Yes and no. It entirely depends, again:

1) there must be something talking to the printer

2) there must be something being able to turn data wanted to
   be printed into printable data

3) there must be something handing data wanted to be printed
   to step 2)

Now, with all of the above, responsibilities can overlap and
shift as we see fit. *One* way of doing it - which I
consider fairly uninvolved (for me as a programmer) to use -
would be:

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

2) 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
        - it lends itself well to template definition with placeholders

3) GNUmed:
        - the user can be given control over what to print (such
          as only certain medication list entrys)
        - it can easily generate LaTeX and hand that over to
          LaTeX proper to be turned into, say, PDF

Actually, GNUmed is involved in step 1.5, too, because it
takes the output of 2) and hands it to 1).

What Jerzy does is this:

1) OpenOffice: interface to CUPS or Windows printing
2) Open Office: HTML format
3) GNUmed: control what to print

Here, 1 and 2 overlap.

Yet another approach:

1) GNUmed/wxPython: interface to the platform printing framework
2) GNUmed/wxPython: internal description of print job or use of, say, PDF files
3) GNUmed: control what to print

Here, all three overlap.

Using the gm-print.sh idea would decouple step 2 from step 1
even more: GNUmed would still select the data to print.
GNUmed would generate a printout in a well-defined output
language (html, xml, tex, you name it) and hand it to the
step 2 processor. 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.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346