I've got a basic working printers unit.

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.

The plan is to have anything that I can't handle in postscript code to pass through to a regular TCanvas object that holds a bitmap. Then, once I figure out how... I can encapsulate the remaining graphics from the bitmap into the postscript code. So, any paint or drawing routines the user calls that doesn't directly translate to postscript can still be used.

Attached is the printers.pas unit and a sample application for testing purposes. I have no font support in it yet, and the only things that work on the canvas are moveto, lineto and TextOut.

I wouldn't bother adding this to the LCL just yet... but I wanted feedback to see if anyone thinks I'm headed down the wrong path with this. If I get a green light I'll delve into it deeper.

My questions are these:

What is the proper way to tell the Printer object to print to file using Delphi?

How can I (in Linux) stream the stringlist holding the postscript into LPR directly? Or must I go through a temp file?

Another thing I need to do is query lpstat to find out what printers are available. How can I best issue the shell command and grab the output? I know I could output it to a temp file, read that file then delete it. Is there a better way?

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.

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?

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.

Thanks! That's exactly what I needed.

-Tony

Sorry misunderstood.. but essentially the same answer applies YOU don't. It is all automated by Delphi via standard means. If you want too print to a File it has to be set by some sort of print dialog which calls to win32 etc. And Even then I have never actually seen it done, or for that matter be of any use because in Win32 it is almost impossible to DO anything with the file it produces. So in this case I say, simply add new properties to the printer, something like

TPrinterOutputType = (otStdOut, otFile, otPrinter);
Property OutputType : TPrinterOutputType read.. write..
Property OutputName : String read.. write...

where the output name is the printer name or the file name, or nothing if stdout.

Well basically here is on place where the Postscript object comes in, the Printer can own the Postscript object, and the printer can use that.

Aka instead of sending the printer to the canvas, send the postcript object.

Well here I think you are misunderstanding and WAY over complicating things.. What you are talking about is Postscript versus interface specific printing or really against everything else. And that isn't what we need to begin with. See here is how it should lay out, in the long run (envision italics around that):

TPrinter -
StdOut Mode(aka like Delphi's assign file) -
TProcess

File mode(what you are starting to do) -
TPostscript

  Printer Mode(what your stressing over..) -
    Interface
      -win32
        -metfiles & printer handles
      -unix
        -postscript & lpr

What you are talking about requires WAY more time and energy devoted all at once than I would expect anyone to do. Start with the Postscript. just the postscript. For now we can encapsulate this Printer object around lpr via TProcess. Don't worry about everything else yet.

Basically it's like this, as Michael pointed out, done properly the TPostscript part will be Cross-Platform. Wrapping a TCanvas around it won't be that hard to begin with, and as we go it would be simple to behind the scenes to take the code and add it to interface specific printer canvas handle, aka the printer would file output mode, and the actual calling to the lpr could be added to the backend as well. BUT for now don't stress it. anything is better than nothing. And I can see several ways to do this later on.

Anyway. As I said we only need a special Canvas for now. eventually that can become a non-lcl based canvas for use with the postscript object, and the interface specific routines encapsulating it. Until then keep going the way you are going. The LCL started out only working for GTK+, and it's only been recently that it started supporting Win32. So I see nothing wrong with starting out only supporting Postscript printing. After all even Windows supports Postscript printing, so we may still be able to use the same code there. In fact, AFAIK AbiWord does something along these lines. I might take a look myself later.

Andrew

AFAIK the showpage command takes care of this.
%%PAGE is for structured documents, so Ghostview and other PSUtils can 'see' the different pages.

[cut]

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.

Use the TProcess object of the FCL:

With TProcess.Create(Self) do
  Try
    CommandLine:='/usr/bin/lpr -PPrintterName');
    options:=[poUsePipes];
    Execute;
    With InputStream do
      begin
      // Write postscript to stream.
      end;
  finally
    Free;
  end;

There is a process.txt which describes the object. The object will work on linux/unix/windows.

As far as I know, lazarus uses this to call the compiler.

Michael.

Are you certain? I was fairly sure that Postscript supported multiple pages from the same file... with %%Page

You can handle virtually anything with Postscript calls. Bitmaps are a Problem, as are More advanced Raster Operations, but even they can be handled for the most part natively. And for the rest.. Arc/Pie/Ellipse can use Bezier functions from MathGraph.pp routines and call to Polygon. Polygon works the same way as Polyline except for the fill params. Easy enough to handle I think. Obviously Polyline can simply loop through the points and call to MoveTo LineTo something like this :

procedure TPostScriptCanvas.Polyline(Points: PPoint; NumPts: Integer);
var
  i : Longint;
  LastPt : TPoint;
begin
  If (NumPts <= 1) or (Points = nil) then exit;
  LastPt := Point(LastX, LastY);
  MoveTo(Points[0].X, Points[0].Y);
  For i := 1 to NumPts - 1 do
    LineTo(Points[i].X, Points[i].Y);
  MoveTo(LastPt.X, LastPt.Y);
end;

RoundRect can be based upon my InterfaceBase RoundRect to Call to the canvas arc Pie & rectangle instead of Interfaces. Or better we can convert it into a Polygon Points with Bezier Functions. That will be easier I think..

Also note you have started single path, this will be hard to handle with things like rectangle ellipse and so forth which are their own complete path(not that you can't do it this way.. but it may be difficult).

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. Then your canvas can use it to handle the calls etc. I can help out some with this, but if you are willing to make it easy enough to separate the Postscript Engine from the Postscript Canvas it will make it even easier, because then it would be possible to create wrappers around it in the interface portion, which would essentially allows us to phase out the need for a special TCanvas component. But either way it can be done. So too sum up.. go for it it will work fine for now, and portions can be re-used later on to design a more Delphi/all things automated, most of the work hidden, way.

Its automatic. If the printer is set to start printing immediately the moment you do a NewPage/EndDoc the prior page will print, otherwise all pages will start after EndDoc.

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.

Another thing I need to do is query lpstat to find out what printers are available. How can I best issue the shell command and grab the output? I know I could output it to a temp file, read that file then delete it. Is there a better way?

Again, if there is an easy way.. stdin/stdout. I know how to do this in C, but never had a real need in Delphi so.. research. I will see if I can find anything in my spare time. Also you might look into Corel's old library its kinda obsolete(though I think its currently being worked on by Xandros), but it may be a useful reference anyway. Its located at

http://sourceforge.net/projects/libaps/

(and yes, it's in C).

Andrew

I can't seem to get the stream to work quite right (it's "Input" by the way and not "InputStream"

With TProcess.Create(nil) do
  Try
     writeln('Setting LPR command');
     CommandLine:='/usr/bin/lpr';
     options:=[poUsePipes];
     Execute;
     FPostScript.Document.SaveToStream(Input);
  finally
     Free;
  end;

But nothing ever happens. I can call this by saving to a file first and then passing the path to that to lpr in the commandline param above, but not if I try to stream it.

What am I doing wrong?

Thanks,
Tony

Starting to look nicer. If you can encapsulate everything that doesn't require a parent handle into these components, such that it doesn't actually require any of the LCL code, I think this would make a nice starting point for an FCL Printers unit. From there we can create a LCL backend around it to hide the differences between a Printer Canvas and a Canvas. cool.

yes you definitely should use Pen's and Brush's, but as I said before, it would be nicer if none of this code required any LCL code, so that it could become part of the FCL. I would suggest creating a TPSBrush and a TPSPen wih callbacks on change, exactly like the Graphics versions. Then in your code you could do a If Pen.Style = psNull else and so forth. Something along the lines of this :

  TPSObject = class(TPersistent)
  protected
    procedure Changed; dynamic;
    Procedure Lock;
    Procedure UnLock;
  public
    property OnChange: TNotifyEvent read FOnChange write FOnChange;
  end;
  TPSPen = class(TPSObject)
  protected
    procedure SetColor(Value : TColor);
    procedure SetStyle(Value : TPenStyle);
    procedure Setwidth(value : Integer);
  public
    constructor Create;
    destructor Destroy; override;
    procedure Assign(Source: TPersistent); override;
  published
    property Color: TColor read FPenData.Color write SetColor;
    property Style: TPenStyle read FPenData.Style write SetStyle default
psSolid;
    property Width: Integer read FPenData.Width write SetWidth default
1;
  end;

we can slowly remove any dependencies on Graphics.pas this way, while still retaining the Canvas look'n'feel.

Just my thoughts.. others may have(probably do have) better ideas.

Andrew

TPersistent is compiled with the $M+ compiler directive and supports RTTI. In other words: It is streamable and can be used in the object inspector. More words: Delphi compatibility.

Mattias

+ From: Mattias Gaertner
+
+ On 07 Nov 2002 11:45:23 -0600
+ Tony Maro wrote:
+
+ > On Thu, 2002-11-07 at 10:31, andrew johnson wrote:
+ >
+ > > yes you definitely should use Pen's and Brush's,
+ >
+ > I was afraid you were going to say that. The problem is I don't
+ > understand why a Pen or Brush is so... convoluted. Like, why is it a
+ > TPersistent? What advantage is that over just a plain TObject...? +
+ TPersistent is compiled with the $M+ compiler directive and supports RTTI.
+ In other words: It is streamable and can be used in the object inspector.
+ More words: Delphi compatibility.

Another thing is, you can assign a TPersistent to another (of the same type) TPersistent

Like MyBrush.Assign(MyDefaultBrush)

Marc

andrew johnson wrote

yes you definitely should use Pen's and Brush's,

I was afraid you were going to say that. The problem is I don't understand why a Pen or Brush is so... convoluted. Like, why is it a TPersistent? What advantage is that over just a plain TObject...?

TPSPen = class(TPSObject)

Thanks for the samples. I'll build on that.

-Tony

Well, nobody has complained yet about small attachments so here:

Another working printing example. I did as requested and separated the TPostScript object from the printing system completely. It still uses a TPostScriptCanvas for individual pages, to keep a similarity to the standard Delphi printing system so that it will interact more smoothly with it.

So far it supports text with fonts and sizes, color, fills, rectangles, ellipses, lines and pies. Stretching ellipses and pies was hard work, BTW.

I then hacked together a TPrinter object that calls it. The hacked TPrinter will print to postscript file, print to printer or print to PDF. In OS's other than Linux all you get is print to postscript file.

Here's my next question: I've no experience with TPen or TBrush and I wonder if I need to use them to standardize the color selection methods. However, I won't be supporting bitmaps yet, so TBrush may be the wrong thing...

Do you think it needs to use the standard TPen and TBrush objects, or do you think my current approach of a FillColor and PenColor property will be fine? I do need a Pattern property, but it will be postscript code, not bitmap, most likely. I'm having problems figuring out embedding bitmaps. But, considering I've only really been doing Postscript for about a week now, I guess this isn't bad.

Also, I still haven't figured out the question below:

Since this doesn't need to be (IMO shouldn't be) LCL based, does it really matter anyway? So long as the core properties are the same I see no reason why they couldn't be changed cleaned up.. aka un-convoluted. In this situation I see no need for Delphi Compatibility, it has no need to be streamed, and it should never show up in a situation where it wants to be in the OI. So unless someone else as a compelling reason otherwise, I say feel free to change this to make more sense, use less overhead et-al.

Andrew