Screenshot/picture/image size

[maarit_t]

Hi,

I've been trying to find a solution for a problem that I have with screenshots in the user manual that I'm editing with Help+Manual 8.

My problem is that the screenshots that I add to the manual are shown bigger that they are in reality. For example if I open them with Paint and then in Help+Manual side by side there is a huge difference in size. If I make the screenshots smaller in Help+Manual from picture properties it will affect the picture quality very badly.

How can I get the screenshots to display in same size that they actually are? I use bitmap images.

I'll try to attach an example image here. On the left image in Help+Manual and on the right image in Paint. Both are zoomed to 100%.

Thank you for your help and assistance!

Regards,
Maarit Tötterman

[Ty Griffin]

Hi Maarit—

In the Help+Manual editor, you should be able to (a) select the image by clicking on it, and then (b) grab a corner of the image—click and hold and drag, then release—to make it any size you wish, either larger or smaller than its original size. I just tried it with JPG, PNG and BMP images, and it worked fine and as expected. Can you not do this?

[Alexander Halser]

Hi Maarit,

The answer is simple: MS Paint is wrong.

Well, not exactly wrong, but it shows the picture at its original size. Let's assume that your bitmap is 100 x 100 pixels. MS Paint will display it at 100 x 100 screen pixels (that is: your display has physical dots and it maps 1 pixel of the bitmap to 1 pixel of the display). And that's wrong.

Your display has a higher resolution than most displays and Windows scales everything on your display to make texts readable. From your screenshot, I'd guess that your Windows scaling is set to 150%. My own laptop has an even higher resolution and scales at 200%.

This Windows scaling affects everything on your computer (almost, MS Paint is an exception): texts appear bigger, icons too. Most programs (if they are designed to scale to high resolutions) will increase their icon sizes, text, controls, everything. Even your web browser that you are viewing this post with displays the website at a 150% scale. Yes, 150% scale, despite the web browser still says that it is on "100%". So does every browser, MS Word, PDF viewers, you name it.

Except Microsoft Paint. This poor little program has never learned to deal with high resolutions and shows your bitmap image at its physical (= physical display pixels) size. And that's too small for your display. And that's why MS Paint is wrong.

Help+Manual does scale. When your Windows scaling is 150%, then H&M appears larger, the editor is larger and the editor content is larger as well. And this base value is called "100%" - in other words the "normal" size/magnification. Technically it is not true, it's already 150%. The pixels in the H&M topic editor work in the very same way as a web browser displays content: it calculates with logical pixels and scales the content as required - including texts, and pictures.

You do not want to see the picture in Help+Manual at its real physical pixel size. Because your web browser doesn't do this, either. MS Word doesn't do it, nobody does except MS Paint. It's more important (actually required) to keep the size of text, tables, indents and pictures in sync. This is how the documentation will look like at any scale.

Here's a screenshot of Help+Manual on my computer. That's a 200% Windows scale (=system wide base value). H&M says that the editor is displaying at 100% (replace with "normal" size). But technically, it's already at 200% like you web browser is on 150% when you view this picture.

[Martin Wynne]

You do not want to see the picture in Help+Manual at its real physical pixel size

Hi Alexander,

I do want that, and I have a script running in my H&M page template to make it happen. All images larger than icons are displayed dot-for-dot at their native size. The script sets the max-width to the native pixel size, recalculated to "undo" the high-DPI scaling. It works great -- everything in my webhelp pages is crisp, displayed at the original size. I create the original screenshots large enough to work fine this way on large screens, and the responsive 100% width scales them down on smaller screens. For line graphics PNG images the file size is not a problem, regardless of the pixel-size. The same is true for RLE (run-line encoded) bitmaps.

The standard Windows/browser up-scaling works fine for JPG photos and videos. But it is awful for screenshots, line graphics and CAD drawings. They go fuzzy when up-scaled and it gives me a severe headache having to look at them, especially a detailed engineering drawing.

Paint gets it right. It is a program for creating pixel-resolution line graphics and that is exactly what it displays.

cheers,

Martin.

[maarit_t]

Hi!

Thanks for all the replies and I think I now understand what the problem is. It is the Windows scaling that Alexander is talking about.

But the thing is that the original software that I'm taking the screenshots from is actually smaller than what it is displayed in Help+Manual. I need to find a way to work around this. I would actually want to see the real physical pixel size in Help+Manual as Martin writes.

Resizing that Ty was suggesting doesn't work, since the quality of the screenshot will be bad after that. It is all blurry and I don't want that.

I do want that, and I have a script running in my H&M page template to make it happen. All images larger than icons are displayed dot-for-dot at their native size. The script sets the max-width to the native pixel size, recalculated to "undo" the high-DPI scaling. It works great -- everything in my webhelp pages is crisp, displayed at the original size.

What is this script? Could you possibly help me to do the same? I think this is exactly what I need for my screenshots.


Regards,
Maarit

[Tim Green]

What is this script? Could you possibly help me to do the same? I think this is exactly what I need for my screenshots.

This will only help you if you are the only person viewing the documentation you write. If that is the case, then fine. Otherwise, you need to see it at the relative size that is correct on your screen, because then the relative size will be correct on everyone else's screen as well. If you mess around with the display so that it looks right for you, and only you, your documentation layout will look very different from what you expect on every other computer. Screenshots are relatively low resolution and will always look a little unclear on high-resolution monitors with the way operating systems scale. That is simply a fact of life.

If you really want to see it like that correctly, then go into your Windows display settings and change to 100%. Then the relative sizes will be correct, because everything on your screen will then be displayed 1:1, exactly as you want it. However, I suspect that you will not be very happy with the result. That is why scaling is used.

[Alexander Halser]

I need to find a way to work around this. I would actually want to see the real physical pixel size in Help+Manual as Martin writes.

Insert the image at its physical size (do not scale it with the mouse) and set the topic editor zoom to 67%. That's about the "real" size, because your Windows system is at 150% and that editor zoom of 67 scales it to (150 / 100 x 67) = 100.5%.

Paint gets it right. It is a program for creating pixel-resolution line graphics and that is exactly what it displays.

I know you are the last man standing defending pixel-perfect resolutions, Martin As long as you are the only person who's reading the documentation you write, that's perfectly fine. It's just not going to work in a world of 5K displays.

Let me give you both another example...

In Windows, text - size given in point - will grow or shrink with the Windows system scale. This is because by definition 1 pt = 1/72 inch. Windows at 100% system scale calculates each (logical) inch with 96 physical display pixels. At 200% it is 192 pixels per logical inch. This value is called dpi (dots-per-inch).

Windows at 100% scale: text in Arial, 20pt = 20 / 72 x 96 = 27 physical display pixels tall (that includes space below the baseline)
Windows at 200% scale: text in Arial, 20pt = 20 / 72 x 192 = 53 physical display pixels

So, text will appear larger on computers with a higher Windows system scale. If the elements that go with the text (images, tables, paragraph indents) were still using physical pixel values, this quickly goes out of sync. If a HTML table defines column widths in pixels and those pixels were treated by the browser as physical pixels, the columns would become too small to fit the text. Remember that text is specified in point and the point value will produce larger text on higher scales. It might still be readable at 150%, but at 300% you don't stand a chance.

There is one popular Windows application that still treats HTML content specified with "px" values as physical display pixels: Microsoft HTML Help viewer. If the HTML Help viewer - running on a Windows with 150%+ scale displays a HTML page that defines images and tables with pixel values (e.g. CSS "width:250px"), it treats that pixels as physical screen pixels. On high resolution displays, this look pretty awkward.

With H&M version 7 we introduced a new CHM export for exactly this reason. It does not specify pixel values, but writes point and inch.
And because a few users had complained bitterly about this change, you can switch off this feature, if you really want to:

chmexport-with-pixel-values.png

We do not recommend to turn off this setting, keep it on. If you turn it off, you should know what you are doing. Look what the Microsoft CHM viewer produces if the HTML specifies "px" values:

win96dpi.png

win192dpi.png

This is pretty contrary to how a web browser handles the same HTML page:

webbrowser96dpi.png

webbrowser192dpi.png

So, I hope I was able to make it a bit more clear to you what happens with all this scalation.

[Martin Wynne]

What is this script? Could you possibly help me to do the same? I think this is exactly what I need for my screenshots.

That will only help you if you are the only person viewing the documentation you write.

Hi Tim,

That is not the case. My script works for all users. It causes images to appear at their native dot-for-dot size on all browsers on all computers, regardless of their Windows DPI settings or monitor size, provided the screen is large enough. On screens smaller than the image, it is scaled down to fit. Or if the browser window is restored-down smaller.

It doesn't apply to small images such as icons which appear at their usual upscaled size.

I have tested it on several different computers in Windows at different DPI settings, in different browsers, and it works fine. Also tested in Firefox on Linux.

It's a simple enough script, *perhaps I should patent it?

I should perhaps add that every image in my webhelp is in a paragraph by itself. They tend to be large. I don't have small images which run-on within text in a paragraph. It should work ok for such images, but I haven't tested it. H&M allows you to add a CSS class to images if desired, and that could be used to control which images the script applies to, and which not.

*p.s. that was in jest, I can post something here if wanted?

edit: Alexander wrote:

I know you are the last man standing defending pixel-perfect resolutions, Martin As long as you are the only person who's reading the documentation you write, that's perfectly fine. It's just not going to work in a world of 5K displays.

I'm not the only person reading my docs. My image correction works fine for other users, and on 4K screens. I haven't got a 5K screen to test. But dot-for-dot means just that regardless of the screen resolution. Obviously if the physical monitor dot size gets smaller, so does the image.

cheers,

Martin.

[Alexander Halser]

It causes images to appear at their native dot-for-dot size on all browsers on all computers, regardless of their Windows DPI settings or monitor size

You have to go to great lengths to modify the image size at runtime in a web browser. For a regular web browser, there is simply no CSS setting that would make it scale the picture to physical screen pixel values.

Even a dedicated "px" CSS like <img src="xy" style="width:500px"/> will be 1000 physical screen pixels wide if the browser is on 200% zoom. And on a Windows system with a base scale of 200%, a browser zoom of "100%" is in fact already 200%.

It's certainly possible to factor in the browser zoom in a javascript at runtime and modify image sizes back to their native dot-for-dot size. I just wonder what this' for. As you said, your screenshots tend to be large and on screens smaller than the image, it is scaled down to fit anyway.

And that's exactly what this picture setting in Help+Manual does - it displays the picture at its (logical) native size but makes sure it doesn't become larger than there is space for it.

scale-image-max-width.png

[Martin Wynne]

You have to go to great lengths to modify the image size at runtime in a web browser. For a regular web browser, there is simply no CSS setting that would make it scale the picture to physical screen pixel values.

Well I don't know about great lengths. Here's a demo page which does it, containing large and small images:

https://85a.uk/images/image_demo.php

Try changing the Windows display DPI, or the browser zoom, or dragging the browser window size around. The images will remain at original size, or smaller.

The script can be copied from the page source. Call the function in the <body> tag. If you don't use "lazy" image loading, you don't need the onscroll call.

No doubt IT professionals will be able to clean up the script -- I'm a 74-year-old oily-fingered engineer. But it works fine for me and my users.

cheers,

Martin.