Bug 104020 - FILEOPEN: Saving business cards loses positioning of image
Summary: FILEOPEN: Saving business cards loses positioning of image
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.1.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, regression
Depends on:
Blocks: Labels-BusinessCards
  Show dependency treegraph
 
Reported: 2016-11-18 22:05 UTC by Thomas Hehl
Modified: 2024-10-01 09:23 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Business card document (85.16 KB, application/vnd.oasis.opendocument.text)
2016-11-21 12:36 UTC, Thomas Hehl
Details
Layout with LibO 4.4.6.3 (56.86 KB, image/png)
2016-12-01 15:05 UTC, Telesto
Details
Layout with LibO 5.4.0.0 (60.02 KB, image/png)
2016-12-01 15:06 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Hehl 2016-11-18 22:05:09 UTC
I have attached the problematic file. When you open it, (it doesn't matter whether you update the links) you will see that the images are aligned with the top margin. Move the image.

Right click on the top left image and click format image. Change position to horizontal, center, to paragraph text area and vertical, center, to paragraph text area and hit OK. Click Synchronize Labels.

Everything appears correctly. This is how it should look. Save it and close writer.

Re-open the document. Images are again jacked up.
Comment 1 Xisco Faulí 2016-11-19 00:31:13 UTC Comment hidden (obsolete)
Comment 2 Thomas Hehl 2016-11-21 12:36:45 UTC
Created attachment 128922 [details]
Business card document
Comment 3 Telesto 2016-12-01 15:03:34 UTC Comment hidden (obsolete)
Comment 4 Telesto 2016-12-01 15:05:59 UTC
Created attachment 129186 [details]
Layout with LibO 4.4.6.3
Comment 5 Telesto 2016-12-01 15:06:42 UTC
Created attachment 129187 [details]
Layout with LibO 5.4.0.0
Comment 6 Xisco Faulí 2016-12-01 15:25:38 UTC
(In reply to Telesto from comment #3)
> Confirming that the images are aligned with the top margin when opening,
> with:
> Version: 5.4.0.0.alpha0+
> Build ID: 4130c8def811d1dcc87eacaa8ae48ba02738a790
> CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
> TinderBox: Win-x86@42, Branch:master, Time: 2016-11-29_01:03:18
> Locale: nl-NL (nl_NL); Calc: CL
> 
> but not with:
> Versie: 4.4.6.3 
> Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d
> Locale: nl_NL

Hi Telesto, is it the same issue at opening time than a saving time described in the description?
Comment 7 QA Administrators 2017-12-02 16:26:11 UTC Comment hidden (obsolete)
Comment 8 Thomas Hehl 2017-12-02 20:00:34 UTC
Recreated issue in current version: Version: 5.4.2.2
Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4
CPU threads: 4; OS: Windows 6.2; UI render: default; 
Locale: en-US (en_US); Calc: group
Comment 9 Buovjaga 2018-05-30 18:21:15 UTC
Bisect first gave me the wrong blamed commit (it was actually a good commit), but I advanced forwards one commit at a time (maybe under 10 times).

The first bad commit is this: https://cgit.freedesktop.org/libreoffice/core/commit/?id=e807dafa5ba9247479f925f96474d88d58450be9

commit e807dafa5ba9247479f925f96474d88d58450be9 (patch)
tree 7c35799a8c6b1c7dc7791da0621c6299bcd9f709
parent c62ab814d8df19e16c82262093a350fac93d328d (diff)
loplugin:stringconstant: OUStringBuffer: appendAscii -> append
Change-Id: I5aa87d22f0b810597ba5dd2f8b98d148ddb99020

Adding Stephan to CC

I used this solution to advance forwards in the history: https://stackoverflow.com/a/33668818
Comment 10 Stephan Bergmann 2018-05-31 07:21:18 UTC Comment hidden (obsolete)
Comment 11 Buovjaga 2018-05-31 08:24:40 UTC
(In reply to Stephan Bergmann from comment #10)
> * I don't understand how to execute the reproducer recipe from comment 0
> with a current LO master (e.g., in the right-click context menu of the top
> left image, there's no "format image" item).
> 
> * If you bisected (i.e., rebuilt LO from each bisected code revision), did
> you try a build with e807dafa5ba9247479f925f96474d88d58450be9 reverted?  For
> one, the change itself looks correct; and for another, the changed code
> (GridPrinter) appears to only be used as a debugging aid across the code
> base, so unlikely that is involved here.
> 
> * If instead you bibisected, what repo did you use?

You only have to open the file and see, if the images are jutting out of their label frames like in attachment 129187 [details] (bad result).

I did not rebuild, but the repo I used contains all the commits: bibisect-win32-5.1 from https://wiki.documentfoundation.org/QA/Bibisect/Windows#Versions
Comment 12 Stephan Bergmann 2018-06-01 09:18:38 UTC
Hm, with the bibisect-win32-5.1 I can indeed reproduce that

> commit 98cd24c7e539d7ce0b1f2ae069926815e149d2b8
> Author: Norbert Thiebaud <nthiebaud@gmail.com>
> Date:   Mon Aug 31 07:30:22 2015 -0700
> 
>     source e807dafa5ba9247479f925f96474d88d58450be9
> 
>     source e807dafa5ba9247479f925f96474d88d58450be9

displays businesscard.odt wrongly, while its predecessor

> commit aef4f3dd8ca1c18078866e42a886c23f69704657
> Author: Norbert Thiebaud <nthiebaud@gmail.com>
> Date:   Mon Aug 31 05:18:00 2015 -0700
> 
>     source c62ab814d8df19e16c82262093a350fac93d328d
> 
>     source c62ab814d8df19e16c82262093a350fac93d328d

displays it correctly.  (And c62ab814d8df19e16c82262093a350fac93d328d is indeed the predecessor of e807dafa5ba9247479f925f96474d88d58450be9 in the core repo; i.e., there's no commits in the bibisect repo that cover multiple core commits.)  However, when I revert e807dafa5ba9247479f925f96474d88d58450be9 on recent LO master (also on Windows), businesscard.odt still displays wrongly (which matches the impression that that commit looks good and rather unrelated to the broken functionality).  Something must be fishy with that bibisect repo.
Comment 13 Buovjaga 2018-06-01 13:13:06 UTC
This is difficult to bisect. Now I tried it with a fresh profile per launch:
rm -rf instdir/user && instdir/program/soffice

I was pointed to some typo-fixing commit! I walked between the commits a bit and seemed to be getting totally random results.
Comment 14 Xisco Faulí 2018-06-01 15:54:27 UTC
This is weird, on mac the regression was introduced much later, in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=9e9f310648992e103d664a82a96ed5bdee1db4ad..5244a49b92fa5acfa7445292775edf61bde6b232 (bibisected with bibisect-mac64-6.0-32commits while on linux it points to range  https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=ba70050dc37f82306a8a3c5815372a4b9fff18fc..3ecef8cedb215e49237a11607197edc91639bfcd ( bibisected with lo-linux-dbgutil-daily-till51 )
Comment 15 Xisco Faulí 2018-06-01 16:15:54 UTC
Reverting https://cgit.freedesktop.org/libreoffice/core/commit/?id=6ade80cf142664e78954c7544534e9436ceb90c7 fixes the problem on Mac but not on Linux...

Adding Miklos to the loop... he might have some insight here as well...
Comment 16 Miklos Vajna 2018-06-04 06:57:41 UTC
(In reply to Xisco Faulí from comment #15)
> Adding Miklos to the loop... he might have some insight here as well...

Hm, no idea off the top of my head. I don't see any really problematic commits in the Linux bibisect range, so I guess the easiest would be to bisect this.
Comment 17 QA Administrators 2019-10-19 02:42:20 UTC Comment hidden (obsolete)
Comment 18 QA Administrators 2021-10-19 03:41:42 UTC Comment hidden (obsolete)
Comment 19 Timur 2022-06-13 14:57:01 UTC
I don't see an explanation is this really about BC saving, or is it some Fileopen issue where image changed position in 5.1? I'd say it's not about saving.
Comment 20 QA Administrators 2024-06-13 03:17:23 UTC Comment hidden (obsolete)
Comment 21 Jiří Nováček 2024-10-01 09:23:48 UTC
Reproduced with
Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: 905e7c1105536c9757fa2c2faf670738aab02595
CPU threads: 8; OS: macOS 15.0; UI render: Skia/Metal; VCL: osx
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded