Report page size change when converting from wmf to bmp

I have a need to merge several reports into one job. This I have done by collecting the tempfilenames for each report and then sending the collected result to a new report.
Problem is that it is a mix of portrait and landscape, and the landscape pages are cut at portrait width, not rotated to fit.
So, I rotated the pages using ImageEx and saved as BMP. This works fine for saving as PDF, but not for printer. What happens is that the report, being A4, is defined as 594 * 842.
The BMP when converted ends up at 794 * 1123 . Why is that? Any information outside 594*842 is cut when printing.
Resize bmp to A4 make everything visible, but blurry, I loose 25% of the pixes.
I have also tried to dable around in .NET to convert, I was fooled by a possibility to save as wmf, which was really png, but all good things end up blurry when size is changed. Also a path down the road of SetWorldTransform has been unsuccessfull.

It seems I have one more thing to try before I will be forced to rewrite the reports:
Is it possible to instruct a printer to resize pages to fit?

Workaround found: I changed my dummyreport to have a detail with a single image in it, filling the entire page. Then set the image source to each wmf or bmp during printing.
Seems to work fine.
That was a lot of work before I thought of that :frowning:

1 Like

There is a bug or at least undocumented behavior in Windows implementation of PlayMetaFileRecord (for WMF) and PlayEnhMetaFileRecord (for EMF) functions. Enumerating of metafile records can be required to join several metafiles or to modify existing metafile (for example, to set a total field’s value which is dependent from data printed on next pages). The problem is that if source metafile has records for functions affecting current settings for coordinates transformation (SetViewportOrgEx, SetViewportExtEx, SetWorldTransform, etc.), and the target HDC is metafile-based, Windows can silently insert extra records for SetWorldTransform or ModifyWorldTransform. These extra records break aspect ratio of a target metafile on displaying or printing. The problem in WMF case can be solved by accurate selecting functions to draw, See comment from description of CreateMetaFile:

To create a scalable Windows-format metafile, record the graphics output in the MM_ANISOTROPIC mapping mode. The file cannot contain functions that modify the viewport origin and extents, nor can it contain device-dependent functions such as the SelectClipRgn function.

A more-or-less good solution for extra records inserting Windows in case of EMFs has not been found.

This is the solution I use, too.

1 Like

I found one good thing down the .NET route though: I was able to open the WMF and read it using higher DPI (I think default is 96), then write a BMP with 300 DPI four times the required size. When this scaled down to fit the A4 page, it wasn’t blurry like a simple just a ImageEx rotate did.