Still working on my print routine for this current project. I have taken everyone’s advice and created the entire routine by using only DrawString, DrawRect, and DrawOval (avoiding the 72dpi trap of DrawInto). I scaled everything to HorizontalResolution/72. I set the printer for max resolution and then grab the Horizontal Resolution it actually uses (see code below) for my scaling. When I print to my Laser Printer, I get a beautiful, crisp print. I can change the resolution of the printer (from 600 to 2400) and still get the proper size printout, so I believe the scaling of everything is working as should.
My problem comes in when I choose Adobe Printer as the output device. Regardless of what option I choose for the PDF resolution in the PDF Print dialog settings, I get the same result … a printout that’s about 1/4th the size it should be (and really crappy looking print, at that). Using MsgBox dialogs, I can see that the Adobe Printer resolution setting I’m getting back is correct (e.g., I get 600dpi for “Standard”, 2400dpi for "High Quality Print, etc.).
What am I missing this time?
Thanks in advance for any help you may offer …
Dim g as Graphics
dim ps as new PrinterSetup
If g <> Nil Then
prtHRES = ps.HorizontalResolution
prtScaleFactor = prtHRES / 72
// print the header area
dim caseTitle As String = lblModelName.Text
dim ycoord As Integer
dim xcoord As Integer
dim dpisetting As Integer = 72
dim topoffset As Integer = 12 * prtScaleFactor // 1/4" @ 72dpi
dim leftoffset As Integer = 36 * prtScaleFactor // 1/2" @ 72dpi
dim caseTitleHeight As Integer
dim caseTitleWidth As Integer
dim wordspc As Integer = 15 * prtScaleFactor // spacing between case name and descriptor lines at the top
dim linespc As Integer = 3 * prtScaleFactor // spacing between the two descriptor lines at the top
dim usablewidth As Integer = 7.5 * prtHRES
g.TextUnit = FontUnits.Pixel
// print the case model name
g.TextFont = "TGL 0-1451 Engschrift"
g.ForeColor = &c584e4e // dark gray
g.TextSize = 40 * prtScaleFactor
xcoord = leftoffset
caseTitleHeight = g.StringHeight(caseTitle, 700* prtScaleFactor)
ycoord = topoffset + caseTitleHeight
caseTitleWidth = Ceil(g.stringwidth(caseTitle))
g.DrawString(caseTitle, xcoord, ycoord)
// print the 1st line of the case model description
g.TextFont = "Franklin Gothic Demi Cond"
g.ForeColor = &c000000 // black
g.TextSize = 16 * prtScaleFactor
xcoord = leftoffset + wordspc + caseTitleWidth
ycoord = topoffset + caseTitleHeight/2 + g.StringHeight(wndMainWindow.txfModelDescriptor1.Text, 700* prtScaleFactor)/2 - linespc
g.DrawString(wndMainWindow.txfModelDescriptor1.Text, xcoord, ycoord)
Don, I do not have the answer to your question; but, I would caution on using one scaling factor for both horizontal and vertical resolution. There are printers out there that do not have the same maximum resolution for both the vertical and horizontal resolutions. They aren’t too common these days but they do exist. I always have the two different scale factors using the vertical one for anything regarding height such as text size or vertical placement. Then have the horizontal one for anything regarding width or the horizontal direction of going across the page such as string widths and the likes. Yes, it complicates things a wee bit; but, it is safer in the long run.
Thanks for your response, Harry. Yes, I had read of the potential for different horizontal and vertical printer resolutions, but the printer that this application will use is a known entity (I’ve got one here that I’m using for the testing) and has identical horizontal and vertical resolutions.
Most likely, I will go back and retrofit my routine with the ability to handle the “differing” situation as well though … your point is well taken. My more immediate problem is getting consistent (acceptable) results with the hard copy print and PDF versions. Hard copy on the Brother Laser printer (600dpi) looks fabulous … hard copy on an inkjet printer @110 dpi looks “inconsistent” (size is right, but print is ‘thin’ in some areas while ‘thicker’ in others … printing to Adobe PDF (I have the full install of Acrobat) looks horrible (size is wrong … blurry … text did not scale the same as other objects in the print, like rectangles, for instance, etc. etc. etc.)
If your output is too small, it means the actual resolution of the printer is higher than what it reports. I would try to arbitrarily set the resolution to maximum, or simply multiply the proportions by 4 and see what happens.
Thanks, Jeff … this is the first time I ever had to print anything from a Xojo app (how could you tell, right? ^^), so I am definitely learning. I will try your suggestion together with Michel’s ideas below and see where that leads me.
Your suggestion of multiplying the proportions by 4 provided a printed result whose appearance QUICKLY led me to discover an error in my code that was causing my problem. Thanks again, as always, Michel for your help on the matter! Your suggestion sure shortened the troubleshoot time for me and right now that is more appreciated than you’ll ever know.
Got to trying this last night, Jeff … I think you meant “ps.PageWidth” since PageWidth is a property of the Printer Setup and not the Graphics object. But the bottom line is, you’re right … I have incorporated that and ps.PageHeight to allow my routine to handle more than a 8.5" x 11" piece of paper … Thanks for the tip!
I say that because I have seen printers with different resolutions when shopping around. Can I give you a specific printer at this moment…not without going out to the various manufacturers and digging around. Here is a paragraph from an article about this at Understanding Printer Resolution
I don’t believe this is as common these days at is was in the past but still, to be safe, why chance it. Who know what printers are owned by those buying your software.
Even though this is a custom application for one specific customer whose printers are all known, your inputs and Michel’s have convinced me to go ahead and modify the routine to accommodate the possibility of differing horizontal and vertical resolutions mainly because:
No guarantees that the “known” customer printer environment won’t change some day
I should be writing code with ‘re-purposing’ in mind … write once, use many times!
Thanks, Harry (and Michel), for helping me not take the ‘easy way out’ and instead staying consistent with best practices!