I have two points that i need be to be clarifief on :
changing image DPI from 200 to 100 does it mean that i have to resize the image by half or i could keep the actual dimensions but decrease the DPI.
I herd that GDI+ could be a nice alternative to change the image DPI, i googled in that way but i found no example showing how to change the DPI with GDI+.
Any Idea about those questions, and thank you.
Changing the dpi of an existing image doesn't make much sense. It records the resolution of the device that created the image. So that it can be displayed at the same physical size on another device with a different dpi setting. Which is how an image you drew in a painting program on a monitor with 96 dpi doesn't turn into a postage stamp one-sixth the size when you print it on a printer with 600 dpi resolution.
By changing it in your code when you already have the image, you are basically trying to change the characteristics of the device that created the image. That doesn't make sense, your code cannot reach back and, say, change the CCD in the camera or change the monitor resolution.
It's just a reference number.
You can display or print the image at any size you want, it doesn't have to match the original size.
Related
I'm trying to adjust button width depending on the current language that is set in comboBox. For some language like spanish some of the texts are just too long to be fitted into PUSHBUTTON. All controls are in .rc file. To calculate PUSHBUTTON width I'm using RECT (rect.right - rect.left) and to calculate text widht I'm using GetTextExtentPoint32W but unfortunately this method is giving me different values depending in what PC is running. In my laptop where resolution is set to 1920x1080 and scalling100% (recommended is 125%) text width is around 25% bigger than in PC with the same configuration
It depends on the Device Context which may be different across PCs.
Also, you need to be DPI-Aware (since your scalling is not 100%) and GDI isn't.
Suggestion: move to Direct2D.
I am using QSplashScreen to display a splash screen for my QtQuick 2 application. I am using a decent quality image (838 X 500). It displays correctly in some screen resolutions. But for some other resolutions like 2K resolution, it looks like some low quality transformation is applied.
Already tried Qt::SmoothTransformation
Connecting my laptop to my monitor (I have 2K monitor) and selecting 'Duplicate display' option in display management, produces low quality image. Selecting 'Second screen only' produces decent quality image.
QPixmap pixmap(qApp->applicationDirPath()+"/splash.png");
QSplashScreen splash(pixmap.scaledToWidth(screen_width*0.35,Qt::SmoothTransformation));
splash.show();
Is there a way to display an image without loosing the quality?
I am experiencing the same issue with 'Image' in QML.
If Qt is attempting to render the image at the same "physical" size on a higher resolution display, then it will have no choice but to upscale the image. You should provide a higher resolution image:
https://doc.qt.io/qt-5/scalability.html#loading-files-depending-on-platform
The target platforms might automate the loading of alternative
resources for different display densities in various ways. On iOS, the
#2x filename suffix is used to indicate high DPI versions of images.
The Image QML type and the QIcon class automatically load #2x versions
of images and icons if they are provided. The QImage and QPixmap
classes automatically set the devicePixelRatio of #2x versions of
images to 2, but you need to add code to actually use the #2x
versions:
if ( QGuiApplication::primaryScreen()->devicePixelRatio() >= 2 ) {
imageVariant = "#2x";
} else {
imageVariant = "";
}
Forget the part about iOS - I think it's outdated, because it has applied to all platforms for a while now.
So in your case, you should add a splash#2x.png that is twice the resolution (and detail) of splash.png. If you're just using QPixmap, you will need to add the code above to ensure the correct image variant is selected. If you're using QML's Image type, it will select it automatically.
I'm trying to retrieve file icons on Windows. I follow this guide http://pogopixels.com/blog/getting-the-48x48-or-256x256-icon-of-a-file-on-windows/
I use SHIL_JUMBO to get the maximum size possible. However, not all icons returned are big enough, such as the QuickTime icon in the attached image. The size of the whole pixmap returned is still 256x256 but it does not fill the entire space. My program will then scale it down, making it too tiny to see.
I'm wondering if I can retrieve some extra info such as the size of the original icon, so I know that it's too small to scale down.
I have a drawing function that just takes an HDC.
But I need to show an EXACT scaled version of what will print.
So currently, I use
CreateCompatibleDC() with a printer HDC and
CreateCompatibleBitmap() with the printer's HDC.
I figure this way the DC will have the printer's exact width and height.
And when I select fonts into this HDC, the text will be scaled exactly as the printer would.
Unfortunately, I can't to a StretchBlt() to copy this HDC's pixels to the control's HDC since they're of different HDC types I guess.
If I create the "memory canvas" from a window HDC with same w,h as the printer's page,
the fonts come out WAY teeny since they're scaled for the screen, not page...
Should I CreateCompatibleDC() from the window's DC and
CreateCompatibleBitmap() from the printer's DC or something??
If somebody could explain the RIGHT way to do this.
(And still have something that looks EXACTLY as it would on printer)...
Well, I'd appreciate it !!
...Steve
Depending on how accurate you want to be, this can get difficult.
There are many approaches. It sounds like you're trying to draw to a printer-sized bitmap and then shrink it down. The steps to do that are:
Create a DC (or better yet, an IC--Information Context) for the printer.
Query the printer DC to find out the resolution, page size, physical offsets, etc.
Create a DC for the window/screen.
Create a compatible DC (the memory DC).
Create a compatible bitmap for the window/screen, but the size should be the pixel size of the printer page. (The problem with this approach is that this is a HUGE bitmap and it can fail.)
Select the compatible bitmap into the memory DC.
Draw to the memory DC, using the same coordinates you would use if drawing to the actual printer. (When you select fonts, make sure you scale them to the printer's logical inch, not the screen's logical inch.)
StretchBlt the memory DC to the window, which will scale down the entire image. You might want to experiment with the stretch mode to see what works best for the kind of image you're going to display.
Release all the resources.
But before you head in that direction, consider the alternatives. This approach involves allocating a HUGE off-screen bitmap. This can fail on resource-poor computers. Even if it doesn't, you might be starving other apps.
The metafile approach given in another answer is a good choice for many applications. I'd start with this.
Another approach is to figure out all the sizes in some fictional high-resolution unit. For example, assume everything is in 1000ths of an inch. Then your drawing routines would scale this imaginary unit to the actual dpi used by the target device.
The problem with this last approach (and possibly the metafile one) is that GDI fonts don't scale perfectly linearly. The widths of individual characters are tweaked depending on the target resolution. On a high-resolution device (like a 300+ dpi laser printer), this tweaking is minimal. But on a 96-dpi screen, the tweaks can add up to a significant error over the length of a line. So text in your preview window might appear out-of-proportion (typically wider) than it does on the printed page.
Thus the hardcore approach is to measure text in the printer context, and measure again in the screen context, and adjust for the discrepancy. For example (using made-up numbers), you might measure the width of some text in the printer context, and it comes out to 900 printer pixels. Suppose the ratio of printer pixels to screen pixels is 3:1. You'd expect the same text on the screen to be 300 screen pixels wide. But you measure in the screen context and you get a value like 325 screen pixels. When you draw to the screen, you'll have to somehow make the text 25 pixels narrower. You can ram the characters closer together, or choose a slightly smaller font and then stretch them out.
The hardcore approach involves more complexity. You might, for example, try to detect font substitutions made by the printer driver and match them as closely as you can with the available screen fonts.
I've had good luck with a hybrid of the big-bitmap and the hardcore approaches. Instead of making a giant bitmap for the whole page, I make one large enough for a line of text. Then I draw at printer size to the offscreen bitmap and StretchBlt it down to screen size. This eliminates dealing with the size discrepancy at a slight degradation of font quality. It's suitable for actual print preview, but you wouldn't want to build a WYSIWYG editor like that. The one-line bitmap is small enough to make this practical.
The good news is only text is hard. All other drawing is a simple scaling of coordinates and sizes.
I've not used GDI+ much, but I think it did away with non-linear font scaling. So if you're using GDI+, you should just have to scale your coordinates. The drawback is that I don't think the font quality on GDI+ is as good.
And finally, if you're a native app on Vista or later, make sure you've marked your process as "DPI-aware" . Otherwise, if the user is on a high-DPI screen, Windows will lie to you and claim that the resolution is only 96 dpi and then do a fuzzy up-scaling of whatever you draw. This degrades the visual quality and can make debugging your print preview even more complicated. Since so many programs don't adapt well to higher DPI screens, Microsoft added "high DPI scaling" by default starting in Vista.
Edited to Add
Another caveat: If you select an HFONT into the memory DC with the printer-sized bitmap, it's possible that you get a different font than what would get when selecting that same HFONT into the actual printer DC. That's because some printer drivers will substitute common fonts with in memory ones. For example, some PostScript printers will substitute an internal PostScript font for certain common TrueType fonts.
You can first select the HFONT into the printer IC, then use GDI functions like GetTextFace, GetTextMetrics, and maybe GetOutlineTextMetrics to find out about the actual font selected. Then you can create a new LOGFONT to try to more closely match what the printer would use, turn that into an HFONT, and select that into your memory DC. This is the mark of a really good implementation.
Another Edit
I've recently written new code that uses enhanced meta files, and that works really well, at least for TrueType and OpenType fonts when there's no font substitution. This eliminates all the work I described above trying to create a screen font that is a scaled match for the printer font. You can just run through your normal printing code and print to an enhanced meta file DC as though it's the printer DC.
One thing that might be worth trying is to create an enhanced metafile DC, draw to it as normal and then scale this metafile using printer metrics. This is the approach used by the WTL BmpView sample - I don't know how accurate this will be but it might be worth looking at (it should be easy to port the relevant classes to Win32 but WTL is a great replacement for Win32 programming so might be worth utilizing.)
Well it won't look the same because you have a higher resolution in the printer DC, so you'll have to write a conversion function of sorts. I'd go with the method that you got to work but the text was too small and just multiply every position/font size by the printer window width and divide by the source window width.
When I print the CDC for a report control that I've created it appears tiny (less than 1 square inch on paper). How can I get the report to be printed to occupy the entire page ?
Or in other words, how can I make the entire report to appear in one printed page.
CPrintDialog printDialog(FALSE);
printDialog.DoModal();
CDC dcPrint;
if(dcPrint.Attach(printDialog.GetPrinterDC()))
{
int iHorzRes = dcPrint.GetDeviceCaps(HORZRES);
int iVertRes = dcPrint.GetDeviceCaps(VERTRES);
int iHorzResCDC = m_CDC.GetDeviceCaps(HORZRES);
int iVertResCDC = m_CDC.GetDeviceCaps(VERTRES);
dcPrint.m_bPrinting = TRUE;
dcPrint.BitBlt(0,0, iHorzRes, iVertRes, &m_CDC, iHorzResCDC, iVertResCDC, SRCCOPY);
CFont* pOldFont = dcPrint.SelectObject(&m_HeaderFont);
dcPrint.TextOut(0,0,"HelloWorld") ;
dcPrint.SelectObject(pOldFont);
CPrintInfo printInfo;
printInfo.m_rectDraw.SetRect(0,0, iHorzRes, iVertRes);
dcPrint.StartDoc("Report Print");
dcPrint.StartPage();
if(dcPrint.EndPage())
dcPrint.EndDoc();
else
dcPrint.AbortDoc();
}
dcPrint.DeleteDC();
m_CDC is the memory DC that I use to buffer and display the entire report on screen.
As others have said, this is because, in general, the display resolution of printers is a lot higher than displays. Displays are usually 96 to 120DPI: at 96DPI this means that an image of 96 pixels (dots) by 96 pixels occupies approximately 1 square inch on the display. However, if you just take that image and print it out on a 600DPI printer, the size of the image will be about 1/6" by 1/6" - much smaller. This is a bane of the publishing world - images that look fine on displays often look either tiny or terrible when printed.
You could, as has been suggested, use StretchBlt rather than BitBlt to scale up your image. Depending on the difference between your display and printer, this will either look a bit blocky, or utterly hideously blocky.
A much better option is to rewrite your code that does the drawing of the control so that you've got a method that takes a device context (and some co-ordinates) and draws into it. Your normal window painting code can pass the memory DC to this routine and then BitBlt the result to the window, and your painting code can call this method with the printer DC and some suitable co-ordinates.
When writing this routine you'll have to worry about scaling: for example, you'll need to create fonts for the given device context, and with a scaling-indepdendant size (that is, specify the font size in points, not pixels), rather than relying on a pre-created font.
I suppose that you're not scaling your report to the printer's resolution. Typical screen resolution is 72 DPI (sometimes 96 DPI). Printer resolution can be 300DPI, 600DPI or higher.
You should repaint the report to the printer DC with all coordinates and sizes scaled to the printer's resolution.
Your printer has a lot more dots per inch than your screen. You will need to scale things to fit the printed page a bit better.
Try using StretchBlt() instead of BitBlt().