Bug 152090

Summary: JPG Export does not handle DPI / Dimensions correctly!
Product: LibreOffice Reporter: Frasier Crane <frasier.crane>
Component: DrawAssignee: Not Assigned <libreoffice-bugs>
Status: RESOLVED DUPLICATE    
Severity: normal CC: ilmari.lauhakangas
Priority: medium    
Version: 7.4.2.3 release   
Hardware: All   
OS: Windows (All)   
Whiteboard:
Crash report or crash signature: Regression By:

Description Frasier Crane 2022-11-17 16:44:10 UTC
Description:
Exporting a JPG from a drawing does not handle the DPI / dimensions correctly!

E.g. I create a page 30 x 20 cm landscape and place some high-res photos on it.

When I export this page as JPG, I can select "Modify dimensions" (default 30 x 20 cm) or "Modify resolution" (default 96 dpi).

When I select the first choice, I get an image file with the dimensions 1134 x 756 pixels. Seems to be correct for 96 dpi.

When I select the second option and set it to 300 dpi, I also get an image file with 1134 x 756 pixels, which is totally wrong of course!

The "width and height" of the image should always stay 30 x 20 cm, even if I change the dpi, so that I can get a high-resolution output file!

When exporting JPG (and other files that are aware of dimension AND dpi), it must be possible to specify BOTH, dimension AND dpi and not one OR the other!

A work-around is to set the dimension to 3543 x 2362 pixels - which corresponds to an image of 30 x 20 cm with 300 dpi. This produces a correct high-res file. However, Draw should handle that correctly (and professionally), of course, so that I can define my output file to be 30 x 20 cm with 300 dpi...

Steps to Reproduce:
1. See description

Actual Results:
JPG file of incorrect size or dpi.

Expected Results:
JPG file with correct size and dpi.


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 7.4.2.3 (x64) / LibreOffice Community
Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf
CPU threads: 32; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win
Locale: de-AT (en_AT); UI: en-US
Calc: CL
Comment 1 Buovjaga 2022-11-17 18:05:04 UTC

*** This bug has been marked as a duplicate of bug 144195 ***