DPI scaling issues about openlivewriter

[panjkov]

I have that also, running on Lenovo W540 on native resoution 1920 x 1080. I attributed that to my customized theme I have on my Orchard blog...

[RobDolinMS]

AFAIK @shanselman has also hit this issue.

[dotMorten]

@RobDolin I tried taking a look but the designer is crashing for every single control. Is this a known issue or just my PC?

[timheuer]

@dotMorten the controls are developed not always using the best designer-friendly code. Some crash for me as well. You'll see even in the ones that open, custom layout manager code was used so the UI shown in the designer really isn't representative anyway.

I think the issue here is in Ribbon which doesn't have a great design experience anyway.

Jump to the codez!

[dotMorten]

@timheuer Thanks. Was poking around in the style selector code, but can't make much sense of how the combobox control ends up looking the way it does. Lots of spaghetti code to weed through to find the right spot to tweak.
Any pointers where to go look would be much appreciated

[shanselman]

There's a few separate High DPI issues, this is one. The one that bugs me
is that images are shown at 100% while text scales to the ambient dpi.

On Wed, Dec 9, 2015 at 3:38 PM, Morten Nielsen [email protected]
wrote:

@timheuer https://github.com/timheuer Thanks. Was poking around in the
style selector code, but can't make much sense of how the combobox control
ends up looking the way it does. Lots of spaghetti code to weed through to
find the right spot to tweak.
Any pointers where to go look would be much appreciated

—
Reply to this email directly or view it on GitHub
#44 (comment)
.

Scott Hanselman
Donate to fight diabetes: http://hnsl.mn/fightdiabetes

[dotMorten]

@shanselman I couldn't find the issue for the related image-size issue. Is it logged?

[randrey]

This may be not related to screen resolution at all. OLW creates these images by generating and rendering html file inside an in-memory browser control and capturing output as a bitmap image.
The html contains a p and h1-h6 elements with the text "AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz". It also links a stylesheet file, which defines few styles and sets default fonts:

body
{
    font-family: Calibri, Trebuchet MS, Helvetica, Arial, Sans-Serif;
    font-size: 11pt;
}

The browser should fallback to a default font even none of the listed is available in the system. So I don't think it's a lack of fonts issue. But to be sure, can you check which ones you have installed?

The image then gets cropped into smaller pieces to match ribbon buttons (i.e. "Heading 1" gets pre-rendered h1). These smaller bitmaps are cached in the %APPDATA%\OpenLiveWriter\blogtemplates. You may want to check what they look like.

I myself can't reproduce this. If anyone wants to take a look, check out OpenLiveWriter.PostEditor\Commands\SemanticHtmlGalleryCommand.cs.

[kathweaver]

I just installed the nightly build with the Blogger fix, and this appears to have been fixed with the new version also. I was seeing it in the past, but not now.

[willduff]

@kathweaver There haven't been any changes to this code, so there must be an environmental/configuration difference. Did you change your blog theme? Toggle the 'Blog theme' button in Writer? (See picture below). Change your computer resolution? It's also possible that the output is just non-deterministic, such that sometimes the screenshot looks good and sometimes it doesn't.

Personally, I only hit this issue very rarely. I'm on a Surface Pro 3 too, like @dotMorten. I think the main cause of issue here is mainly due to the blog theme. If anyone has a consistent repro with a freely available blog theme, please let me know!

Thanks @randrey for looking through the code and writing that up. We should collect knowledge like this in the wiki. I'll try and put something together but still working through a long backlog of items.

[kathweaver]

Yes, it's definitely the theme for me. The theme that is causing some other problems too. Typepad Nimble Design Lab theme. I'm leaving http://blogs.kweaver.org/blog/ with that theme on it so you can see what is going on.

Typepad blog themes are not working correctly #34 is the issue.

Just installed the UWP app on Surface Pro 4.
The blogger setup didn't bring over the theme and the HTML themes are borked.

However, same session with my wordpress site is peachy.

[toobob]

any progress on resolving High DPI/4k image rendering? i found this work around for photoshop, but it didn't work for me ( https://www.danantonielli.com/adobe-app-scaling-on-high-dpi-displays-fix/ ). for those of us who use a lot of photos/images, it's a real problem as the photos/images are too tiny to see until posted.

DPI stands for dots per inch. That is only applicable in the “view”, which means, on your screen (not on the website, which would be the presentation). Dots Per Inch is how many pixels on the screen in one inch. DPI for graphics tends to relate to printers, as it describes the number of individual ink dots that a printer places on a single page. You need higher resolution images, not the application to change the image size depending upon DPI.

There are only pixels. DPI is a relative term, and only applicable to the “view”, whether that view is the end user’s monitor, t-shirt, greeting card, or other item. What I am saying sounds bizarre. Here is an article from a photographer, explaining why DPI in relation to a photograph or graphics on a computer, is not useful.

You will need to make your graphics a higher resolution. Then, when viewed on a lower resolution monitor, the user will zoom out, and then it would have a higher ppi (DPI).

For example, 1000x1000 image, at 300 DPI (your view, 300 pixels per inch on a monitor), and you send it to someone else. They must zoom out because their monitor is only at 72 DPI. They zoom out so the image is now at 50%. They are now looking a high DPI image themselves, because there are more “dots” or “pixels” per inch on their screen. Sending a 100x100 500 DPI image to a printer would allow the image to be less blurry when printed on a t-shirt because the software they use reads that file as essentially having more resolution information, but you could basically think of that 100 pixel image as having 5 identical dots per pixel, so it doesn't make it better for web or computer presentation.

DPI will not serve you as a measurement for graphic development on the internet/blogging. Resolution will. Using DPI in tools such as Photoshop, adds extra data, that is essentially more pixels for resizing the image, but that doesn’t matter for web presentation, because image zooms and resizes will occur based on the resolution. The DPI information is only applicable to the in-depth image formats that you use, and that is because it has extra pixel information for resize purposes, so that if you opened that same file on a lower dpi monitor, it essentially resizes it for you.

The best answer is probably to use high resolution images that look good for you, and then zoom them to whatever the appropriate width is in pixels via CSS. Then everyone can view your 2000x2000 image, that still looks good for them, when zoomed to 500x500. You can use CSS to set the style of the images to 50% or 40% or whatever the relative measure is if you want to use the same single image for all viewers to your website, whether on 3200x1800 or 1280x800. Here is an article at Stack Overflow describing how to size an image at a percentage of the users monitor resolution. That is what you need rather than DPI changes.

[dotMorten]

@robertdknight I fail to understand the relevance of that with properly scaling the UI Elements in LiveWriter for different System DPI settings.

DPI stands for dots per inch. That is only applicable in the “view”, which means, on your screen (not on the website, which would be the presentation). Dots Per Inch is how many pixels on the screen in one inch. DPI for graphics tends to relate to printers, as it describes the number of individual ink dots that a printer places on a single page. You need higher resolution images, not the application to change the image size depending upon DPI. There are only pixels. DPI is a relative term, and only applicable to the “view”, whether that view is the end user’s monitor, t-shirt, greeting card, or other item. What I am saying sounds bizarre. Here is an article from a photographer <http://proshooter.com/article_whatisa300dpiJPeg.htm> , explaining why DPI in relation to a photograph or graphics on a computer, is not useful. You will need to make your graphics a higher resolution. Then, when viewed on a lower resolution monitor, the user will zoom out, and then it would have a higher ppi (DPI). For example, 1000x1000 image, at 300 DPI (your view, 300 pixels per inch on a monitor), and you send it to someone else. They must zoom out because their monitor is only at 72 DPI. They zoom out so the image is now at 50%. They are now looking a high DPI image themselves, because there are more “dots” or “pixels” per inch on their screen. DPI will not serve you as a measurement for graphic development on the internet/blogging. Resolution will. Using DPI in tools such as Photoshop, adds extra data, that is essentially more pixels for resizing the image, but that doesn’t matter for web presentation, because image zooms and resizes will occur based on the resolution. The DPI information is only applicable to the in-depth image formats that you use, and that is because it has extra pixel information for resize purposes, so that if you opened that same file on a lower dpi monitor, it essentially resizes it for you. From: toobob [mailto:[email protected]] Sent: Saturday, January 27, 2018 10:03 AM To: OpenLiveWriter/OpenLiveWriter Cc: Subscribed Subject: Re: [OpenLiveWriter/OpenLiveWriter] DPI scaling issues (#44) any progress on resolving High DPI/4k image rendering? i found this work around for photoshop, but it didn't work for me ( https://www.danantonielli.com/adobe-app-scaling-on-high-dpi-displays-fix/ ). for those of us who use a lot of photos/images, it's a real problem as the photos/images are too tiny to see until posted. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#44 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AZTbFqi5eiogPco9tdGbH5KCrvovCVgeks5tO0iugaJpZM4GyO3y> .Description: Image removed by sender.

Web Design is Pixel or percentage accurate. There is no way to use DPI in relation to it. You can't make an image look bigger than it is, because the output in the browser is based on how wide it is in pixels. Making the image look bigger than it is, would consume some pixels that weren't actually consumed.

You can't make an image look 50 pixels wide, if it is in actuality 25 pixels wide, to make up for DPI issues. You would need to zoom the entire view. The problem with that, is that text would look unusually large, unless you disabled the operating system scaling for text in that application.

So, I suggested disabling the Operating System scaling for the application, and putting a Zoom view that zooms everything.

If your monitor using DPI scaling (like retina in Macbooks) what that does, is it takes the already existing stuff, like someone's 460x400 image, and enlarges it by whatever percentage the whole screen is scaled at. That is a driver function of the video driver, and it is zooming an already existing image. It's not really having anything to do with DPI in the content itself. It's just doing it at the "view" for your computer screen.

The large text you see, is because Windows increases the size of the fonts. Text flows, so you can do that. But images don't work that way, because to enlarge them changes the pixel width of things in layouts in CSS and the HTML code. If you see images enlarged to some DPI spec, like occurs on a Retina screen (where it assumes a base resolution of 1600x900, and upscales it by quadrupling every inbound pixel, similar to how a Blueray player upscales DVD), the video driver is doing what I suggested, and just zooming in on things that are presented normally. That's not application specific though, it's a video driver/special software doing the scale for everything that is put on screen. The content, and the editors of that content, did not do anything in relation to dpi. Sorry for so many paragraphs on this, I am having a bit of trouble getting it out in one go. DPI doesn't work in CSS unless you custom build the functions for it, because things are determined by Pixels, and since the view shows a webpage with CSS elements expressed in Pixels, you would need to zoom the entire view (a huge change to the program) rather than just make images appear to take up more pixels than they really do. That would also make your designs look way different on different monitors than what you think it does.

I think you could achieve a similar effect by incorporating into your theme something that checks the resolution of the monitor. If the monitor resolution is 3200x1800, then the image should be 1800 wide. If it the monitor is 1920x1080, then the image shoudl be 900 wide. That's just an example. That way, when you are looking at it, and the CSS renders things, in theory you should see an image big enough to meet your goals. But that isn't done through DPI in any fashion except what you code in the web design, because CSS and HTML display images by their resolutions in pixels. If I was doing that, I would put the image in big enough to see it normally, and set the CSS/Javascript to make it smaller depending on the resolution of the viewers monitor. You could even take a faster shorcut, but just putting the images in div tags that scale to widths. Say, 50% of the column. Then, if you are using a big monitor, the 50% of a column makes the image 1000 pixels wide, and if someone is on a smaller monitor, the 50% of a column would make the image 600 pixels wide. The scaling is done at the "View" level, not at the data (model/controller) level, when it comes to websites. When you are making the website, you are putting in the 'data' - you are building the controller (the code on the webpage), that is viewed in the browser. The scaling is done at the "view" in the browser (resizing images or fonts) or at the OS level (DPI or Retina), so it will have to be handled there, unless the programmers of this application are super awesome, and they may be, in which case, I will gladly say I am wrong.

But, if your goal is large size images for you, and normal size images for smaller monitors, the percentage scalling in div tags sounds like the way to go, and just start with a high resolution to begin with, that is resampled smaller for smaller monitors.

In a Model-View-Controller paradigm (Websites, with HTML), the "Zoom" of an image has to be handled in the view level. When you are making the website, such as with this program, you are modifying the "controller". The operating System could "scale" something in the "view", or the program could scale it's "view" as I mentioned with a zoom" or you can have the website scale it's view, which is by using CSS to modify the image resolutions, so that when you see it presented, your view is scaled. There are three views for purposes of solving your issue. OS View (Retina or Windows DPI scales everything), OneLiveWriter Application's View (scale the viewport of everything), or the Website's view by scaling the images via CSS. The OS VIEW (Not OpenLiveWriter's) is handling the font scaling, but doesn't scale images in Windows, because Windows DPI scaling works differently than Retina, which works more like a movie upscaler on the whole screen instead of on specific components like Window's version does.

Hope this helps. Just trying to help get your desired result.

I finally got a good explanation, but I edited after the email had sent. Please read the above post on the website rather than your inbox.