Why is finding out this magic Rectangle so difficult?
In the OnPrintPage event I have PrintPageEventArgs and I am trying to draw using the Graphics within the bounds of the maximum printable area.
I have tried using PageBounds, PrintableArea, Graphics.VisibleClipBounds, etc. All fail to consistently get the drawing area, especially when switching from Landscape to Portrait layout. PrintableArea does not seem to ever change when you switch from Landscape to Portrait.
I have also noticed that there is a difference in how Graphics.VisibleClipBounds is set depending on if I'm doing a print preview and an actual print. In a preview it always shows Portrait width/height, so I have to check if it is a preview and I have to manually swap the width/height when it is a Landscape.
I need an algorithm to calculate the printable area as it relates to the current Graphics context, not an arbitrary theoretical print area that isn't used in actual drawing.
My concern is dealing with the Graphics matrix offset. So far I have noticed severe inconsistencies between how the Graphics context is pre-translated using the hard margins depending on factors like:
If OriginAtMargins is true or false (not behaving as I would think)
If I'm printing to a printer, or using the PrintPreviewControl (I have to check if this is a print to preview or a print to page to handle the translation properly)
If I'm using my printer at home or my printer at work (both behave differently)
Is there a standard way to handle this? Should I just reset the matrix? When I set OriginAtMargins to true, the Graphics is pre-translated to 84,84, but my margins are 100,100. The hard margins are 16,16. Shouldn't it be translated to 100,100? Since 0,0 should be at the page bounds, not the hard margins.
Basically my method should always work at getting the best printable rectangle. I just need a consistent, device-independent way of making sure that my drawing origin (0, 0) is at the top-left of the page in order for the above Rectangle to be of any use to me.
Your question lacks a little clarity as to what the "best" rectangle is. I'm going to assume you mean the largest rectangle that will be 100% visible when printed.
So lets start by making sure we understand what the print document graphics object "origins" are and how the OriginAtMargins property affects this origin.
OriginAtMargins - Gets or sets a value indicating whether the position
of a graphics object associated with a page is located just inside the
user-specified margins or at the top-left corner of the printable area
of the page.
- PrintDocument Class Definition on MSDN
So with OriginAtMargins set to false (default) the graphics object will be adjusted to the PrintableArea rectangle (about 5/32 from each page edge for my laser printer, old laser printers may be more, new inkjets may print right to the edge, software PDF printers will print right to the edge). So 0,0 in my graphics object is actually 16,16 on the physical page of my laser printer (your printer may be different).
With the default 1 inch page margins and OriginAtMargins set to true, the graphics object will be adjusted to the 100,100,650,1100 rectangle for a normal portrait letter page. This is one inch inside each physical page edge. So 0,0 in your graphics object is actually 100,100 on the physical page.
Margins are also known as "soft margins" as they are defined in software and not affected by the physical printing device. This means they will be applied to the current page size in software and reflect the actual page dimension portrait or landscape.
PrintableArea is also known as "hard margins" which reflect the physical limitations of your printing device. This will vary from printer to printer, from manufacturer to manufacturer. Because these are hardware measurements, they do not rotate when you set the page to landscape/portrait. The physical limitations won't change on the printer regardless of software print settings, so we need to make sure we apply them on the correct axis depending on our software settings for the print document (orientation).
So following the rough model of the sample code you posted, here's a PrintDocument.PrintPage event handler that will draw a rectangle as large as possible while still being visible (with the default PrintDocument.OriginsAtMargins being false). If you set PrintDocument.OriginsAtMargins to true it will draw a rectangle as large as possible while still being visible inside the configured soft margins (defaults to 1" from page edges).
PrintAction printAction = PrintAction.PrintToFile;
private void printDocument_BeginPrint(object sender, PrintEventArgs e)
{
// Save our print action so we know if we are printing
// a preview or a real document.
printAction = e.PrintAction;
// Set some preferences, our method should print a box with any
// combination of these properties being true/false.
printDocument.OriginAtMargins = false; //true = soft margins, false = hard margins
printDocument.DefaultPageSettings.Landscape = false;
}
private void printDocument_PrintPage(object sender, PrintPageEventArgs e)
{
Graphics g = e.Graphics;
// If you set printDocumet.OriginAtMargins to 'false' this event
// will print the largest rectangle your printer is physically
// capable of. This is often 1/8" - 1/4" from each page edge.
// ----------
// If you set printDocument.OriginAtMargins to 'false' this event
// will print the largest rectangle permitted by the currently
// configured page margins. By default the page margins are
// usually 1" from each page edge but can be configured by the end
// user or overridden in your code.
// (ex: printDocument.DefaultPageSettings.Margins)
// Grab a copy of our "soft margins" (configured printer settings)
// Defaults to 1 inch margins, but could be configured otherwise by
// the end user. You can also specify some default page margins in
// your printDocument.DefaultPageSetting properties.
RectangleF marginBounds = e.MarginBounds;
// Grab a copy of our "hard margins" (printer's capabilities)
// This varies between printer models. Software printers like
// CutePDF will have no "physical limitations" and so will return
// the full page size 850,1100 for a letter page size.
RectangleF printableArea = e.PageSettings.PrintableArea;
// If we are print to a print preview control, the origin won't have
// been automatically adjusted for the printer's physical limitations.
// So let's adjust the origin for preview to reflect the printer's
// hard margins.
if (printAction == PrintAction.PrintToPreview)
g.TranslateTransform(printableArea.X, printableArea.Y);
// Are we using soft margins or hard margins? Lets grab the correct
// width/height from either the soft/hard margin rectangles. The
// hard margins are usually a little wider than the soft margins.
// ----------
// Note: Margins are automatically applied to the rotated page size
// when the page is set to landscape, but physical hard margins are
// not (the printer is not physically rotating any mechanics inside,
// the paper still travels through the printer the same way. So we
// rotate in software for landscape)
int availableWidth = (int)Math.Floor(printDocument.OriginAtMargins
? marginBounds.Width
: (e.PageSettings.Landscape
? printableArea.Height
: printableArea.Width));
int availableHeight = (int)Math.Floor(printDocument.OriginAtMargins
? marginBounds.Height
: (e.PageSettings.Landscape
? printableArea.Width
: printableArea.Height));
// Draw our rectangle which will either be the soft margin rectangle
// or the hard margin (printer capabilities) rectangle.
// ----------
// Note: we adjust the width and height minus one as it is a zero,
// zero based co-ordinates system. This will put the rectangle just
// inside the available width and height.
g.DrawRectangle(Pens.Red, 0, 0, availableWidth - 1, availableHeight - 1);
}
The two lines that determine available width and available height are what I think you were looking for in your question. Those two lines take into account whether you want soft margins or hard margins and whether the print document is configured for landscape or portrait.
I used Math.Floor() for the easy way out to just drop anything past the decimal (ex: 817.96 -> 817) just to make sure the available width and height was just inside the available dimensions. I'm "failing safe" here, if you wanted to you could maintain float based co-ordinates (instead of int), just be careful to watch for rounding errors that will result in the clipped graphics (if it rounds 817.96 up to 818 and then the printer driver decides that's no longer visible).
I tested this procedure in both portrait and landscape with both hard margins and soft margins on a Dell 3115CN, a Samsung SCX-4x28 and CutePDF software printer. If this didn't adequately address your question, consider revising your question to clarify "magic rectangle" and "best rectangle".
EDIT: Notes About "Soft Margins"
Soft margins are applied in software and do not take into consideration the hardware limitations of the printer. This is intentional and by design. You can set the soft margins outside the printable area if you want and the output may be clipped by your printer's driver. If this is undesirable for your application, you need to adjust the margins in your program code. Either you can prevent the user from selecting margins outside the printable area (or warn them if they do) or you can enforce some min/max conditions in your code when you actually start printing (drawing) the document.
Example Case: If you set the page margins to 0,0,0,0 in Microsoft Word 2007 a warning dialog pops up that reads "One or more margins are set outside the printable area of the page. Choose the Fix button to increase the appropriate margins." If you click fix, Word will simply copy the hard margins into the soft margins, so the dialog now shows 0.16" for all margins (my laser printer's capabilities).
This is expected behavior. It is not a bug/problem with Microsoft Word if the printed page is clipped because the user ignored this warning and used 0,0,0,0 page margins. This is the same in your application. You need to enforce the limits for whatever if appropriate in your use case. Either with a warning dialog, or you can force the limit more strongly in code (don't offer a choice to the user).
Alternative Strategy
Alright so maybe you don't want to just get the hard margins, but rather get the soft margins and then enforce that the soft margins remain inside the printable area when printing. Let's develop another strategy here.
In this example I will use the origins at margins, and allow the user to select any margin they want, but I'm going to enforce in code that the selected margin not be outside the printable area. If the selected margins are outside the printable area, I'm simply going to adjust them to be inside the printable area.
PrintAction printAction = PrintAction.PrintToFile;
private void printDocument_BeginPrint(object sender, PrintEventArgs e)
{
// Save our print action so we know if we are printing
// a preview or a real document.
printAction = e.PrintAction;
// We ALWAYS want true here, as we will implement the
// margin limitations later in code.
printDocument.OriginAtMargins = true;
// Set some preferences, our method should print a box with any
// combination of these properties being true/false.
printDocument.DefaultPageSettings.Landscape = false;
printDocument.DefaultPageSettings.Margins.Top = 100;
printDocument.DefaultPageSettings.Margins.Left = 0;
printDocument.DefaultPageSettings.Margins.Right = 50;
printDocument.DefaultPageSettings.Margins.Bottom = 0;
}
private void printDocument_PrintPage(object sender, PrintPageEventArgs e)
{
Graphics g = e.Graphics;
// If you set printDocumet.OriginAtMargins to 'false' this event
// will print the largest rectangle your printer is physically
// capable of. This is often 1/8" - 1/4" from each page edge.
// ----------
// If you set printDocument.OriginAtMargins to 'false' this event
// will print the largest rectangle permitted by the currently
// configured page margins. By default the page margins are
// usually 1" from each page edge but can be configured by the end
// user or overridden in your code.
// (ex: printDocument.DefaultPageSettings.Margins)
// Grab a copy of our "hard margins" (printer's capabilities)
// This varies between printer models. Software printers like
// CutePDF will have no "physical limitations" and so will return
// the full page size 850,1100 for a letter page size.
RectangleF printableArea = e.PageSettings.PrintableArea;
RectangleF realPrintableArea = new RectangleF(
(e.PageSettings.Landscape ? printableArea.Y : printableArea.X),
(e.PageSettings.Landscape ? printableArea.X : printableArea.Y),
(e.PageSettings.Landscape ? printableArea.Height : printableArea.Width),
(e.PageSettings.Landscape ? printableArea.Width : printableArea.Height)
);
// If we are printing to a print preview control, the origin won't have
// been automatically adjusted for the printer's physical limitations.
// So let's adjust the origin for preview to reflect the printer's
// hard margins.
// ----------
// Otherwise if we really are printing, just use the soft margins.
g.TranslateTransform(
((printAction == PrintAction.PrintToPreview)
? realPrintableArea.X : 0) - e.MarginBounds.X,
((printAction == PrintAction.PrintToPreview)
? realPrintableArea.Y : 0) - e.MarginBounds.Y
);
// Draw the printable area rectangle in PURPLE
Rectangle printedPrintableArea = Rectangle.Truncate(realPrintableArea);
printedPrintableArea.Width--;
printedPrintableArea.Height--;
g.DrawRectangle(Pens.Purple, printedPrintableArea);
// Grab a copy of our "soft margins" (configured printer settings)
// Defaults to 1 inch margins, but could be configured otherwise by
// the end user. You can also specify some default page margins in
// your printDocument.DefaultPageSetting properties.
RectangleF marginBounds = e.MarginBounds;
// This intersects the desired margins with the printable area rectangle.
// If the margins go outside the printable area on any edge, it will be
// brought in to the appropriate printable area.
marginBounds.Intersect(realPrintableArea);
// Draw the margin rectangle in RED
Rectangle printedMarginArea = Rectangle.Truncate(marginBounds);
printedMarginArea.Width--;
printedMarginArea.Height--;
g.DrawRectangle(Pens.Red, printedMarginArea);
}
Currently the following is working on my printer. I have OriginAtMargins set to false. This causes automatic translation to the HardMarginX and HardMarginY when I'm printing to my printer, but NO translation when I'm printing to the PrintPreviewControl. Therefore, I have to check for this case.
private void printDocument_BeginPrint(object sender, PrintEventArgs e)
{
printAction = e.PrintAction;
printDocument.OriginAtMargins = false;
}
private void printDocument_PrintPage(object sender, PrintPageEventArgs e)
{
Graphics g = e.Graphics;
if (printAction != PrintAction.PrintToPreview)
g.TranslateTransform(-e.PageSettings.HardMarginX, -e.PageSettings.HardMarginY);
RectangleF printArea = GetBestPrintableArea(e);
g.DrawRectangle(Pens.Red, printArea.X, printArea.Y, printArea.Width - 1, printArea.Height - 1);
}
public RectangleF GetBestPrintableArea(PrintPageEventArgs e)
{
RectangleF marginBounds = e.MarginBounds;
RectangleF printableArea = e.PageSettings.PrintableArea;
RectangleF pageBounds = e.PageBounds;
if (e.PageSettings.Landscape)
printableArea = new RectangleF(printableArea.Y, printableArea.X, printableArea.Height, printableArea.Width);
RectangleF bestArea = RectangleF.FromLTRB(
(float)Math.Max(marginBounds.Left, printableArea.Left),
(float)Math.Max(marginBounds.Top, printableArea.Top),
(float)Math.Min(marginBounds.Right, printableArea.Right),
(float)Math.Min(marginBounds.Bottom, printableArea.Bottom)
);
float bestMarginX = (float)Math.Max(bestArea.Left, pageBounds.Right - bestArea.Right);
float bestMarginY = (float)Math.Max(bestArea.Top, pageBounds.Bottom - bestArea.Bottom);
bestArea = RectangleF.FromLTRB(
bestMarginX,
bestMarginY,
pageBounds.Right - bestMarginX,
pageBounds.Bottom - bestMarginY
);
return bestArea;
}
If anyone can try this code on their printer to verify that it works universally, or correct it if I'm wrong, that would be great.
I don't know if pre-translation of the origin to the hard margins when OriginAtMargins is false is standard with all printers, or if it's just doing this on my printer.
I think what you need is simply redraw the image to fit whatever the paper size being used. Here's my code:
Protected Overrides Sub OnPrintPage(ByVal e As System.Drawing.Printing.PrintPageEventArgs)
Dim img As Image = Nothing 'Your image source
Dim ps As PaperSize = MyBase.PrinterSettings.DefaultPageSettings.PaperSize
Dim pF As RectangleF = MyBase.PrinterSettings.DefaultPageSettings.PrintableArea
Dim srcF As New RectangleF(0, 0, pg.ImageSize.Width, pg.ImageSize.Height)
Dim dstF As New RectangleF(0, 0, pF.Width, pF.Height)
e.Graphics.InterpolationMode = Drawing2D.InterpolationMode.HighQualityBicubic
e.Graphics.DrawImage(img, dstF, srcF, GraphicsUnit.Pixel)
MyBase.OnPrintPage(e)
End Sub
Related
I am using PDFBOX and itextsharp dll and processing a pdf.
so that I get the text coordinates of the text within a rectangle. the rectangle coordinates are extracted using the itextsharp.dll.
Basically I get the rectangle coordinates from itextsharp.dll, where itextsharp uses the coordinates system as lower left. And I get the pdf page text from PDFBOX, where PDFBOX uses the coordinates system as top upper left.
I need help in converting the Coordinates from lower left to upper left
Updating my question
Pardon me if you didn't understood my question and if not full information was provided.
well, Let me try to give more details from start.
I am working on a tool where I get a PDF in which a rectangle is drawn using some Drawing markups within a comment section. Now I am reading the rectangle coordinates using iTextsharp
PdfDictionary pageDict = pdReader.GetPageN(page_no);
PdfArray annotArray = pageDict.GetAsArray(PdfName.ANNOTS);
where pdReader is PdfReader.
And the page text along with its coordinates is extracted using PDFBOX. where as I have a class created pdfBoxTextExtraction in this I process the text and coordinate such that it returns the text and llx,lly,urx,ury "line by line" please note line by line not sentence wise.
So I want to extract the text that lays within the Rectangle coordinates. I got stuck when the coordinates of the rectangle returned from itextsharp i.e llx,lly,urx,ury of a rectangle has an origin at lower left where as the text coordinates returned from PDFBOX has an origin at upper left .then I realised I need to adjust the y-axis so that the origin moves from lower left to upper left. for the I got the height of the page and height of the cropbox
iTextSharp.text.Rectangle mediabox = reader.GetPageSize(page_no);
iTextSharp.text.Rectangle cropbox = reader.GetCropBox(page_no);
Did some basic adjustment
lly=mediabox.Top - lly
ury=mediabox.Top - ury
in some case the adjustment worked, whereas in some PDFs needed to do adjustment on cropbox
lly=cropbox .Top - lly
ury=cropbox .Top - ury
where as on some PDFs didn't worked.
All I need is help in adjusting the rectangle coordinates so that I get the text within the rectangle.
The coordinate system in PDF is defined in ISO-32000-1. This ISO standard explains that the X-axis is oriented towards the right, whereas the Y-axis has an upward orientation. This is the default. These are the coordinates that are returned by iText (behind the scenes, iText resolves all CTM transformations).
If you want to transform the coordinates returned by iText so that you get coordinates in a coordinate system where the Y axis has a downward orientation, you could for instance subtract the Y value returned by iText from the Y-coordinate of the top of the page.
An example: Suppose that we are dealing with an A4 page, where the Y coordinate of the bottom is 0 and the Y coordinate of the top is 842. If you have Y coordinates such as y1 = 806 and y2 = 36, then you can do this:
y = 842 - y;
Now y1 = 36 and y2 = 806. You have just reversed the orientation of the Y-axis using nothing more than simple high-school math.
Update based on an extra comment:
Each page has a media box. This defines the most important page boundaries. Other page boundaries may be present, but none of them shall exceed the media box (if they do, then your PDF is in violation with ISO-32000-1).
The crop box defines the visible area of the page. By default (for instance if a crop box entry is missing), the crop box coincides with the media box.
In your comment, you say that you subtract llx from the height. This is incorrect. llx is the lower-left x coordinate, whereas the height is a property measured on the Y axis, unless the page is rotated. Did you check if the page dictionary has a /Rotate value?
You also claim that the values returned by iText do not match the values returned by PdfBox. Note that the values returned by iText conform with the coordinate system as defined by the ISO standard. If PdfBox doesn't follow this standard, you should ask the people from PdfBox why they didn't follow the standard, and what coordinate system they are using instead.
Maybe that's what mkl's comment is about. He wrote:
Y' = Ymax - Y. X' = X - Xmin.
Maybe PdfBox searches for the maximum Y value Ymax and the minimum X value Xmin and then applies the above transformation on all coordinates. This is a useful transformation if you want to render a PDF, but it's unwise to perform such an operation if you want to use the coordinates, for instance to add content at specific positions relative to text on the page (because the transformed coordinates are no longer "PDF" coordinates).
Remark:
You say you need PdfBox to get the text of a page. Why do you need this extra tool? iText is perfectly capable of extracting and reordering the text on a page (assuming that you use the correct extraction strategy). If not, please clarify.
Note that we recently decided to support Type3 fonts, although we weren't convinced that this makes sense (see Text extraction is empty and unknown for text has type3 font using PDFBox,iText (difficult topic!) to understand why not).
What some consider "wrong extraction" can often be "wrong interpretation" of what is extracted as explained in this mailing-list answer: http://thread.gmane.org/gmane.comp.java.lib.itext.general/66829/focus=66830
There are other cases where we follow the spec, leading to results that are different than what PdfBox returns. Watch https://www.youtube.com/watch?v=wxGEEv7ibHE for more info.
if ((mediabox.Top - mediabox.Height) != 0)
{
topY = mediabox.Top;
heightY = mediabox.Height;
diffY = topY - heightY;
lly_adjust = (topY - ury) + diffY;
ury_adjust = (topY - lly) + diffY;
}
else if ((cropbox.Top - cropbox.Height) != 0)
{
topY = mediabox.Top;
heightY = cropbox.Top;
diffY = topY - heightY;
lly_adjust = (topY - ury) - diffY;
ury_adjust = (topY - lly) - diffY;
}
else
{
lly_adjust = mediabox.Top - ury;
ury_adjust = mediabox.Top - lly;
}
These are final adjustment done
I am trying to print an image (from file) to a the printer using a PrintDocument.
I am re-sizing my image so that it is scaled to be full page on the printout when I print this the image is cropped slightly.
EDIT 2
I am using the margins to calculate the area to use:
With printSettings.DefaultPageSettings
Dim areaWidth As Single = .Bounds.Width - .Margins.Left - .Margins.Right
Dim areaHeight As Single = .Bounds.Height - .Margins.Top - .Margins.Bottom
End With
The bounds of the page are 1169x827 (A4) and with the margins it is 1137x795.
After resize my image size is 1092x682 and I am using the following code to draw it:
e.Graphics.DrawImage(printBitmap, .Margins.Left, .Margins.Top)
The annoying thing is that when I print to the PrintPreviewDialog it is scaled perfectly but when I print the exact same code to the actual printer it does not fit.
EDIT 3
Full code can be found at this url
Usage:
Dim clsPrint As New clsPrinting
With clsPrint
.Landscape = True
.SetMinimumMargins()
If .ShowPrintDialog Then
.Documentname = "Some doc name"
.Preview = False 'When True shows ok
.PrintImage("filename of a png file")
End If
End With
Try using e.graphics.VisibleClipBounds for the printable page size in the PrintPage function. As Hans said, it's better not to resize your image before printing.
You must work with MarginBounds:
in C#:
e.Graphics.DrawImage(your_image, e.MarginBounds);
in C++/CLI:
e->Graphics->DrawImage(your_image, e->MarginBounds);
Note: If your image doesn't have the same aspect ratio you'll need to adjust. In this example width of the image exceeded the page width:
Dim adjustment As Double = img.Width / e.MarginBounds.Width
e.Graphics.DrawImage(img, New Rectangle(New Point(0, 0), New Point(img.Width / adjustment, img.Height / adjustment)))
Sounds like you are wanting to print a page with a full bleed which most personal printers are not capable of. As one of the comments above mentions, factor in the margins to re-size the image to the appropriate size.
I did not find a solution to this problem. I worked around it by using the printer margins when performing a print preview and ignoring the margins (start at 0,0 origin) when actually printing. I believe that this is possibly a bug in the printer driver? But I can't confirm.
Is there any technique to calculate the height of text in AcroField?
In other words, I have a template PDF with a body section that I want to paste my long text into and I want to get the height of the text. If it overflows, insert a new page for rest of the text.
This will give height and width:
Vector curBaseline = renderInfo.GetBaseline().GetStartPoint();
Vector topRight = renderInfo.GetAscentLine().GetEndPoint();
iTextSharp.text.Rectangle rect = new iTextSharp.text.Rectangle(
curBaseline[Vector.I1], curBaseline[Vector.I2],
topRight[Vector.I1], topRight[Vector.I2]
);
Single curFontSize = rect.Height;
Just set your field to a font size of zero. This will automatically size the font so that the given text will fit into your field... within certain limits. I don't think it'll shrink below 6 points.
Another alternative would be to use a ColumnText and call myColText.go(true). This will "simulate" layout, letting you know what goes where without actually drawing anything to the PDF. Just whip up a columnText with the same dimensions, font&font-size as your field, and your results should be the same.
In fact, I believe iText's text field rendering code uses ColumnText internally. Yep, have a look at the source for TextField.getAppearance().
Note that the bounding box of your field isn't going to match the box the text is laid out into... you have to account for borer style & thickness. That's why I suggest you look at the source.
I'm trying to find out max available area on my printer. I've printed a simple rectangle trying out different boundary variables. My question is, why doesn't first two work correctly? They don't print a full rectangle on the paper, only the left and top sides are drawn. Why does only the third one prints a full rectangle? I was under the impression of that all three should be working correctly. What am I missing?
Here's my code:
this.printDocument1.DefaultPageSettings.Margins = new Margins(0, 0, 0, 0);
...
private void PrintPage(object sender, PrintPageEventArgs e)
{
//Method 1, no right and bottom sides are printed
e.Graphics.DrawRectangle(new Pen(Color.Black, 1), e.PageBounds);
//Method 2, same as Method 1
e.Graphics.DrawRectangle(new Pen(Color.Black, 1), e.MarginBounds);
//Method 3, works correctly
e.Graphics.DrawRectangle(new Pen(Color.Black, 1), new Rectangle((int)e.Graphics.VisibleClipBounds.X, (int)e.Graphics.VisibleClipBounds.Y, (int)e.Graphics.VisibleClipBounds.Width, (int)e.Graphics.VisibleClipBounds.Height));
}
First one doesn't work because you are trying to print out of margins. Second one fails because you are trying to print over the margin, so the right and bottom lines fall 1 pixel off the bounds. Now 3rd one works IMO because, printing rectangle coordinates are floating point, and you are casting them to integers, thus rounding them down, so the rectangle falls inside the print area.
EDIT
Some additional info I found regarding your comment:
"If the Graphics object is using a nondefault PageUnit,[2] then VisibleClipBounds will be in different units than PageBounds (which is always in units of 100 dpi). To handle these variables, it's useful to have a helper method to return the "real" page bounds in a consistent unit of measure"
Check out this article , I believe it covers everything.
My first guess is that 2 is working with the margins you set previously (0,0,0,0) and that your printer doesn't actually support no-margin printing (most don't). Because of the fact that most printers require at least some margins, #1 will pretty much never work.
Method 3 appears to actually be querying the driver for the printable area of the page and then using that, so, it works.
As for why you get the top and left instead of nothing with #1 and #2, this is because you're just saying "print me a rectangle of these dimensions starting at the upper left hand corner of the printable area" not "print me a rectangle with these dimensions and start in the far upper left hand corner of the page where you can't actually print" so it's trying to, but it goes off the edge of the page since it's bigger than the printable area of the page.
I have a form on which I have a number of textboxes. I wish to print the text from these textboxes in the locations they are on the form. It is printing at the moment using the code below. However, the text prints differently on different printers (on some it prints just right, on some too high, etc). It is being printed on a pre-printed form with spaces for the text so it needs to be fairly exact. What am I missing to make it print the same on every printer?
public void printDocument_PrintPage(object sender, PrintPageEventArgs e)
{
Panel curPanel = this.FormPanel;
Graphics g = (Graphics)e.Graphics;
Pen aPen = new Pen(Brushes.Black, 1);
// Cycle through each control. Determine if it's a checkbox or a textbox and draw the information inside
// in the correct position on the form
int xLocation, yLocation;
for (int j = 0; j < curPanel.Controls.Count; j++)
{
// Check if its a TextBox type by comparing to the type of one of the textboxes
if (curPanel.Controls[j] is TextBox)
{
// Unbox the Textbox
TextBox theText = (TextBox)curPanel.Controls[j];
// Draw the textbox string at the position of the textbox on the form, scaled to the print page
xLocation = theText.Bounds.Left;
yLocation = theText.Bounds.Top;
g.DrawString(theText.Text, theText.Font, Brushes.Black, xLocation, yLocation);
}
}
}
The problem is that you ignoring how the text is aligned inside the control. Default alignment is roughly equal to StringFormat.Alignment = StringAlignment.Center, it can be changed for buttons and check boxes with their TextAlign property. You'll need to use the DrawString() overload that takes a Rectangle and a StringFormat. Note that TextBox is tricky, you might still be off by a few pixels.
Take a look at Control.DrawToBitmap() for a completely different approach.
I'm wondering if maybe the problem is discrepencies in how different printers pull in the paper. The text is off by a maximum of half an inch between printers. I was hoping this wasn't the case because if so I will just have to tailor my application to the client's particular printer (not ideal). Has anyone else run into this situation?
This is most likely a combination of two things:
You need to explicitly set up the page margins/boundaries. Various printers will have default margin and page size settings. Use a PageSetupDialog to help you out. If you want consistent printing, you can make the margins constant, but page size should be the responsibility of the user (and then check to make sure your margins actually fit on the page!).
The text needs to be placed on the page in relation to the page boundaries. I know your comment says that it will be, but it doesn't look like that it is actually implemented in your code. Setting the OriginAtMargins (on your PrintDocument control) to true helps immensely with this.