Bug 164439 - Calc fails to export a selection to JPG when the export dimensions are modified
Summary: Calc fails to export a selection to JPG when the export dimensions are modified
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Graphics-Export
  Show dependency treegraph
 
Reported: 2024-12-23 14:06 UTC by ms777
Modified: 2024-12-24 14:57 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Export of Cells A1:C2 shows the problem. Macro to export multiple resolution (10.33 KB, application/vnd.oasis.opendocument.spreadsheet)
2024-12-23 14:10 UTC, ms777
Details
Export without changing resolution (18.95 KB, image/jpeg)
2024-12-23 14:11 UTC, ms777
Details
Export with 10x resolution (197.06 KB, image/jpeg)
2024-12-23 14:12 UTC, ms777
Details
video testing the bug (21.37 MB, video/webm)
2024-12-23 18:21 UTC, BogdanB
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ms777 2024-12-23 14:06:49 UTC
Description:
With File/Export/tick the selection mark you can export the selection to JPG or PNG. The dialog allows to change the width/height of the JPG/PNG generated. If one cell content is a string with partly modified font or style (e.g. Bold) the text in the exported JPG is misaligned.
  
see https://ask.libreoffice.org/t/libreoffice-calc-jpeg-export-text-is-misaligned/115285/9
tested on 24.2.5.2 Windows 10

Steps to Reproduce:
1.Select cells A1:C2 in the attached calc
2.Export / tick selection, select .jpg / do not modify dimensions
3.Export / tick selection, select .jpg / modify dimensions, e.g. by multiplying with 10


Actual Results:
Both generated jpgs differ. In the 10x jpg a text is misaligned

Expected Results:
Both jpgs should be identical, just have different dimensions


Reproducible: Always


User Profile Reset: No

Additional Info:
the attached calc contains Basic code to simplify testing. The problem occurs both when exporting through the UI and through Basic, however
Comment 1 ms777 2024-12-23 14:10:47 UTC
Created attachment 198238 [details]
Export of Cells A1:C2 shows the problem. Macro to export multiple resolution
Comment 2 ms777 2024-12-23 14:11:41 UTC
Created attachment 198239 [details]
Export without changing resolution
Comment 3 ms777 2024-12-23 14:12:29 UTC
Created attachment 198240 [details]
Export with 10x resolution
Comment 4 BogdanB 2024-12-23 17:04:09 UTC Comment hidden (obsolete)
Comment 5 ms777 2024-12-23 17:49:13 UTC Comment hidden (obsolete)
Comment 6 BogdanB 2024-12-23 18:21:33 UTC Comment hidden (obsolete)
Comment 7 ms777 2024-12-23 18:41:45 UTC Comment hidden (obsolete)
Comment 8 BogdanB 2024-12-23 19:28:27 UTC
Confirm with
Version: 24.8.3.2 (X86_64) / LibreOffice Community
Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92
CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 9 Mike Kaganski 2024-12-24 14:57:39 UTC
Code pointer:

The normal cell text painting happens in ScOutputData::LayoutStrings calling OutputDevice::DrawText [1].

The "editengine" (formatted) text painting happens in ScOutputData::DrawEdit calling ScOutputData::DrawEditStandard calling EditEngine::Draw [2].

To debug this, likely the outputdevice's preparation (setting its map mode) must be tracked in both cases.

[1] https://opengrok.libreoffice.org/xref/core/sc/source/ui/view/output2.cxx?r=5166efaa&mo=54167&fi=1490#2202
[2] https://opengrok.libreoffice.org/xref/core/sc/source/ui/view/output2.cxx?r=5166efaa&mo=54167&fi=1490#3308