gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] printing


From: Horst Herb
Subject: Re: [Gnumed-devel] printing
Date: Mon, 22 Sep 2003 16:37:17 +1000

On Mon, 2003-09-22 at 16:22, Ian Haywood wrote:
> On Mon, Sep 22, 2003 at 03:05:22PM +1000, Horst Herb wrote:
> > I never was really happy with the way printing was handled with wx.
> In what way? IMHO, they have bridged the UNIX/Windows gap in the
> least painful way possible. Are you referring to print quality?

Print quality and especially positioning

> In terms of printing-position accuracy, it's difficult to see how they
> can be better than raw PostScript. My own experience is that the scaling
> (720 units = 1 inch) is reasonable (but not exact), but there is often a
> translation artifact of up to 1cm
> (mind you, on cheap printers it is difficult to position the paper
> precisely, high-end printers are probably better.)

PDF=Postscript in that aspect, and printing through acrobat means the
PDF gets converted into Postscript. Windows just doesn't have a generic
Postscript driver / driver translator, or does it? (unless you install
gv for Windows)

> Point is, we may still need the adjustment  system for printing

Point is that when I try to print a script with wx, the output looks
different between printing it from wxGTK as compared to wxWin.
If I print the PDF generated with Reportlab, it looks exactly the same
(incl. positioning) on my Linux and Windows boxes regardless of the
printer used (except for minor changes in paper margins (absolute
offsets)).
 
> > However, I don't know how this would be handled on Windows - any ideas
> > anybody? I suppose on OS/X it works just the same as on Gnu/Linux.
> 
> AFAIK Windows forbids raw access to the printer port (you can go through
> the old MS-DOS API of course, but there's no guarantee the printer on

No, no. Not raw access. But something that transparently allows the
equivalent of acroread -toPostscript <filename>  | lpr
without forcing the user to install complex packages such as gv


> This is only for forms of course, for letters weren't we going to pipe
> through AbiWord or similar?

Absolutely.
Alternative would be to generate Abiword XML programmatically for forms
(like scripts) and pipe it through Abiword for printing.

Horst





reply via email to

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