Relationship between pixels, centimeters and DPI. Relationship between pixels, centimeters and DPI 96 dpi

Encyclopedia of Plants 08.05.2022
Encyclopedia of Plants

Where did 96 dpi come from

Apple's high-density display craze has highlighted scaling issues with some Windows apps. Where did these problems come from and how to solve them?

Thus, 96 dpi is a virtual parameter obtained as a result of virtual calculations and averaging. It is calculated on the basis of an assessment of the user's subjective perception of the size of the letter depending on the distance and is a correction factor for the 72 dpi parameter, which, in turn, is simply a reflection of the fact that 72 points of one monitor with a certain diagonal and resolution (moreover, released on market for a very, very long time) is the same as the virtual inch used in printing. Complicated? Very.

Unlike this virtual parameter, PPI is quite real: it is the physical number of real screen pixels per inch, which is very easy to accurately calculate. This is the key difference between the parameters: one of them is virtual, and the other is quite real.

How is the Windows interface built, why did 96 dpi become the base, how is this base used?

Nevertheless, the 96 dpi parameter has become an essential element for building system and application interfaces. How did it happen?

At the time when Windows was just taking over the market, technology and the PC industry were not developing at such a crazy pace as they are now, but the development was going on, and then it seemed very dynamic. The standards for displaying images on the screen changed each other: CGA, EGA, and, finally, which became the last IBM standard, which was widely spread on the market. Monitor diagonals and available resolutions gradually grew. And the resolution gradually turned from a constant into one of the variables.

However, binding computers to paper continued to be one of the most important aspects of their functionality. Accordingly, the dpi parameter, which set the parameters of fonts and graphics when outputting to paper, remained relevant. Apparently, this parameter began to be perceived as a universal constant, and it was dpi that became the starting point for building the interface of the system and applications - both for text and for graphics.

However, at that time it seemed quite logical and reasonable. First, the resolution grew at about the same rate as the screen diagonal, i.e. the size of the element on the screen was approximately the same. Secondly, computer power was then in short supply, so it was not enough for complex interfaces. Vector elements were an unattainable luxury; fonts were raster, and the scale and size of interface elements were hard-coded once and for all. Well, the sizes of fonts and elements themselves did not come from the ceiling - they have been honed for decades on paper. In other words, binding to paper looked not only logical, but also convenient from the point of view of working with a computer.

At the same time, I want to remind you once again that the dpi parameter itself is virtual and has nothing to do with the hardware of the computer. The computer always draws an image in pixels and displays it on the screen at a certain resolution. By and large, he doesn’t care what diagonal to display the picture on, and even more so he doesn’t know how far the user is sitting from the screen, and this parameter was taken into account when choosing the most “favorable” dpi. Therefore, we need dpi as a parameter in two cases: when outputting to paper (then it sets the scale and organization of elements on a sheet of paper) and as a certain base value that determines subjectively convenient scale of image elements on the screen.

Since this random combination of monitor settings (image dimensions/resolution giving the desired PPI) and system (dpi) worked well, it was perceived as something permanent and unshakable. It was believed that the parameter dpi = 96 will always remain relevant. That is why one should not always blindly trust “good practice” - this may not be a general rule, but simply a successfully working combination of random parameters that will crumble like a house of cards if one of them changes. Actually, this happened with dpi: everyone believed in its inviolability so much that, in order to simplify life, they began to consider it as a constant. And when it was still necessary to change the dpi, a catastrophe happened to the interfaces. That's what we'll talk about.

Organization of the Windows interface, LCD screens and related complexities

So, dpi has become the base value, which formed the basis of all elements (text and graphics) and Windows OS, and applications. When the resolution was increased, the size of the elements in dpi remained the same, just more of them fit on the screen, and the visible size, i.e. how these elements looked on the screen, was determined by the ratio of the physical size of the screen and its resolution. For a long time, the resolution and screen size grew at about the same pace, so nothing terrible happened.

In principle, the concept of dpi staggered a little already as CRT monitors developed, because the required size / resolution ratio, even for them, was by no means always maintained exactly. As a result, on different monitors, elements on the screen had different visible sizes. But in most cases, small deviations were put up with, and in case of significant deviations from the “norm”, the monitors themselves came to the rescue. After all, CRT tubes worked well with several resolutions, so the problem could most likely be eliminated by setting a different resolution on the monitor - so that the visual size of the elements was closer to the coveted dpi. Therefore, most users perceived too small or too large a picture not as the wrong scale, but rather as the wrong resolution for a particular monitor. For example, remember 800x600 vs 1024x768 for 14" monitors?

This method stopped working with the transition to monitors with LCD matrices, because they are able to work well with only one resolution. And already at the second step of development, LCD monitors showed how much they can ruin everyone's life.

For the first time, PC users globally faced the problem of scaling when LCD monitors with a diagonal of 17 inches and a resolution of 1280 × 1024 pixels began to enter the market in bulk. I think many readers remember the problems with setting them up. In pursuit of beautiful specifications, manufacturers chose a higher resolution, but as a result, the size/resolution balance for this type of matrix turned out to be extremely unfortunate: the pixel density turned out to be too high, and with standard monitor and system settings, the image of elements on the screen was too small for comfortable work. It turned out that scaling in Windows does not work well.

It got to the point that users out of desperation lowered the resolution by a step, although for LCD monitors this had very unpleasant consequences: the image became fuzzy, the fonts were blurry, and the eyes still hurt. To all the trouble, the resolution of 1280×1024 implies a non-standard aspect ratio: 5:4 instead of 4:3, i.e. when the monitor was switched to 1024×768, the proportions were also violated. Here's an unfortunate set of circumstances...

Then 18-inch and 19-inch monitors appeared on the market with the same resolution, on which the size of the screen elements was already more decent, which reduced the severity of the problem. However, the broad masses have already received an object lesson that the ability to scale interfaces on the screen is not a luxury, but a necessity. Moreover, with the spread of LCD matrices, the good old way of “changing the screen resolution” no longer worked, i.e. only the software setting of the system remained. It’s easier and more convenient, and there are much more customization options. It all seems so obvious now because we're used to it. But for a long time it was believed that it was necessary to change not the scale of the picture, but the screen resolution ...

However, scaling in Windows is not as easy as it seems.

Difficulties of interface scaling

The interface of the system and applications consists of a large number of different elements. However, they are calculated in different coordinate systems. For example, fonts are considered in the same dpi (everything can be more complicated there, but for simplicity we will take that this is their only parameter), and graphic elements - directly in pixels.

An icon on the desktop is a simple bitmap image with a rigidly fixed size in points (pixels), for example, 32x32, and it will remain that size (as far as I remember, now there are options for 16x16, 32x32, 64x64 pixels). , but it's just another icon drawn in a different size; more on creating icons, ). The interface looks holistic only as long as the proportions of the text and graphic components specified by the creator are preserved.

Let's take the simplest example: the interface has a dialog box, on it is a "save changes" button, the background of which is a bitmap image. Suppose we set the graphics scale to 100%, and dpi = 96, and under these conditions we drew the interface. All elements are perfectly fitted to each other and look great. Now let's set dpi=120, what happens? The text will become larger, but the size of the button will remain the same - that is, the text will crawl out of the space allotted to it. Now imagine that the entire rendered window is a bitmap, and set the scale to 120%. Both text and background images will become blurry and lose their sharpness. This interface looks sloppy and unpleasant. Actually, these are the two main problems when scaling interfaces, and below we will talk about how they were and are being solved in Windows.

Device Zoo

Apple controls both the devices (and solely) and the software platform. Therefore, firstly, it can decide for itself which solutions and with what parameters to bring to the market, and secondly, it can support a limited range of products, choosing the best (in its opinion) ratio of parameters. This, among other things, makes life easier for both the company itself and third-party developers in terms of creating and optimizing the interface.

The Windows platform is built on completely different principles, the essence of which is the diversity of manufacturers of components, software and devices, united only by a common operating system. Matrices and monitors for desktop computers and mobile devices on Windows are produced by a variety of manufacturers, so there is a huge number of screen sizes and resolutions available, and new ones are constantly being added, and the old ones are no longer relevant. Therefore, software developers simply cannot test all options and are forced to create interfaces according to the most universal principles that will allow them to work on any type of monitor. Until recently, the only constant parameter was dpi, and software manufacturers had to pray that monitor manufacturers would choose the ratio of diagonal and resolution so that 96 dpi roughly corresponded to their PPI.

However, in real life, hardware manufacturers look back on marketing numbers more than on their software counterparts. For example, I would like to throw a grenade at the camp of monitor manufacturers: these guys with a clear conscience produce monitors with the same Full HD 1920 × 1080 resolution, but with a matrix diagonal from 21.5 to 27 inches. Moreover, finding a good 27-inch monitor with Full HD resolution (which suits me best due to not very good eyesight) until recently was not so easy, and the price there was appropriate.

However, even the current situation can soon be called "good old days." Apple has flagged the idea of ​​dramatically increasing the number of pixels per inch and is actively implementing it in all of its devices. The new standard is already accepted by the market, and to keep up, the Windows platform has to move in the same direction. This forces us to look for completely different approaches to interface design and creates a lot of new problems.

Moreover, Microsoft itself boldly took a step further by including tablets in the paradigm: i.e. now we have the same operating system (Windows 8) with the same interface should not only work, but provide high usability and a similar experience on any screen, from a 10-inch tablet at 1366x768 resolution (which was originally stated as the minimum standard resolution for the system, but now Microsoft has reduced this requirement to 7-inch screens and 1024x768 resolution) and up to ... well, let's say it's a 30-inch (actually taller) monitor with a resolution already higher than Full HD (2560x1600, for example).

Thus, Full HD (1920×1080) is also by no means the limit. But the main humor of the situation is not even in this, but in the fact that a Full HD screen can be on a huge 27-inch monitor (or a TV with an even larger diagonal), and on an 11-inch tablet screen.

Games as an example

So, I think many readers have already come to the conclusion that the ideal solution would be to create an interface from fully scalable elements. To illustrate this approach to solving the problem, let's take another example from the history of the ancient world: the evolution of computer games. Initially, they often looked like this: a backdrop rigidly drawn to the desired resolution (in fact, a picture like wallpaper) plus sprites - bitmap images of a fixed size, and fixed in pixels (you can indulge in nostalgia on msdn). In other words, in fact, the same desktop icons with a fixed size in pixels or bitmap fonts. Sprite animation was carried out due to the fact that in place of one sprite another was placed, also pre-drawn. How the scaling of the sprites was carried out, I, perhaps, will not tell - I will save the readers' nerves.

In principle, even all the favorite 3D The games of our childhood, starting with Wolfenstein 3D, used sprites. The unforgettable Duke Nukem 3D can be called as their swan song. This is perhaps the last successful game in which the monsters were sprites, despite the fact that the game world itself has been really three-dimensional for quite some time.

A static sprite can be drawn and even animated beautifully, but here's the problem - only for a certain resolution and a certain scale. It won't scale up. Actually, terrible large pixels of sprites are just an example of unsuccessful scaling. Therefore, gradually in games they began to be replaced by vector images of people and cars. So you can build full-fledged two- and three-dimensional models with all the pluses (the ability to deploy them as you like, scale them, etc.), but also the minuses (they require significant computing resources to calculate). In general, this was the impetus for the development of all three-dimensional video cards, which are now pathetically called GPUs. The world in games has become fully scalable, and as a bonus - fully three-dimensional - but at the cost of a strong increase in computing resource requirements. Since then, there has been a constant race: as the computing power of hardware grows, the quality of processing and complexity increases, which increases the requirements for computing capabilities - and so on.

On the left - the original game with sprite monsters and textures typical for that time, on the right - the result of the work of the fans, who also brought the monsters to a three-dimensional look.

However, we do not pretend to have a three-dimensional interface yet. It is important for us to understand that raster image icons are not suitable for the modern concept of displaying an image, and if so, we need to create a new paradigm for building an interface in which all elements can freely scale depending on the current ratio of resolution and screen diagonal. And this task will be more difficult than Apple's (they only needed to redraw icons with twice the resolution). Although, in general, when solving this problem, bypass technologies are still used almost everywhere.

So, in the first part, we assessed the total number and scale of tasks facing the developers. In the next, second part, we will look at how the interface scaling problem is solved in Windows - both for the traditional desktop and for the new interface (which used to be called Metro).

As you all know very well, the W3C in the CSS 2.1 standard gives us absolute and relative units of measurement to set sizes, in particular fonts.

The absolute ones are:

  • ininches, inches. 1 inch = 2.54 centimeters
  • cm- centimeters
  • mm- millimeters
  • ptpoints, points. 1 point = 1/72 inch. What is in the Word drop-down list when choosing a font size is the items
  • pcpicas, peaks. 1 spades = 12 points

For relative:

  • emfont-size, the height of the corresponding font (). There was also a definition of em - as the width of the character m.
  • exx-height, character height x corresponding font
  • px- pixels

You noticed?
Pixels are relative units of measurement!
How did you not know? :)

The CSS 2.1 manual explains:

Pixels are relative to the resolution of the viewing device, i.e. most often - a computer display. If the output device's pixel density is very different from that of a typical computer display, the user agent must rescale the pixel values. It is recommended that the reference pixel be the visual angle of one pixel on a device with a 90dpi pixel density at arm's length from the reader.

This is theory.

Now for some practice.

Open our favorite Windows in the Control Panel. In the properties of the "Screen" look at the tab Settings -> Advanced -> General:

96 dpi (dots per inch). This is a typical density (dpi) for monitors with a resolution of 1024x768 or so.
Why do we need this option? 96 dpi means there are 96 pixels per inch of your monitor. No, you don't need to reach for the ruler, the real value depends on the monitor, you can take our word for it. This parameter is required to convert the physical dimensions of the monitor matrix (inches, centimeters, millimeters) into pixels and vice versa.

And now about how this post began.

Change resolution 96 dpi (Small Font) to 120 dpi (Large font) and see what your favorite Internet will turn into. And that's not to mention programs written for 96 dpi resolution.
The whole problem is that the sizes of fixed elements, such as images, windows and areas, are set in pixels, and font sizes are usually in paragraphs.

And although in theory, PA ( user agent) should scale the pixels, in practice the pixels remain absolute.

Given the widespread use of monitors with a diagonal of more than 17″, more and more users, instead of increasing the default font size, increase the density, abandoning the standard 96 dpi.

Such non-standard tastes of the client are manifested in page templates, in layout elements with sizes specified in pixels. A line of text, or even a word, can easily not fit into a fixed-width column. Therefore, if you cannot get rid of fixed sizes, font sizes should be set in pixels, not in relative units.

For example, at standard density 96dpi, the 14 pt font has a height of:

H=14*96/72=18.666px~ 19px

And at a density 120dpi, the 14 pt font has already a height:

H=14*120/72=23.333px~ 23px

The conversion from points (pt) to pixels (px) is done from the ratio 1 pt = 1/72 inch:

These are the relative pixels :)

P.S. While the guys from the W3C are theorizing, it has long been necessary to transmit in the cgi request, along with the User agent, such parameters as screen resolution, browser display area sizes, dpi and color depth. And on the server side, just select the desired template. After all, we do not live in the 20th century.

DPI - (dots per inch, dots per inch) - a characteristic of screen resolution, which shows how many dots of the screen correspond to a logical inch. The screen resolution is set using the "Display Properties" - "Settings" - "Advanced" - "General" - "DPI setting" dialog.

1C:Enterprise version 8 considers screen resolution for scaling all controls and other interface objects. Due to inaccuracies in Windows system font scaling, there are some considerations when designing forms for different screen resolutions.

Development in normal resolution

The default resolution set in Windows OS is 96 DPI (Normal Size). Resolution 120 DPI (Large Size), usually used to increase the image of icons and fonts. At this resolution, the letters of the font are displayed with more dots and therefore become larger and easier to read.

But with increased resolution, about 30% less information is placed on the screen than with normal.

Designing forms is only recommended at 96 DPI, not 120 DPI or any other screen resolution. If you do not follow this recommendation, then when scaling a form from 120 DPI to 96 DPI, the text of some controls may not fit within the allocated boundaries, which will lead to a distortion of the meaning of the information displayed by them (for example, the appearance of ellipsis at the end of the text).

Figure 1 shows a form designed at 120 DPI. Figure 2 shows the same shape at 96 DPI. It can be seen that at 96 DPI the inscriptions "Name" and "Indicate the month in words in the document date" did not fit and end with ellipsis, and the command panel is so small in height that standard buttons do not fit in it.

Picture 1

Figure 2

Reserve for other resolutions

Due to inaccuracies in scaling system fonts, it is recommended to make the margins a little wider than necessary, leaving a margin of several points (2-4 points is enough). The height of the controls does not need to be adjusted. Figures 3 and 4 show the shape designed at 96 DPI and how it will look at 120 DPI respectively.

You may notice that the text of the radio button box does not fully fit into the allotted size at 120 DPI. To prevent this from happening, it is enough to make this field two points wider.


Figure 3


  • Translation

Windows, starting with Vista, provides two mechanisms for adapting applications to high pixel density (dots per inch, DPI) monitors: larger system fonts and full-scale window magnification. Unfortunately, trying to get some of your applications to work in either mode may fail, thanks to a combination of negligent developers and bad decisions made by Microsoft.

This page is intended to help users understand and fix possible issues when setting high DPI settings. Please note that we will only cover traditional Windows apps, not Windows Store ("Metro", "Modern UI") apps. The latter use the new WinRT API, which provides its own scaling mechanism.

From the translator

In this article, the following abbreviations are used, which I considered not appropriate to translate: Graphical User Interface (GUI), Dots Per Inch (DPI), DPI-Aware applications - applications that can display their GUI correctly, without distortion, at various DPI values, Graphical Device Interface (GDI). My comments (highlighted in italics).

Scaling Methods

Traditionally, native Windows desktop applications use two display mechanisms:
  • Graphical Device Interface (GDI) functions for display access. Typically, GDI coordinates are measured directly in screen pixels, regardless of monitor size and pixel density.
  • And text output using Windows system fonts. This is optional, but most applications use system fonts for most of their graphical user interface (GUI).
Initially, most monitors had a pixel density of around 96 dpi. So the GUI using this feature looked pretty much the same on any system. But, as the pixel density increases, the GUI elements of such applications decrease in terms of centimeters or inches. (real, which are measured using a ruler attached to the monitor). Small text and other fine details become increasingly difficult to see.

To remedy the situation, Microsoft decided it would be a good idea to build some sort of scaling method into Windows. One of the two methods described below (Windows XP or Vista) applies when the user sets the DPI to a value higher than the standard 96 dpi. Both methods attempt to increase the size of image elements.

Windows XP style scaling

The first of these methods, as you might guess, appeared in Windows XP. This method is not actually a GUI application scaling method per se. Only system fonts and some system UI elements are scaled at higher DPI settings (I would call it "NOT scaling method" in Windows XP style).

All other application elements are still displayed in 1:1 scale. The only difference in their appearance is that any text and some GUI elements displayed using system functions suddenly become larger. For example, text on buttons. This causes obvious problems which we will discuss a little later.

Windows Vista style scaling or DPI virtualization

Windows Vista introduced a second option with a strange name, "display scaling," without any clarification, apparently to completely confuse users. We will use a more descriptive name, the virtualization DPI method. When this method is enabled, Windows still performs Windows XP style scaling. As before, the sizes of all system fonts and some elements of the system interface are increasing.

The difference is that applications that can correctly use high DPI values ​​must tell Windows to do so. Such applications should set the new DPI-Aware flag, either by calling the "SetProcessDPIAware" Win32 API function, or preferably by inlining the manifest with the dpiAware flag. But if the application does not have a DPI-Aware flag, Windows behaves differently, first it forms an internal display at a scale of 96 dpi (emulating a DPI of 96 for the application), and then scales the resulting image to match the current DPI settings before displaying it on the screen.

This would be a fantastic scaling method if all of our monitors had the pixel density of the latest iPhones (326dpi). Unfortunately, this is not so. Application windows scaled this way look too blurry at the popular 120 dpi resolution (@homm that's not a resolution btw). Therefore, Microsoft disables DPI virtualization by default if you choose a pixel density less than or equal to 120 DPI.

How to change DPI settings

In Windows 7/8, open Control Panel and then select Appearance and Personalization, then Display, and finally select either Set Font Size (DPI) (Windows 7) or Custom Size Options ( Windows 8). You will see the following dialog box (Windows 7, Windows 8 is almost identical):


In the drop-down list, you can select the desired DPI setting as a percentage, where 100% corresponds to 96 DPI, 125% - as in the screenshot, corresponds to 120 dpi (you can more accurately write the value manually). Prior to Windows 8, the actual DPI ("pixels per inch") value was displayed next to the system font size. Windows 8, for unknown reasons, does not show the DPI value, so you have to calculate it yourself.

You can also add a ruler (which has a scale in inches) to the screen, and try to match the markings on it with the markings on the screen by changing the value in the drop-down list. The checkbox circled in red at the bottom determines whether to use only Windows XP-style scaling, or also the new DPI virtualization method. If the checkbox is unchecked, as in the screenshot, then DPI virtualization is enabled.

Declamation. This dialog box is an example of a non-user friendly interface. At first glance, this appears to be a checkbox to disable Windows XP style scaling. But this scaling method (which only increases system fonts and other system user interface elements - Windows XP scaling) is always enabled when a high DPI is selected. Actually this flag controls whether this method will be the only one (Use only scales in the style of Windows XP), or the "DPI virtualization" method will also be applied for applications that do not have the DPI-Aware flag. So this checkbox does not control the scaling method specified in its name, but controls another scaling method not mentioned anywhere - and allows the new method to be used when the checkbox is unchecked!

Error in Windows 8. In addition to this, in Windows 8 this is an error dialog. As a rule, everything works as in Windows 7, but the state of the checkbox is not saved at DPI values ​​of 150% and higher. When you check this box, "DPI virtualization" is properly disabled. However, the checkbox itself remains unchecked the next time you open this dialog.

Changes in Windows 8.1, or why everything is blurry?

In Windows 8.1, the Windows XP-style scaling flag has disappeared, and now "DPI virtualization" is never used at DPI values ​​up to and including 120, but is always used at higher values ​​for those programs that do not have the DPI-Aware flag. If some applications seem fuzzy to you, you must manually disable DPI virtualization for them.

Windows 8.1 allows you to use multiple monitors with different DPI. However, this feature also forces the use of "DPI virtualization" for traditional applications that move between monitors with different DPI values. To avoid this, you can disable "DPI scaling" in the settings using the new option "I want to select the same scale for all displays".

Windows 8.1 also adds a dedicated switch to set 200% and a new API so that developers can selectively disable "DPI virtualization".

Help, my system fonts are not the correct size!

Sometimes, after changing the DPI settings, you may notice that some system fonts have become too large or too small for new settings. The likely reason is that you are using a custom desktop theme based on your old DPI settings. Windows does not scale custom theme fonts.

If you actually created a custom desktop theme and want to keep it, you'll have to adapt the fonts yourself to the new DPI settings. However, Windows has an annoying habit of "helpfully" creating custom themes without your knowledge, for whatever reason. So if you've never created a custom desktop theme just delete it and go back to the default theme.

In Windows 7/8, open the Control Panel, select "Appearance and Personalization" and then "Personalization". If you see the selected entry in the My Themes row, this means that Windows is using a user theme whose system fonts Windows will not scale. Select a default theme, such as the first entry under Aero Themes (Windows 7) or Windows Default Themes (Windows 8), and delete unwanted entries under My Themes. Now, all system fonts should display correctly.

Application types, how they scale (or don't scale)

Now let's look at what methods should be used for existing Windows applications at high DPI values. The following table summarizes, later we will consider the various cases in more detail.

Applications don't care about DPI at all are either very old or badly written, but nonetheless still in use. One famous example is Apple's iTunes for Windows. Here, developers use system fonts for the GUI, and without caring about actual font sizes, they hard-wire window sizes to 96 DPI, naturally distorting the GUI when font sizes increase at higher DPI values.

Such applications require a new method of scaling "DPI virtualization", unfortunately this often makes the interface blurry. Otherwise, you'll run into problems ranging from text clipping to overlapping controls, sometimes rendering the GUI completely unusable (luckily, this rarely happens). Over the years, I've collected several sample screenshots of buggy apps.

Example application, only works with DPI equal to 96

Resolution 150% (144 DPI)





Applications that can adjust their GUI to different DPI values, but do not have a DPI-Aware flag- These are typical applications from the Windows XP era. Here the developers have taken care to get the actual system font sizes before creating the GUI. Such applications display correctly when using Windows XP style scaling. Unfortunately, since they don't set the DPI-Aware flag to tell Windows this fact, they will default to "DPI virtualization", making their GUI fuzzy. You may not like this, so you may want to force the Windows XP scaling style for such applications.

An example of such an application and a resolution of 150% (144 DPI)





Applications that can adjust their GUI to various DPI values ​​​​that have a DPI-Aware flag- This is the latest type of application that is completely hassle-free, regardless of DPI settings. The DPI-Aware flag is set automatically for Windows Presentation Foundation (WPF) and GDI+ applications because these APIs provide built-in scaling. Developers using the old GDI API and (surprisingly) Windows Forms need to manually mark their DPI-Aware applications.

Applications that are not DPI capable but have the DPI-Aware flag is even worse than completely ignoring the DPI value. In the examples, you will find GUI applications scaling well up to 120 DPI but no higher, or JavaFX applications. Here we can't do anything anymore, because. we have no way to force Windows to use DPI virtualization for such programs. Once the DPI-Aware flag is set, the application must scale itself. We can only "saw" developers to fix their product - or use something else.

Choosing a scaling method for your applications

Once you've decided that you want to use a high DPI setting, your choice of scaling method depends on the applications you're running. Keep in mind that to disable "DPI virtualization" means to check the box (check box) with the incorrect name "Use Windows XP style scaling" and vice versa.
  • If you're so incredibly lucky to only use applications that are both DPI-Aware and set the right flag, then it doesn't matter which scaling method you choose. All applications will use Windows XP style scaling and DPI virtualization will never be used.
  • If you only use well-written DPI-Aware applications, but some of them do not set the necessary flag, you can disable "DPI virtualization". Thus, all applications will be displayed correctly without any blurring due to scaling. If your monitor has a very high pixel density such that scaled bitmaps no longer look blurry, you may want to enable DPI virtualization anyway.
  • If you have one or more applications that are not DPI capable and do not have the DPI-Aware flag, you must enable DPI virtualization if you are not prepared to put up with skewed application GUIs. Unfortunately, another problem arises here, because, Microsoft implemented this option in an inconvenient way. You can enable DPI virtualization only for the entire system, not for a single application, and then selectively disable for individual applications.

We remind you that in Windows 8.1 there is no longer a choice in this matter. If you're running at 120dpi (125%), every program will be forced to use Windows XP-style scaling, and if you're running at a higher resolution, every program that isn't DPI-Aware will default to " DPI virtualization.

Eliminate DPI virtualization for individual applications

Once you've decided to enable DPI virtualization or you're running Windows 8.1 at more than 120 dpi, you can check your system for DPI-Aware applications that don't have the appropriate flag. And give them back the ability to use Windows XP-style scaling for which they are designed. There are two ways to do this, the first one works only for 32-bit applications, the second one is universal and suitable for 64-bit applications as well.

32-bit applications- It's easy: right-click on the executable in Windows Explorer, select the Properties dialog box, go to the Compatibility tab, and check the "Disable image scaling on high screen resolution" checkbox. That's it, in Windows 8.1 it also works for 64-bit applications.

64-bit applications- For no apparent reason, perhaps to annoy users of 64-bit applications, in Windows 8 and earlier, the checkbox mentioned above is disabled for 64-bit applications, although the option itself is quite functional if you make changes directly to the registry! So, start the registry editor and navigate to this key:

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers

Now add a string value (REG_SZ) whose name is the full path to the application executable and whose value is HIGHDPIAWARE. I recommend that you change a few 32-bit applications first, as described above, so you can see some sample values ​​in this registry key.

We've looked at how DPI settings can be used on Windows Vista and later. And if you ever wondered what the compatibility option is for - "Disable image scaling on high screen resolutions". And why it doesn't do anything on your system, you now know: it's only effective if you have the system-wide "DPI virtualization" option enabled, and only for applications that don't set the DPI-Aware flag properly, but still correctly use scaling in Windows XP style.

16.12.2009

To begin with, I suggest you conduct a small experiment. Create or open a document with default page sizes in any program. Usually it will be A4 format - 210297 mm. Now make sure that the display scale is 100%, that the orientation is portrait and that the view matches the future printout (for OpenOffice this is "Print Layout View"). Done?

To begin with, I suggest you conduct a small experiment. Create or open a document with default page sizes in any program. Usually it will be A4 format - 210 × 297 mm. Now make sure that the display scale is 100%, that the orientation is portrait and that the view matches the future printout (for OpenOffice this is "Print Markup View"). Done? Then take an A4 sheet and try to match its outline with the screen. With a probability of 99.9%, their sizes will not match, and the difference will not be 0.01%, but much more significant.

The resulting discrepancy is due to the user interface model implemented by the creators of operating systems and applications. Indeed, in order to display something on the screen, while maintaining the actual size of the document, you need to take into account not only the size of the display, but also its resolution - how many pixels fit per unit length vertically and horizontally. The developers thought and thought, then, apparently, they sent a junior laboratory assistant (or maybe Bill Gates himself - young and energetic) to determine the dimensions of a typical screen. He returned with numbers. We divided the length by the number of pixels and got 96 dpi (it was a matter in America where inches were in use, and 1 inch = 25.4 mm). And someone said it was good. And he called the magic number "logical resolution."

And now attention! The correct answer (quoting a document from the Microsoft website from the developer section - http://msdn.microsoft.com/en-us/library/aa970067.aspx): "The default dpi parameter is 96. This means that 96 dots occupy the width or height of one imaginary inch. The exact size of an "inch" depends on the size and physical resolution of the monitor. For example, if a monitor is 12 inches wide and has a horizontal resolution of 1280 dots, then a 96 dot horizontal line expands to a length of about 9/10 inch.” The key word here is "imaginary". Consequently, our inch turns out to be elastic - it stretches or shrinks depending on the physical dimensions and resolution of a particular monitor.

It should be noted that the value of 96 tnd for many years significantly exceeded the real capabilities of monitors. The typical physical resolution of most models was 72 dpi (it still remains the logical resolution in Mac OS), it even got the phrase “screen resolution” attached to it. This is what is set for screen fonts, as well as for standard low-resolution images displayed in layout programs instead of “linked high-res”. With the same discreteness, they make graphics for the Web.

In addition, even after installing the drivers supplied with the monitor, the computer could not accurately find out the actual dimensions of the image area, because on CRT monitors it is customizable and usually does not stretch to the entire screen without borders, since it was at the edges of the display that geometry distortion and information were maximum. Nobody wanted to see this - it's better to leave small black fields. So, if a layout designer or designer wanted to display an image of exactly the size that it would be printed later, such a simple option as setting 100% was not suitable. Alas, it does not fit now.

Meanwhile, after the advent of LCD monitors, a simple solution became possible for the problem we are considering. Because flat panel displays have an inherently perfect geometry, their pixels are aligned once and for all. There is only one physical resolution at which the picture is optimal (it should be chosen by those who are engaged in layout or design). Its value, as well as the dimensions of the display area, are known to the computer with high accuracy. But then why is "Scale 100%" still not working as it should? Apparently, because no one has specifically thought about it yet.

I think it would be necessary to add a small button "Bring screen scale to print scale" somewhere among the parameters. Yes, the title is long. Or maybe - "Equalize the sizes on the screen and when printing"? So, it probably sounds better.

And what exactly is this button supposed to do? The answer is simple: just recalculate the ratio between logical (96 dpi) and physical screen resolution, and then set the appropriate scaling factor for the user interface.

That's the theory. But the criterion of truth is practice! So, picking up a ruler, I measured the width of my laptop screen. It turned out 284 mm, or 11.18 inches, - almost like in the Microsoft example. Horizontal resolution - 1280 dots. In dots per inch, this would be 114.5. Therefore, I need to change the existing display scale to 119.27% ​​(i.e. 114.5 times 100 divided by 96). The laptop is running Vista OS. I select "Control Panel Personalization Change Font Size" (in fact, the values ​​​​of all user interface elements and applications that support this will change). I click on "Special Scale" and set "119%" (alas, you cannot enter a fractional scale). I return - a new line "114 dpi" appeared. Now it remains to reboot the laptop and check ... It worked!

P. S. One of the users who discussed this method in LiveJournal suggested just ... remember at what scale the dimensions of the sheet correspond to the real ones.

We recommend reading

Top