Bug 149821 - Windows LO inappropriately retrieves accessibility information to determine output resolution for image exports
Summary: Windows LO inappropriately retrieves accessibility information to determine o...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
(earliest affected) release
Hardware: All Windows (All)
: medium minor
Assignee: Not Assigned
Depends on:
Blocks: Graphics-Export
  Show dependency treegraph
Reported: 2022-07-02 20:31 UTC by xordevoreaux
Modified: 2023-01-20 09:36 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description xordevoreaux 2022-07-02 20:31:04 UTC
I adjusted the Ease Of Access settings in Windows to make the text 125% bigger and also selected the "make everything bigger" option to 125%, then wondered why my PNG exports were HUGE.  

I then noticed the resolution had changed. I don't want the resolution of my exports to change just because I modify my Ease of Access settings to see the screen better.

The resolution went from 37 pixels/cm to 47, making everything huge, and this should not have happened.

DO NOT do this.  If I don't change the setting myself, leave it alone, do not borrow from Windows Accessibility settings.

I only tested the PNG export in Draw.

Explanation below.

Steps to Reproduce:
In Microsoft Windows 10:

1. Confirm in Windows Settings > Ease of Access that text magnification is 100% and "Make Everything Bigger" is also 100%.

2. Open Windows LO
3. Create a new Drawing
4. No need to draw anything, just select File, Export...
5. In the export dialog, change the export type from GIF to PNG
6. Hit Save
7. Observe in the PNG Options dialog that the resolution is 37 pixels/cm.
8. Cancel the export and COMPLETELY quit out of LibreOffice
9. In Windows Settings > Easy of Access > Display, change the "Make Everything Bigger" option to 125%.
10. Repeat steps 2 through 7. Observe that the output resolution has gone from 37 pixels/cm to 47 pixels/cm.

Actual Results:
Any exported PNG is now larger, even when page size is not modified, because LO changed the resolution output (without user intervention) based a Windows setting.

Expected Results:
This export behavior is wrong.

Regardless what a person has set for the "Make text bigger" and "Make everything bigger" option, LibreOffice for Windows should NOT change the output resolution based on that.

If at 100% for "Make everything bigger" the pixels/cm is 37, then at any other setting for "Make everything bigger", the pixels/cm for LibreOffice image exports should remain at 37, not change.  

By basing the export based on Windows accessibility features, it's not possible to maintain the export resolution/dimensions available at 100% of the Windows setting from any other.

Don't use Accessibility features to determine Windows LO draw resolution output.

Reproducible: Always

User Profile Reset: No

Additional Info:
Tested in:

Version: (x64) / LibreOffice Community
Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

and in:

Version: (x64) / LibreOffice Community
Build ID: 23f76e2fed8d77c888a5595d96520ec958cccda8
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL
Comment 1 xordevoreaux 2022-07-02 20:38:05 UTC
Note about this as well -- just because I might export an image does not mean I'm the final consumer for that image. The person receiving the output may be using a different (or the default) set of accessibility settings to see the screen, and should not have to contend with oversized images coming from me.
Comment 2 Telesto 2022-07-02 21:07:54 UTC
Seems related to bug 92375 comment 25 / bug 112538. Probably more similar bugs at bug 116082
Comment 3 xordevoreaux 2022-07-02 22:52:18 UTC
(In reply to Telesto from comment #2)
> Seems related to bug 92375 comment 25 / bug 112538. Probably more similar
> bugs at bug 116082

I read this bug, and saw this for one of the comments:

I would suggest the current dpi setting of the running OS. This way, the result (how the slides look) would still be the same as before on the original computer.

SERIOUSLY bad idea. It would not be the same, not by a long shot. The output needs to be independent of the O/S, because the person creating the image, as I mentioned above, may not be the final consumer of that image. The next person may be viewing screen content at a completely different magnification/resolution.

LO should not be determining the DPI based on the user's O/S settings because the output may not be limited to that user, but shared, and if you're trying to meet a particular DPI/Resolution for the client or end user of that image, and your own O/S accessibility settings for viewing content differs from that client or consumer, and LO is reacting to that, that's a show-stopper to production.

*I* want to be the one determining the DPI of the output by configuring LibreOffice to export how I want it, NOT for LO to react to the fact that my eyesight is going bad and I need to see the screen better by determining for me what the output should be based on the O/S's accessibility settings.
Comment 4 xordevoreaux 2022-07-02 22:58:57 UTC
Case in point, when I set the Windows O/S accessibility setting to 125%, and LO changes the DPI from 37 pixels/cm to 47 pixels/cm, I can't reach the original output dimensions of my export.

For example, if the dimensions of my picture, exported, is 528x728 pixels at 37 pixels/cm output, and LO changes the resolution for me, without my intervention, to 47 pixels/cm output based on my accessibility settings, I subsequently cannot export to 528x728 ratio without changing page dimensions, which subsequently screws up the placement of content on the page.
Comment 5 Buovjaga 2023-01-20 09:36:31 UTC
I confirm

On Windows 11, it is System > Display > Scale.

Behaviour is the same in 5.1, 4.3.

Version: (X86_64) / LibreOffice Community
Build ID: 1c638b7ac46d8077994c8483e6becc4a33efd12b
CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: en-US (en_FI); UI: en-US
Calc: threaded