Your Privacy Matters: We use our own and third-party cookies to improve your experience on our website. By continuing to use the website we understand that you accept their use. Cookie Policy
914
What controls resolution between document preview and printing?
posted

Using UltraPrintPreview and UltraPrintDocument. Regardless of the resolution I set my screen size, the preview always presents correctly. However, with my screen size changed from its default resolution (say 1600 x 1200) to a much smaller mumber (say 1024 x 768), the printed output uses a much larger font and is truncated. With screen resolution set to my normal 1600 x 1200, a printout correctly matches the preview regardless of printer.

What do I need to do to effect proper printing when the screen resolution has been changed? Is that under my control?

I wrote a small test program using only the framework's printdocument and printdialog; regardless of the screen resolution, the printed output matched the preview. So it appears that this may be some problem unique to the Infragistics components.

Further Information: I am using the document engine to generate a document and creating an enhanced metafile stream using the Infragistics.Documents.Report.Projection.IProjectionPage that is to be printed; the emf is generated using a scale of 1.0. Apparently, this scale factor is what probably needs to be revised based on the user's current screen resolution vs the printer resolution. Can anybody shed some light on how I can determine exactly what the scale factor should be?

  • 914
    posted

    Here is some more information on this problem. Perhaps someone can shed some light on this:

    I am using the Infragistics document engine to generate a fairly complex document for output. Since the document engine does not provide any print preview functionality, I use a combination of the Infragistics UltraPrintDocument and UltraPrintPreview controls for print preview and printing capabilities. To draw a page, I use a function to convert a document page to an enhanced metafile stream that is then drawn to the UltraPrintDocument in its PagePrinting event handler. This is working quite well up to a point.

     

    Regardless of screen resolution, the print preview appears perfect. But when the document is printed, it is apparently scaled based on the ratio of the maximum supported screen resolution to the current screen resolution of the primary screen. I never noticed this in my development because I keep my screen at the maximum 1600x1200. But after getting a report from a client, the discovery was made. If I adjusted my screen resolution to 1024x768, the printed output became resized by a factor of 1.5625 (the ratio of the screen resolution to the maximum). This tracked true to each different resolution that I set my display at. So to circumvent this scaling effect, I added code to get the current screen resolution from Screen.PrimaryScreen.Bounds, and the list of all resolutions supported by the display device using the Win32 EnumDisplaySettings. I then calculated a scale factor to scale the enhanced metafile drawing (1024/1600=0.64 in this case) only when the output is being directed to the printer instead of the preview and the printing is now perfect regardless of the resolution of the primary display device.

     

    You would think that is all there is to it. Unfortunately, most of my client's clients connect to their application via RDP. When the program is accessed running on a server where the client is connected via RDP, the resolution returned by Screen.PrimaryScreen.Bounds is not the server’s resolution but the local computer connected to it. And the Win32 EnumDisplaySettings API has only the current resolution of the remote desktop in its list. So the scale factor is always 1.0.

     

    To begin with, I do not know why the printout is scaled based on the screen resolution to the max resolution, but it is. So now I need a way to determine the screen resolution of the server and its max supported to be able to calculate a scale factor. Or any other reason why this is behaving as it is.

     

    Just looking for any info anyone may have concerning this. Infragistics? Do you guys have any insight?