08/5/1999
	Added Cancel Button to progress bar form. There is a property added
	called ShowCancel that is set to true or false depending on whether
	or not you want the cancel button to show. If it is set to true, then
	the procedure you define in the *new* OnCancel event will be called if
	the button is pressed. This allows you to cancel the printing by
	calling the TPrintObject.Abort procedure;

	Added two new procedure calls to allow word wrapping of long text:

	WriteLineWrap(XL,XR,Y: single; Text: string; KeepY: boolean);
	WriteLineColumnWrap(ColumnNumber: word; Y: single; Text: string;
							KeepY: boolean);

	These procedures allow you to send text to the TPrintObject and it 
	will wrap the text within the given parameters.
		XL: starting position in inches;
		XR: length in inches to wrap the text within;
		Y: vertical positioning either -1.0, -2.0 or absolute position;
		Text: string to print;
		KeepY: instructs the TPrintObject to reset the vertical position 
		on the current page to before the printing of the text. This
		useful if you want to print more on the line you started the
		word wrapped text ensuring that they print at the same vertical
		position.

08/07/1999
	Added SamePage parameter to WriteLineWrap and WriteLineColumnWrap. 
	This boolean variable tells the TPrintObject to test the number of 
	lines being printed and if set to true, will perform a NewPage before 
	starting to print.

	Compensated for user clicking Cancel button where additional printing 
	commands were processed even though the print job could be aborted in 
	the OnCancel method.

	Added read only property PrintingStatus that returns true/false status 
	of the TPrintObject. This property will be false before 
	TPrintObject.Start is called and will be set to false when the print 
	job is cancelled by the user by clicking on the Cancel button of the 
	progress bar form. This allows you to test for a cancelled condition 
	anywhere in your reporting procedures and to take action to abort all 
	pending print procedures that haven't been called. Also allows you to
	then test this value when completing the printing and calling either 
	Quit or	Abort accordingly.

	ProgressBar formstyle changed to fsStayOnTop. This was an oversight 
	which stemmed from the debugging and development stage of this 
	component. Nuff said.

	Changed several variables and properties to protected to allow 
	overriding in descendant objects.
		TopMargin: integer;
		BottomMargin: integer;
		LeftMargin: integer;
		RightMargin: integer;
		DetailTop: single;
		DetailBottom: single;
		procedure OnPageChange;
		procedure AfterPageChange;

	Added a procedure to adjust the maximum value of the progress bar 
	while printing. In the event that more is determined to be printed 
	during a print job, you can now adjust the setting of the progress bar 
	maximum using:
		procedure TPrintObject.SetProgressMax(Max: integer);


	NOTE:	Thanks to Kevin Lu of Taiwan for suggesting the above fixes 
		and additions. 


08/08/1999
	Adjusted NextLine procedure to perform a NewPage if printing will 
	extend beyond the bottom of the detail area. 

	Fixed compatibility issue with word wrap procedures where Memo.Text was 
	used instead of Memo.Lines.Text.

	Fixed bug where user clicks on Cancel button of progress bar form and 
	the message asking them to abort the print job is hidden under the 
	progress bar form. This was because the progress bar form is an 
	fsStayOnTop form. Put commands to hide the form temporarily until user 
	answers, then redisplays form.


08/25/1999
	Added new procedure:

		WriteLineColumnArray(Y: single;Cols: array of variant;
				Justif: array of variant;Strings: array of 
				variant; KeepY, SamePage: boolean);

	This procedure will accept arrays of column numbers, justifications 
	for each column, and the text strings for each column. It will then 
	word wrap all text within their respective columns. If KeepY is true, 
	the vertical print position will be reset to where it was before 
	printing or to the top of page if the columns extended onto a new 
	page. If SamePage is true, the procedure will check line count of the 
	largest string to see if it will fit on the current page and if not, 
	it will perform a new page before printing any of the columns.

	Also cleared up some minor bugs in calculating right justified page 
	text.

	Went on find and destroy mission to eliminate as many bugs 
	(annoyances?) as possible based on certain events that happen. Hard to 
	explain this one but thought I'd throw in the reasoning that I tried 
	to find things that would break the print routine and kinda fine tuned 
	it that way.

	NOTE:	I have found strange behavior when using certain HP drivers 
	such as the 6L and 4P. I don't know what happens but some print 
	drivers misplace drawn lines and some give black pages at times. I am 
	currently researching this to find out what the deal is.

09/23/1999
	Changed style of page number display and control to reflect more 
	modern version. It now resembles more of an MS Access page navigator 
	bar. 
	(Thanks to Douglas Baird for his suggestions regarding this. Also on 
	changing the color scheme to one that reflects the users desktop 
	settings.)

	Fixed problem with line drawing. It seems that the farther down the 
	page that line drawing took place, the more the line was drawn higher 
	than it should be. This did not happen with drawing boxes, only lines. 
	This appeared to fix the problem for all printer drivers, though I 
	haven't tested them all fully yet.

	Reworked the page number printing due to some problems in particular 
	circumstances. I can't even begin to explain the circumstances but the 
	problems have seemed to be corrected now.

	Fixed bug when using -1.0 as the Y parameter for the WriteLine method. 
	This was also throwing off the line drawing somehow but I haven't 
	figured it out as to why. I try not to argue with success, though. 
	When it works, be happy! That's my motto lately.

10/21/1999

	Fixed a really stupid oversight bug in the PrintGraphic routine. It 
	seems that I was storing the width and height of the graphic being 
	printed backwards causing some strange results.

	Reworked the graphics calculations based on some insight from a user. 
	Thanks to Steve Philipp for his comments and help in this.

	I hope to update the help file in the near future because I haven't 
	been keeping up with  it. There are new methods that need to be added. 
	I will try to do this soon so be patient with me, please.

10/31/1999

	Happy Halloween, everyone!!

	ALERT: The name of the TPrintObject has changed from TPrintObject to 
	TMWPrintObject. I did this because some people were telling me that it 
	interferes with their own implementation of an encapsulation of the 
	Delphi TPrinter object. Sorry for this change as it will throw you 
	off some in your code. It is not a major difficulty to overcome, 
	however, and it will NOT be renamed again, I promise. As a rule, I use 
	only one TMWPrintObject on a global form and I reference it everywhere 
	else in the program so I only have one place to change it.

	There seemed to be a problem when printing graphics on occasions. I 
	incorporated a DIB graphic print routine that I got from Inprise and 
	it seemed to straighten the problem out. Bitmaps and icons print 
	fairly well and I hope to add in a command for printing a graphic
	from a file soon. (More thanks to Steve Philips for helping solve the 
	graphics problem)

	The TMWPrintObject will now print to ANY TCanvas object. The 
	procedures are simple and all normal print commands work the same. The 
	difference being that the component recognizes that you are printing 
	to a canvas and not a printer so there is no preview and no storing of
	commands. It just prints directly to the canvas you specify. A 
	property called PrinterCanvas was added for this. Normally, 
	PrinterCanvas = NIL so the component will proceed with a normal
	print as if for a preview or to the printer. However, setting 
	PrinterCanvas to a valid canvas object will direct all printing to 
	that canvas. Ex: PrinterCanvas := MyImage.Canvas;
	It seems to work with any and all standard canvases. One caveat to 
	note, when doing this, it is imperative that you use the SetMargins 
	method to set the width and height of the canvas being printed to. 
	This is because the TCanvas does not have height and width properties 
	for the component to read. Normally, I do something like this:
  		SetMargins(0,0,MyImage.Width,MyImage.Height);
	The PrinterCanvas is set to NIL again when the Quit or Abort command 
	is executed.

	Also added was color capabilities for color printers. New methods were 
	added to allow you to specify font, brush and pen colors and also to 
	retrieve them. Pictures already printed in color because they are only 
	copied to the printer canvas as is. Here is a breakdown of the new 
	methods:

	For setting font color:
		SetFontColor(iColor: TColor);
		GetFontColor: TColor;

	For setting brush color:
		SetBrushColor(iColor: TColor);
		GetBrushColor: TColor;

	For setting pen color:
		SetPenColor(iColor: TColor);
		GetPenColor: TColor;

	Miscellaneous adjustments and improvements to code have been made 
	wherever I have run across them while adding the new features. Since 
	this component has developed over a long period of time, a few things 
	still there from the "old days" had to be updated or changed.

	Enjoy and keep the feedback coming.....

11/4/1999

	I just couldn't help myself. Since I made this thing print to any 
	canvas, I just kept thinking that if it only had drawing capability, 
	then I could just use it for, well, just about everything! So, guess 
	what? I put in all the standard canvas drawing routines.
	I left out a couple that I thought weren't needed such as BrushCopy, 
	CopyRect, etc. I'll probably add these in later. For now, I mainly 
	wanted to be able to draw. Not only that, I wanted to be able to 
	specify everything in inches, since that's what you mainly work
	with when using the TMWPrintObject. So, each drawing routine has both 
	the standard pixel parameter syntax and also my own passing single 
	values specifying inches. This makes it easier to align with your 
	text.

	Methods added:
		SetBrushStyle(Style: TBrushStyle);
	        Arc(X1,Y1,X2,Y2,X3,Y3,X4,Y4: integer);
	        ArcInches(X1,Y1,X2,Y2,X3,Y3,X4,Y4: single);
		ClearCanvas(iColor: TColor);
		ClearCanvasArea(X1,Y1,X2,Y2: integer; iColor: TColor);
	        Ellipse(X1,Y1,X2,Y2: integer);
	        EllipseInches(X1,Y1,X2,Y2: single);
	        FillRect(tmwRect: TRect);
	        FillRectInches(X1,Y1,X2,Y2: single);
	        FloodFill(X,Y: interger;Color: TColor;FillStyle: TFillStyle);
	        FloodFillInches(X,Y: single;Color: TColor;FillStyle: 
				TFillStyle);
	        FrameRect(const tmwRect: TRect);
	        FrameRectInches(X1,Y1,X2,Y2: single);
	        LineTo(X1,Y1: integer);
	        LineToInches(X1,Y1: single);
	        MoveTo(X1,Y1: integer);
	        MoveToInches(X1,Y1: single);
	        Pie(X1,Y1,X2,Y2,X3,Y3,X4,Y4: integer);
	        PieInches(X1,Y1,X2,Y2,X3,Y3,X4,Y4: single);
	        PolyLine(Points: array of TPoint);
	        PolyLineInches(Points: array of single);
	        Polygon(Points: array of TPoint);
	        PolygonInches(Points: array of single);

		** For PolyLineInches and PolygonInches, use a single 
		dimension array that contains consecutive X and Y values.
		ex: ({X}1.0,{Y}1.0,{X}2.0,{Y}1.0,{X}1.5,{Y}2.0,{X}1.0,{Y}1.0)

	So far, everything seems to be working good. The TMWPrintObject also 
	recognizes when color can be used for the printing canvas such as an 
	image canvas or a color printer. If color is OK then everything goes 
	as it should. If color is not an option, then the font color will
	not changes so you don't get faded out lettering. The pen and brush 
	colors will change to provide shades of gray.

	Well, that's all for now. Still working on updating the help file. I 
	have an offer for help from Steve Philips so it might get done faster 
	now. It's going to be in HTML format when it's done so keep your eyes 
	out for it. Anyone who would like a copy when it is complete can email 
	me and I'll put your name in the list. As soon as it's ready I will 
	notify everyone and either mail it out or tell you where to download 
	it.

	What's next, you ask. Hmmmm, I was thinking, all print commands are 
	being stored, so how hard could it be to write them to file for later 
	playing? It could even save the graphic files. No data needed, only a 
	report printer program or preview program. Maybe I should write a 
	small app that could be sent with the file to allow others to view and 
	print the report files. What do you think?


******************************************************************************
**************************    IMPORTANT CHANGES    ***************************
******************************************************************************

11/13/99
	OK, OK, I know I told some of you that there wouldn't be any more
	"facial" changes to the TMWPrintObject component, but, I've been
	catching a lot of flack (just kidding) from my European friends who
	work in millimeters instead of inches and paper sizes that look like
	the alphabet. :o) 
	Soooo, I kinda did some modifications that help make the component a
	little more universal. I added a type called TMeasureType and it's a 
	set of (mtInches, mtMM, mtPixels). Calling SetMeasure(mtXXX) will set
	the print component property MeasureType, and allow the component to
	accept input in that particular unit of measure. The cool thing about
	this is that you can change it at will throughout your code so you don't 
	really need to change much existing code, just add a SetMeasure(mtXXX)
	statement here and there, and voila! (The coders in France just perked
	up)
	
	OK, here's the way it works. I modified each graphic and text printing
	routine to check the unit of measure and convert accordingly. I used a
	standard MM = In * 25.4 to convert between inches and millimeters. If
	you think it needs to be more accurate, it can be changed easy enough.
	Maybe I should have made it a property that you could set. Next version
	maybe. I eliminated all of the duplicate graphic commands such as Arc,
	ArcInches and use just the Arc, etc. All of these methods were changed
	to accept all coordinates as real numbers, using single type. That means
	your pixels, too. That was the only way to make it standard. So, if you
	are already using them, just delete the inches in the title and wrap
	it in a SetMeasure block and everything should work great.

	I had to deviate from the standard in the FillPoly, FillRect, PolyLine
	and Polygon methods because they use Rect's and TPoints and I needed
	reals. So I made them accept either real variables or arrays of single.
	Here is the list of the current graphic routines.

	procedure Arc(X1,Y1,X2,Y2,X3,Y3,X4,Y4: single);
	procedure LineTo(X1,Y1: single);
	procedure MoveTo(X1,Y1: single);
	procedure Ellipse(X1,Y1,X2,Y2: single);
	procedure FillRect(X1, Y1, X2, Y2: single);
	procedure FloodFill(X,Y: single;Color: TColor;FillStyle: TFillStyle);
	procedure FrameRect(X1,Y1,X2,Y2: single);
	procedure Pie(X1,Y1,X2,Y2,X3,Y3,X4,Y4: single);
	procedure PolyLine(Points: array of single);
	procedure Polygon(Points: array of single);

	I added methods to set and get the brush and pen mode and styles. I
	think that pretty much rounded up the most of the printing that people
	tend to do. If I think of more, I'll put them in.

	Now, as to the paper sizes. I added most of the standard paper sizes
	that I have seen appear on printers. If anyone wants to come up with the
	code to read a printers available paper sizes and limit choices to those
	in the component, I'd be more than willing to incorporate it for us. I
	just don't have the time cause I've already worked on this way too much
	this week. But it was fun....

	I do not do any validation when you set the paper sizes so you need to
	sure your printer can handle it before you set it. And even though I
	added some standard envelopes, I haven't come up with the code to rotate
	the font to print to them. Again, if some kind soul out there has a mind
	to.............

	I used an array to store the actual size in inches of each type being
	used so I can do some quick lookups using the Ord() function of the
	paper size. It seems to work pretty good so let me know, I really have
	never seen A4 size paper so I can't do much beta testing. If there's 
	any problems, a little insight into how things work with those sizes
	would be appreciated so I can get an idea of what to do.

	Also, another important change is that all text strings for stuff like 
	buttons and captions are set in a resource file. That way you can put
	whatever you want in whatever language you are using. I did not put
	anything in to adjust the sizes so you should experiment if you change
	the strings. The resource file is PrDrvStr.rc and the compiled resource
	is PrDrvStr.res so these need to be in the directory with the component.
	Make changes to the PrDrvStr.rc file and recompile it using BRCC32 and
	look happy!

	Anyway, enjoy it and keep the feedback coming. Before you know it, we'll
	have us a full-fledged report generator that rivals any on the market. 
	Like I said, we're the Linux or reporting!

12/1/1999
	Several bugs fixed regarding conversions of units. There were several places
	where the component was actually converting units of measure twice for one
	command causing printing location problems. I think I found all of the places
	where this was occurring and fixed the code, but if you find more, let me 
	know. Especially those of you that use millimeters more than inches. Here
	in the states, inches is used almost exclusively so I tend to overlook the
	millimeter functionality a little, sorry about that.

	I changed the progress bar form from fsStayOnTop to fsNormal. There have been 
	several people that, myself included, that notice that if an error occurs, the 
	progress bar hides the error message dialog. Since the component has no way
	of knowing if errors occur outside of it, there was no way for me to make it
	hide itself. In the future, I am thinking of putting in a display error message
	function that you can call if errors occur that will hide the progress bar, 
	display the message, and then redisplay the progress bar. 

	Also, in the PrintFromPreview method, I made a stupid error in placing the
	Printer.EndDoc "inside" of the if statement that checked whether or not the
	progress bar was used to destroy it. If the progress bar is not used, the EndDoc
	command was not used. Thanks to Johan Smit of South Africa for finding this.

12/5/1999
	More millimeter bugs fixed. Most notably those associated with the creation of 
	columns (CreateColumn) and with setting the page number position 
	(SetPageNumberInfo). Sorry about not getting these millimeters right on the first
	shot, but, I don't work with millimeters and so it's a difficult change for me. 
	I'll try to test these types of changes more thouroughly in the future.

1/17/2000
	A suggestion was made regarding some way to know if a user actually printed the
	report from the preview screen in order to track whether something had been 
	printed or not. Being as how it's Y2K now and I haven't blown up yet, I figured
	why not? Actually, I thought it was a pretty good idea and figured that other
	people may need to same kind of functionality. So, I added 2 new methods that you
	can use for whatever purpose you may find a need. The events get executed
	immediately before and after the BeginDoc and EndDoc commands, respectively. The
	event after the EndDoc will not be called if the user aborts the print job before
	it completes.

		BeforePrint: event to execute just before printing starts.
		AfterPrint: event to execute just after printing stops.
	
	NOTE: Thanks to Jean-Luc of France for this useful suggestion.

1/21/2000
	Have added two new methods and one new function. In discussions with Jean-Luc,
	I decided that in order to round out the control events for paging issues two
	new methods were needed: OnFirstPage and OnLastPage. These events allow you to 
	perform specific steps for these two pages of any report. The sequence for 
	printing now works this way:

		1. Set up and start (begindoc) the printer.
		2. Call OnFirstPage event.
		3. Print loop
			3a. Page done goto 3b else 4
			3b. Call OnNewPage event.
			3c. Perform new page.
			3d. Call AfterNewPage event.
		4. if not Printing done then goto 3.
		5. Call OnLastPage event.
		6. Complete printing (enddoc)

	The new function added is CurrentPageNumber. I thought about making this a 
	property that could be set or read, but decided that it would be best to leave 
	that to another time because of the code work involved. I am thinking about adding
	a StartPageNumber or something property that could be used to start a report on
	a page other than 1 for report inserts and such. This, too, would require a little 
	work because of the way that page numbering is being tracked in conjuction with
	the object that stores the page information. It will take a little closer look to
	decide if it is worth it or not. Let me know what you think.

	NOTE: Those of you who have worked with this component for awhile and are using
	some of the outdated method calls, in particular the ones that used the old style
	Shading parameter that was a Word instead of a TColor like it is now, need to be
	aware that the next time I upgrade the component, I will probably eliminate the
	older duplicate methods to cut down on the components size somewhat. It may be a
	good idea to start converting the calls to the new style before that happens. Not
	that I think it's a big deal anyway since they are all so similar. Just thought
	you should be aware of it, that's all.


******************************************************************************
**************************    IMPORTANT CHANGES    ***************************
******************************************************************************

01/31/2000
	This version has now been stripped of the obsolete methods as mentioned earlier
	in this document. The methods that have been removed are:
		SetFontInformation 	: replaced by SetFontInfo
		SetHeaderInformation	: replaced by SetHeaderInfo
		SetFooterInformation	: replaced by SetFooterInfo
		SetPageNumberInformation: replaced by SetPageNumberInfo
		DrawBoxShaded		: replaced by DrawBoxShade
		DrawTextBox		: replaced by TextColumnBox
		SetHeaderDimensions	: replaced by SetHeaderDim
		SetFooterDimensions	: replaced by SetFooterDim
	
	The only difference between most of these are the Shading parameter which now
	takes a TColor or RGB value instead of a single value. The SetFontInfo method
	takes a TFont parameter instead of breaking it down into Name, Size and Style
	like the older SetFontInformation. These changes should not cause you to have
	to rework too much of your existing code. Sorry for the inconvenience but I felt
	it was necessary to eliminate some redundant code since this component is growing
	so much.

	Now, on a brighter note, I have finally added rotated text. That's right, so now 
	you should be able to print on those envelopes. I have also added single font 
	attributes set/get routines. This allows greater flexibility to just change one
	facet of the current font without creating a TFont to pass to SetFontInfo. Here
	is the list of new methods:

		procedure SetFontAngle(Angle: integer)
		function GetFontAngle: integer;
		procedure SetFontName(Name: string)
		function GetFontName: string
		procedure SetFontSize(Size: word)
		function GetFontSize: word
		procedure SetFontStyle(Style: TFontStyles)
		function GetFontStyle: TFontStyles

	The Angle passed in SetFontAngle is given in degrees, not radians. Specifying a
	positive angle will rotate the text counter-clockwise and a negative angle will
	rotate the text in a clockwise direction.

******************************************************************************
**********************    END OF IMPORTANT CHANGES    ************************
******************************************************************************

02/24/2000
	I have added some code in the wrap text routine to recognize CR/LF pairs so
	that passing the text from a memo or memofield will break the lines up where
	ever these characters are.

	I added a Version property to display the version of the component. For now,
	it is simply a non-changeable string property but it gives you a quick visual
	on the version you are using for future releases. (Anyone wanting to provide
	a nice little about box property for this component will have my eternal thanks.)

	Some method calls between the TMWPrintObject and the TMWPages object were using 
	slightly different variable types causing a range check error if range checking 
	is turned on. I changed the parameter list to reflect the new types in the
	TMWPrintObject.

03/16/2000
	Added a new property called AutoPageFeed. There have been several requests to be
	to print to odd sized paper and this avoid the Printer.NewPage command. Setting
	AutoPageFeed to true (default) will do page feed commands and setting it to false
	will not. Bear in mind that this component uses BeginDoc and EndDoc so an ultimate
	page feed at the end of the report cannot be circumvented.

	I have modified the WrapText method to account for CR/LF pairs and as separate 
	characters. This has the effect of eliminating those annoying boxes at the end
	of some lines. I found that this greatly improved sending Memo.Text and such for
	word wrapping. 


03/31/2000
	Well, what can I say. I found another problem that I had to take care of. It
	seems that in the WriteLineRight and WriteLineColumnRight methods, the text did
	not always line up correctly. This was due to the calculation of the start of
	the text when storing it, based on the preview canvas, instead of being calculated 
	depending on which canvas was being used to actually print to. I added two new 
	storage containers to store the method calls to the Pages object. It now performs 
	adequately. Let me know if this has any adverse effects on any existing code.

	It seems that an error occurred if there was no printer defined in windows. I 
	have eliminated this by testing the Printers.Count property when creating the 
	component and when calling the Start method. The Start method will display a 
	message that says no printers are available and then exit. So, I have made the
	Start method a function that returns true or false to reflect whether the 
	component started properly. You should change your code to reflect this. If you
	receive false back from the Start method, show an error message and exit 
	gracefully. Otherwise, you can assume all is well with printing.

	WARNING: I am considering upgrading to D5 and bringing this component up to 
	speed. If that happens, I will still provide this component in D2 compatible
	format, but I will not be able to add new functionality to it. I will continue
	to fix bugs, however, so if you find them, let me know. I have made no solid
	plans yet, but how long can I hold out before I just gotta upgrade?


04/13/2000
	More fixes. You know, same old stuff. You find 'em you fix 'em. Most of these
	had to do with the WriteLineColumnRight and WriteLineRight methods. I was running
	some tests and it seemed that multiple right aligned text wasn't really showing 
	good alignment in the previews and sometimes would print jagged as well. In
	order to make it work better (I still get some jaggedness(?) in smaller zoom sizes)
	I store the right align commands which means they get calculated each time it is
	printed. That seems to clear up most of the problem. I'm sure the rest are simple
	calculation error factors. Anyone else want to come up with a better way, let me 
	know.

	Kudos to John S. Robinson for his diligence in tracking down a very strange bug.
	It seems that in the preview form method SetPrinterOptions, I was wrongly setting
	the printer device paper size instead of setting the print object paper size. I 
	have modified the component with his changes and all seems well again in HP heaven.

	Also, thanks to Tomasz Waraksa for his contributions: WriteLineRightToX and 
	WriteLineCenterToX. These two methods add the ability to right justify text anywhere
	on the page instead of just columns and the right margin, and the ability to center
	text at any point on the page. Below are their declarations:

		procedure WriteLineRightToX(X,Y: single; Text: string);
			X : the position to justify at
			Y : the vertical position to print at
			Text : the text to print right-justified

		procedure WriteLineCenterToX(X,Y: single; Text: string);
			X : the mid-point for the text to be centered at
			Y : the vertical position to print at
			Text : the text to print center-justified

	Some suggestions from Douglas Baird have prompted me to add several new routines 
	as well. Two of them: WriteLineAlign and WriteLineColumnAlign allow you to now
	specify an alignment to use when printing instead of having to call separate
	methods such as WriteLineCenter or WriteLineColumnRight.

		procedure WriteLineAlign( Y: single; Text: string; Align: word);
			Y : the vertical position of the text
			Text : the text to print
			Align : the alignment to use
		procedure WriteLineColumnAlign( ColumnNumber: word; Y: single; Text: string;
				Align: word);
			ColumnNumber: the column to print in
			Y : the vertical position of the text
			Text : the text to print
			Align : the alignment to use in the column

		NOTE: For all alignment parameters, you can now specify them using the 
		new constants: wtLeft, wtCenter, wtRight, wtDecimal, wtIndent. The wtDecimal
		constant is to be used to specify printing using a decimal alignment. If	
		you use the wtDecimal as the alignment in the two methods above, the
		decimals will be lined up one letter space left of the right margin or the
		right edge of the column, respectively. If you want more precise control
		over the location, you should use the next two procedures which also take
		an X parameter for horizontal positioning.

		procedure WriteLineDecimal( X,Y: single; Text: string);
			X : the decimal alignment position 
			Y : the vertical position of the text
			Text : the text to print using decimal alignment
		procedure WriteLineColumnDecimal( ColumnNumber: word; X,Y: single; 
				Text: string);
			ColumnNumber: the column to print in
			X : the decimal alignment position relative to the beginning of the 
			    column, not a definitive horizontal position
			Y : the vertical position of the text
			Text : the text to print using decimal alignment

		These two methods give you exact positioning of the alignment for the 
		decimals. The addition of these four methods should make printing financial
		data much easier.
		
		In order to use the wtIndent, it is necessary to explain how I decided to
		implement it. There was already a tab setting that could be used and it is
		automatically calculated into the horizontal print position for all print
		commands. Because I didn't want to break existing code, I left this as is and
		added a new property called Indent. Specifying a value for indent and using the
		wtIndent alignment, text will be printed at the location specified plus the 
		amount of the Indent property. Keep in mind that it will then add in the current
		setting for the Tab value. This way you can indent all text and further indent
		things like the first sentence of a paragraph.

			procedure SetIndent( Indent: single);
				Indent : the amount to indent text using align=wtIndent
			function GetIndent: single;
				function to return the current indent amount in the current
				units of measure.

		Also taken from Doug's suggestion was the addition of constants for the X and
		Y possibilities of -2.0 and -1.0. These constants are:

			wtLeftX : -2.0 (print at left margin)
			wtLastX : -1.0 (print at last horizontal position)
			wtThisY : -2.0 (print on the current line)
			wtNextY : -1.0 (perform new line before printing text)

	Well, that's all for now. Phew, that's a lot of new stuff. Hope everyone enjoys
	using it as much as I do. Well, it's gotten to the point where I am going to 
	have to force myself to finish updating the help file. This additions file is
	getting too large. Once I add everything into the help, I'll clear this file out
	and start over. 			

***************************     End of Additions  ***************************
	Woody
	TMW Software
	woody.tmw@ih2000.net
