[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] script printing code checked in
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] script printing code checked in |
Date: |
Fri, 10 Jun 2005 23:27:02 +0200 |
User-agent: |
Mutt/1.3.22.1i |
On Tue, Jun 07, 2005 at 05:31:04PM +0000, Horst Herb wrote:
> I got sick of playing with wxPython's printing architecture.
That's one good lesson to know :-)
> Tonight I lost the nerve and rewrite gnumed-mini's script printing using
> plain
> postscript / python templating
Given that postscript isn't exactly intended to be user
friendly that speaks for itself regarding the wxPython
printing stuff.
> It appears to work well and very fast, printout virtually immediately with no
> hassles (as long as ghostscript installed or postscript printer
>
> It still has many warts like hardcoded fonts, no automatic line/wordwrap, and
> no intelligence (does not distinguish betwen private/subsidized script etc)
> but if this concept finds general liking, I will continue working on it.
What you describe seems technically nice. I do have one
"problem" with it. PS seems quite low level. How do we
eventually get end-users to define their own forms/templates ?
I do agree that LaTeX is only slightly better in that regard
but it does have some WYSIWYM tools at least.
> It has no dependencies other than python built-ins for now - gnumed has to
> pass all parameters via a single dictionary
Could your code be made to fit into the existing GNUmed
framework:
- template as text blob in database
- data dict generated by GNUmed UI
- template and data handed to form generator class
- template filled in with data by class
- filled in template processed by class
- PS file appears and gets sent to a printer
IOW if you look at client/business/gmForms.py can you imagine
a gmFormEngine child cPSForm ?
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346