Let me explain the problem, I'm getting stuck in it
If I change the dpi settings from the dialog of Printing Preferences of a virtual printer like PDF Creator or any printer that allows to change this setting, and then set a breakpoint like the code below:
PrintDialog printDialog = new PrintDialog();
if ((bool)printDialog.ShowDialog().GetValueOrDefault())
{
System.Printing.PrintCapabilities capabilities = printDialog.PrintQueue.GetPrintCapabilities(printDialog.PrintTicket);
...... insert breakpoint here
}
I can see that the properties printDialog.PrintTicket.PageResolution.X; and printDialog.PrintTicket.PageResolution.Y change correctly while printDialog.PrintTicket.PageMediaSize.Width and printDialog.PrintTicket.PageMediaSize.Height don't change despite the printer resolution change... an A4 paper in portrait mode will always have PageMediaSize.Height = 1122.5196850393702 and PageMediaSize.Width = 793.70078740157476 no matter which resolution is set before ..... for WPF the unit size of these dimensions is set to 1/96th inch but when is Ok on screen because default screen resolution is 96 dpi on the other side is wrong on the printer because it has a different resolution, in other words confuting that Height and Width of the paper are read only properties if I cannot find the way to tell WPF that the unit size of the printer is not 1/96th inch but for example 1/300th inch (if on the printer I previously set 300 dpi ) there's absolutely no way to print at higher resolution than 96dpi
A last note, in my specific case I cannot use RenderTargetBitmap and then resize all to match printer's paper height and width settings because I'm printing high definition barcode images and it would cause an image rescaling that would make the barcode unreadable on final paper because i create it with the purpose to be printed with a resolution of 300dpi which without a resizing will result out of bounds because WPF is telling me the printer paper dimensions in the wrong unit size (1/96th inch) despite the real dpis prevoiusly set on printer
Hoping to have clarified enough the problem,
thanks in advance,
Dave
Related
I would happily provide a screenshot of this, however the problem is the captured image, is much larger than my actual desktop.
I am completely frustrated with this as I have tried using BitBlt with the desktop hdc AND the new "Graphics" commands.
My actual desktop resolution is 1920x1080 - 1080p .
BitBlt and "Graphics" both return that my resolution is 1536x864 # 96 DPI.
A form (WinForm), Maximized, borderless, and irrelevant of scaling mode the form is set to, also shows 1536x864 # 96 DPI.
Now the image that is captured, is like it is being done from 1920x1080, but clipping the region 1536x864 as the screenshot.
If I do PrintScreen directly using Prtscn button, I get the entire image, but still it is about 1.5-2x larger than what I actually see.
What I am looking for -- is a resolution for how I can take a picture of what is on my screen in the scale/dpi/whatever is going on here that it visually looks like. I have written a screen capture program, and using a few different examples for the RubberBand form (overlay form to select a region of the screen by drawing a box), and as you can imagine, this scaling crap is causing those box captures to be offset, and the contents are zoomed.
This is very annoying -- even to explain, however I am positive that most of you are familiar with the terms I use, and also know what to expect from taking a screenshot, so my explanation above should be pretty clear as to what my problem is.
Example/Consideration
Imagine, taking a picture of a window that is 300x300, and getting the top left 150x150 of that zoomed to 300x300 completely skipping the remainder of the window. Resulting image is still 300x300, but it's not what you selected.
Now imagine, you grab a picture of your screen by the only dimensions you can get programmatically, and then put the image into a picturebox. Even though both your screen and the picturebox claim to be the same dimensions and dpi, the image in the picturebox requires scrolling even if the picturebox is maximized to fullscreen on a borderless with no borders / etc. -- again, the picture is zoomed, but how is it still reporting that it's the same size as the form XD (comparing Graphics or BitBlt dimensions with the actual form. also tried comparing picturebox contents, and still same effect)
This, is EXACTLY what the effect is that is happening. When I try to capture a region or segment of the screen. I am not sure why windows api/crl is lying about this seemingly trivial stuff, however there must be a way to accurately obtain screenshots/capture regions without this faux zoom effect -- across all resolutions.
Thank you Hans Passant for pointing me in the right direction.
To add "true" dpi scaling support to a winforms application, you can make it so by adding the following block to your manifest :
Project > Add New Item > Visual C# Items > Application Manifest File
One the file has been added, open it up and look for a line like
</asmv1:assembly>
Whatever the "asmv" number is, (in the example above it is 1), use that to format the code:
<asmv1:application>
<asmv1:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv1:windowsSettings>
</asmv1:application>
Paste the above code (changing the asmv1 to whatever version the manifest is), just above the final closing line for the ""
Also, make sure your forms are set to AutoScale to dpi (and all sub-elements).
I'm using the wpf notifyicon (http://www.hardcodet.net/wpf-notifyicon)
When my laptop is at 100% dpi scaling, the left side of the context menu is centred on the tray icon, as expected.
When the laptop isn't at 100%, the context menu is pushed to the far right.
On high resolution laptop displays, 100% scaling is not the default.
Wherever my tray icon is positioned, that is, however far from the clock, the menu always pops up over the clock, as far to the bottom-right of the screen as is possible while remaining visible.
Note: I'm testing on a default installation of Windows 8.1. Also, the NotifyIcon that I'm using is the one that is generally recommended for anyone attempting tray functionality in WPF.
To reproduce: the problem exists in the windowless sample provided by hardcodet. I'm using wpf NotifyIcon without a window, and can reproduce easily in code or xaml. In fact, I cannot stop reproducing it. It occurs when dpi scaling is turned on, i.e. when a 1080p display is actually showing a lesser resolution, which is what windows does to stop applications having text too tiny to read.
Any ideas about how I can make the context menu appear in the expected place regardless of dpi?
Screen shots as suggested by kennyzx:
good behaviour. the m on red background (MEGAsync) has just been right-clicked
bad behaviour. the green tick, my notifyicon, has just been right-clicked and the menu appears over the clock
!good behaviour. the m on red background (MEGAsync) has just been right-clicked
!bad behaviour. the green tick, my notifyicon, has just been right-clicked and the menu appears over the clock
and some code:
var n = new TaskbarIcon();
n.Icon=new System.Drawing.Icon(#"C:\window - 64 - tick.ico");
n.ContextMenu = new System.Windows.Controls.ContextMenu();
n.ContextMenu.Items.Add(new System.Windows.Controls.MenuItem {Header="E_xit" });
Found the solution here: http://www.codeproject.com/Messages/4929452/Problem-with-context-menu-position.aspx
It is, with thanks to codeproject user Igorious:
Get the code for Wpf Notifyicon (http://www.hardcodet.net/wpf-notifyicon)).
In Hardcodet.Wpf.TaskbarNotification.TaskbarIcon.ShowContextMenu()
replace
ContextMenu.HorizontalOffset = cursorPosition.X;
ContextMenu.VerticalOffset = cursorPosition.Y;
with
var g = Graphics.FromHwnd(IntPtr.Zero);
var scaleX = g.DpiX / 96.0;
var scaleY = g.DpiY / 96.0;
ContextMenu.HorizontalOffset = cursorPosition.X / scaleX;
ContextMenu.VerticalOffset = cursorPosition.Y / scaleY;
Explanation (thanks to codeproject user yachting):
It's needed because WinApi.GetPhysicalCursorPos return the mouse position in pixel,
but WPF's measurement unit is device independent pixel (by definition, it's 1/96 inch)
You need to adjust the return value of GetPhysicalCursorPos by DPI (dots per inch) setting,
otherwise the position of the context menu will be incorrect if users set DPI other than the default 96.
WPF documentation and tutorials state that WPF is resolution independent which I understood shows a window in the same size in different resolutions (1600x1200 -> native and 1024x768) and/or DPI settings. However, when I tried a sample app. with different resolutions the sizes are different. On the net I found http://www.wpflearningexperience.com/?p=41, which use "native resolution" in order to see the same window size on different computers, however I could not understand the underlying concept.
Why native resolution for LCD is vital and resolution indepence is a term instead of DPI independence? Probably, I do not know/use terminology well, but I need a clarification in order to understand this issue.
I do not want to answer my own questions, but I think I got the point. Sorry for this premature question, but after a while I noticed the problem.
As far as I understand WPF uses System DPI (which you set by changing through Windows Desktop Settings) as a scale factor. For example in the tutorial above one of the computers have a native resolution of 1600x1200 and 96 DPI (94 actually as stated in the tutorial). Everything is fine because System DPI (96) is quite close to the real DPI (94) and WPF can use this information to scale your window.
As you know a Device Independent Unit is 1/96 inch and with the numbers above real pixel size (physical pixel on your screen) is multiplied with ( (1/96) * 96 ) which is equal to 1. So if you have a window with 300 DIU, then you will see ( 300/96 ) inch on your screen.
However, when you change your resolution without changing System DPI, here comes the problem which confused my mind. Say, you set the screen resolution to 1024x768 without changing the System DPI (still it is 96) and run the application again and you see a bigger window. This is the reqult of wrong System DPI and naturally wrong scale factor for WPF. WPF does not know much about your real DPI, it only uses the information you give to it which is System DPI. Let's recalculate our window size with this new settings. First we need scale factor which is ( (1/96) * 96 ) equal to 1. We can say that 1 logical pixel is also 1 physical pixel on screen. However, we changed the resolution and 300 pixel is not the same with the previous resolution. Previously we have 1600 pixel on the diagonal which is also 17 inch in length. However, we have 1024 pixel for 17 inch now. 300 pixel is almost 5 inch on our new resolution (1024x768), but only 3.18 inch in the previous resolution (1600x1200). Therefore, WPF cannot be resolution independent due to the wrong DPI value and draws a larger window with the new resolution.
So, how I fix the problem (in my words, I do not claim that this is an absolute solution)! When I change the resolution, I also changed the DPI value which is true for this new resolution. For example, for my own monitor the diagonal size is 17 inch with a resolution of 1024x768, I use the formula (1024 pixel / 17 inch) and find that my new true DPI is almost 60 DPI. I set the System DPI to 60 (through the Desktop Settings of course) and it works. Not perfectly, due to the rounding errors during the calculations, but in practice values can be considered equal.
WPF uses System DPI in order to be resolution independent and you need to set actual DPI (real DPI value for current resolution). You need to set DPI in order to help WPF to be resolution free. Finally (and I think very crucially) you have do one more thing, at least on Windows XP, you need a restart in order to enable your DPI settings with the new value. If you do not (as I did), WPF still make the calculations wrong and draw in different size.
These are my understanding and results from the tests I did, but I cannot claim they are absolute. I just want to share it with the people who may find this information useful. Please comment/edit my post if you find any error or think that needs improvement.
I have used 16x16 px images in my application, so that I get crisp edges and no automatic resizing at the standard dpi setting of 96.
When the user changes their dpi setting, the images get enlarged, and since the source files are only 16x16, they look naturally bad. Is there a way I can provide multiple images for a particular image source, and the best one will be chosen automatically? For example I provide images with the size of 16x16, 20x20 and 24x24 pixels, when the image's size is 16x16 [wpf units], so I have one perfect match for 96, 120 and 144 dpi?
What best i can think is to set the image source dynamically at run-time based on system's DPI settings. In code-behind you can set dynamically like -
ImageViewer1.Source = new BitmapImage(new Uri(#"\\myserver\\folder1\\sample.png"));
Listen to this event in your class to get notified about the dpi settings changed of computer - Microsoft.Win32.SystemEvents.DisplaySettingsChanged. Details of it can be found here - System Events
Also, you can get the system dpi value using the following code -
float dpiX, dpiY;
Graphics graphics = this.CreateGraphics();
dpiX = graphics.DpiX;
dpiY = graphics.DpiY;
Move this logic to a property and based on the property value, dynamically set the image source.
Does anyone know what measurement units are used by Silverlight/WFP? For example, if I create a new button and set its height to 150, is that 150 pixels? points? millimeters?
I design all of my applications in Adobe Illustrator before proceeding to code, and although I try and set everything to the dimensions in my Illustrator file, the Silverlight application is usually larger.
Although in theory, 1 unit in WPF is 1/96th of an inch, that's frequently not the case in practice.
It's usually true when printing. But it's rarely true on screen. The reason for this is that Windows almost always knows the true resolution of a printer, but almost never knows the true resolution of a screen.
For example, I have three screens attached to my computer. Windows thinks that they all have a resolution of 96 pixels per inch. Actually they don't. Two of them have a resolution of 101 pixels per inch, and one has a resolution of 94 pixels per inch. (Why? Because Windows has no way of working the true resolutions out for itself, and I haven't told it. The fiction that they all have the same pixel size is close to the truth, and turns out to be a convenient fiction.)
So when I create, say, a Rectangle in WPF with Width and Height both set to 96, the size of the Rectangle actually depends on which screen it appears on. Windows thinks that all 3 screens have a resolution of 96 pixels per inch, and so it'll render the rectangle as being 96 pixels tall and wide no matter which screen it appears on. That'll make it appear 0.95 inches tall on two of the screens, and 1.02 inches tall on the third.
So in practice, that means that units in WPF on my computer here are either 1/100th of an inch, or 1/94th of an inch in practice. (I.e., in practice, the size of 1 unit in WPF is exactly the size of 1 pixel on my particular setup, no matter how big the pixels happen to be.)
I could change that. I could reconfigure Windows - I could tell it the actual resolution of all 3 screens, in which case the nominal and actual WPF unit sizes would coincide. Or I could lie - I could claim that I have 200 pixel per inch screens, in which case everything would be massive...
The basic problem here is that there is no standard way for the computer to discover the true size of the physical pixels on the screen, and very few people bother to set it up by hand. (And in fact you can cause problems by configuring it 'correctly', because a lot of software doesn't behave correctly when you do.) So the majority of Windows computers don't report physical pixel sizes correctly to WPF - they can't because they don't know.
Consequently, there's no reliable answer to the question - 1 unit in WPF could be pretty much anything on screen. (In practice, most of the time, it turns out to be 1 pixel, simply because if you don't tell Windows anything else, it defaults to assuming that your screens have pixels that are 1/96th of an inch tall, which is the same as 1 WPF unit. And for most desktop screens, that's actually quite likely to be a good guess. But this isn't universal. On systems configured with what used to be called 'large fonts' for example, you'll find a different nominal screen resolution, and 1 WPF unit will correspond to slightly more than 1 physical pixel - about 1.2 in fact.)
With printers, it's all much more predictable. Printers are invariably able to report their resolutions correctly. So if you print something that's 96 WPF units high, you can be confident that it will be 1 inch high.
MSDN's documentation states that the FrameworkElement.Height property (for Silverlight) refers to:
The height, in pixels, of the object
However, for WPF it refers to:
a device-independent unit (1/96th inch) measurement
So, to answer your question... pixels for Silverlight, device-independent units for WPF.
The documentation refers to Pixels, however these are Pixels where there are 96 such pixels per inch. A line of Width 96 when display on a 120 DPI display will be 120 actual device pixels. Similarly such a line drawn on a printer output which has 600 DPI will be 600 pixels long.
They are Device Independent Units.
You can find more detailed explanations here.