[lazarus] Printers unit

[Tony Maro]

First, Andrew, I asked about how to make TPrinter print to file in
Delphi - not how to make the document print when I'm done.  How do you
select a filename as output in Delphi printing, rather than a printer
driver?

Also, I've already changed a bit on the path definition so it's not one
path per page, I know exactly what you mean.  Last night I added
rectangle routines.

On Tue, 2002-11-05 at 08:56, Michael Van Canneyt wrote:
> > > I've tried to make it as ready for real printer support as possible.
> > > What I've done is added a TPostScriptCanvas object that handles most of
> > > the Postscript work - not that there's a lot to do.  Unfortunately part
> > > of it must be handled at the Printer object level (page separation, etc)
> > > so I can't encapsulate all of the postscript generation in that object.
> >
> > Are you certain? I was fairly sure that Postscript supported multiple
> > pages from the same file... with %%Page
> 
> AFAIK the showpage command takes care of this.
> %%PAGE is for structured documents, so Ghostview and other PSUtils
> can 'see' the different pages.

Right, and I'm using both, but my point is that a canvas in a TPrinter
object which I based this on is a single page.  So to separate between
the pages, it had to be handled outside the canvas.  Or am I wrong in
thinking that a TPrinter.Canvas object is only covering the current
page?

> > It's a start. Portions of this would be much easier on the interface
> > side of things, but that would make things harder for Cross-Platform
> > support. My Suggestion would be to write a third object. A TPostscript
> > object encapsulating the Postscript calls. Not a translation, not
> > anything. Pure Postscript calls. This way it would be easier later on to
> > separate the Postscript code from your canvas and move it to the
> > back-end of things.
> 
> I also think this is the way to go; I would put this object in the
> FCL instead of the LCL, since it is OS-independent, and has nothing
> visual about it.
> 
> If you can output the postscript to a stream, then everything should run
> on any platform we support.

Well I plan to just leave the Postscript in a TStringList, and keeping
it platform independent should be easy.  I can easily put that in a
TPostScript object  with all the appropriate canvas-like drawing
functions.  I still like the TCanvas inheritance because I'm learning
EPS right now and it seems to me I can give the users access to graphic
routines to copy in bitmaps that will go to the graphic underneath the
postscript, then when you read out the postscript code you would get the
postscript drawing routines AND the encapsulated graphics of whatever
wouldn't draw in postscript code directly.  It also would make it easy
to add a print method to a form by taking the forms canvas and dumping
it into EPS.  Perhaps it would be better though when someone does a call
like that to create a new bitmap when they call those drawing routines,
allow them to write their graphic into it, crop it back to just the size
of what was edited, and encapsulate it right then into postscript.

What I'm not clear on is how the TPrinter object is supposed to interact
with the printer driver.  It seems like what I'm developing for
postscript here is basically a different kind of canvas - this would be
more akin to a printer driver in Delphi then it is a TPrinter object -
or even a TCanvas object.  But with the design of the TPrinter being the
way it is, and the differences between Linux and Windows printing I'm
still a little foggy on how best to link this.

The way I see it, a TPrinter is independent from the printer drivers. 
The TCanvas gets it's properties from the printer driver to decide it's
size, resolution, etc.  When you perform operations on the
Printer.Canvas, you're really talking to the printer driver THROUGH the
TCanvas.  So, really in effect what I'm proposing writing for postscript
support is a virtual printer driver...?

The other thing is that there are huge differences in the way the
printing systems are accessed between Windows and *nix.  In Windows I'm
going to need a handle to the printer driver, etc... in Linux that
doesn't apply.  I'm stressing over how to differentiate in Linux to
specify a printer from the list, etc. without breaking compatibility.


> > > How can I (in Linux) stream the stringlist holding the postscript into
> > > LPR directly?  Or must I go through a temp file?
> > >
> >
> > I would suggest for now a temp file, but you could probably find a way
> > to do it via stdin/stdout.
> 
> Use the TProcess object of the FCL:

Thanks!  That's exactly what I needed.

-Tony