Here's what happened in the PDF:
25 0 obj
<<
/Type/Page
/Parent 9 0 R
/Thumb 24 0 R
/Rotate 90
/Resources 10 0 R
/MediaBox [0 0 612 792]
/Contents 23 0 R
>>
endobj
This is clearly incorrect behavior for a landscape page. Landscape doesn't mean "rotate the portraint page 90 degrees" it means "i need to write horizontally across a page canvas that is wider than it is longer".
In my app, I use StartPage with a paper size and landscape setting; each page might have a different orientation, ex.
pdfControl.StartPage(pagesize, landscape);
When I view the resulting PDF, indeed the page displays in Acrobat Reader as landscape... but all my output was rotated 90 degrees!! So I have in effect a portrait page that was rotated sideways (i.e. the text was drawn sideways from top to bottom). This is obviously not what one would intend... I wanted a landscape page with text left to right like any other page, i.e. just a wider area to draw on.
Is this simply a bug in the DLL, or is there some other setting I should be using to get "normal" landscape, not just a rotated portrait?
wPDFControl02.dll version 2.5.6.2
I am evaluating the wPDFControl for our application. I currently have a test app that draws a WMF file (sourced at 300 dpi) onto a screen PictureBox then overlays text onto it for display using a function that accepts a GDI+ Graphics object pointing to the underlying PictureBox.
A Print option in the app uses DrawImage(picturebox.Image, ...) then the same text overlay function, but passing the Graphics object of the printer page instead of the screen PictureBox (i.e. the text overlay is "device independent").
The text overlay function works correctly for both screen and printer, despite the differences in DPI resolution (96 vs 300) and the underlying device drivers, by looking at the resolution and then scaling x,y coordinates appropriately.
I expected to be able to use the Canvas property to do the same for PDF output as I do for printing, i.e. use DrawImage(picturebox.Image ...) then call the text overlay function passing in the Canvas since it is already a device independent function. When I do this, I get somewhat different results than I expected: although everything draws, the entire output (image plus overlayed text) is scaled slightly large, so that everything is cropped on the right side. The code works for both the Printer Graphics and screen Graphics objects, but not the PDF Canvas!
I tried drawing the WMF directly using the wPDFControl DrawMetafile (telling it the source resolution was 300 DPI), and it DID render the WMF correctly... but had a strange effect on the overlayed text, shrinking it in x,y location and size by a large factor (6 or so), i.e. drawing the metafile had the effect of changing the DPI in behavior, even though the DPI property continues to return 96.
Two questions:
1. Is there some setting I can turn on, or some magic parameters to Canvas.DrawImage I can use, so that the solution used for the Printer (using DrawImage of the picturebox .Image) is correctly scaled as it is on the Printer, instead of 15% or so too big?
and...
2. What is happening to the scaling when wpdfControl.DrawMetafile is used? Is there some setting I can change afterwards to fix this? Setting PageScale isn't good enough, because the font size itself was affected too when the WMF was drawn, not just the x,y locations (i.e. it really does appear that the DPI is changed to some much bigger number, despite the fact that the DPIx and DPIy properties continue to return 96).
Thanks!
