[lazarus] Printers unit

[andrew johnson]

On Wed, 2002-11-06 at 23:31, Tony Maro wrote:
> 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.
> 

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.

> 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.

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