gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Gnome (Debian, Ubuntu) and gnumed medication printing


From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] Gnome (Debian, Ubuntu) and gnumed medication printing
Date: Mon, 11 Jan 2010 21:14:06 +0100
User-agent: KMail/1.12.4 (Linux/2.6.31.8-0.1-default; KDE/4.3.4; i686; ; )

Am Montag 11 Januar 2010 20:46:26 schrieb Jim Busser:
> On 2010-01-11, at 5:29 AM, Karsten Hilbert wrote:
> >> numerous directories of the form
> >>
> >>    /home/jbusser/.gnumed/tmp/gm-L-Template-YRORh6
> >
> > ...
> >
> >> However I now seem no longer to be generating the instance files...
> >
> > You are but because PDF generation now works just fine they
> > get deleted appropriately.
> 
> While the PDF generation works fine, I am now debugging to get such
>  GNUmed-generated PDFs (under Ubuntu which, like Debian, uses Gnome and
>  does not have kprinter installed) actually to the printer.
> 
> I did note that after my failed print, my GNUmed stdout/stderr window
>  contains
> 
>       Transcript written on gm-L-Template-nYzYC1-instance.log.
>       /home/jbusser/bin/gm-print_doc: 46: kprinter: not found
> 

I guess you need to install kprinter or change the gm-foo printer shell script 
so it will push the document to some other printer agent instead of kprinter.

The packagers (Debian, Ubuntu, Kubuntu whatnot can take care of patching that 
script)

Or better yet it is the job of the sysadmin.

> and I wondered whether deletion of the temp files including generated PDFs
>  should be positioned after the above step, and not done when the line
>  returns as above? Or would you expect to never encounter such a line once
>  a printer had been set up? I was just thinking that under the principle of
>  not deleting a medical transmission without confirming its receipt at the
>  destination which – here – is the printer queue. At least once its hits
>  the queue, the user can be notified by the print software that there is a
>  printing problem, but if a user cannot realize the printing was not
>  properly set up and wrongly believes the jobs are emerging somewhere else
>  in the building, that would not be good.

The user should not assume anything is finished until he/she has the 
kprinter/Whatever GUI coming up.

Even if configured without gui it is the sole responsibility of the user to 
make sure the document gets printed.

Future versions of GNUmed might handle this better but for now there is just 
no way to catch those errors. One would have to fiddle with return values of a 
mix of shell scripts/python and printing agents.

This is not feasible now. think Windows. There is no way to implement this. If 
the document leaves your printer it worked :-)

Sebastian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]