Bug 117449 - Text boxes positions and sizes are incorrect
Summary: Text boxes positions and sizes are incorrect
Status: RESOLVED DUPLICATE of bug 107946
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Textbox
  Show dependency treegraph
 
Reported: 2018-05-06 00:32 UTC by Ryszard
Modified: 2018-06-12 19:18 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
correct way (31.72 KB, image/png)
2018-05-06 00:35 UTC, Ryszard
Details
Incorrect way (32.02 KB, image/png)
2018-05-06 00:35 UTC, Ryszard
Details
actuall document1 (11.37 KB, application/vnd.oasis.opendocument.text)
2018-05-06 00:36 UTC, Ryszard
Details
correct doc 2 (10.38 KB, image/png)
2018-05-06 00:38 UTC, Ryszard
Details
Incorrect way Doc2 (8.59 KB, image/png)
2018-05-06 00:38 UTC, Ryszard
Details
actuall document2 (29.87 KB, application/vnd.oasis.opendocument.text-template)
2018-05-06 00:40 UTC, Ryszard
Details
without tables within framebox (31.00 KB, application/vnd.oasis.opendocument.text-template)
2018-05-06 14:57 UTC, Xavier Van Wijmeersch
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ryszard 2018-05-06 00:32:44 UTC
Description:
I have files with text boxes created few years ago. Since LO 5.3 series these files are not shows text boxes correctly, somehow now, even the boxes were created without borders, and they using wrap through settings the spacing and spacing to contents are affecting the size and position of text boxes.

Actual Results:  
text boxes are overlapping almost impossible to correct position of them without resetting all spacing to 0 and wrap setting

Expected Results:
Should open file the way was created and still opens right way in last OO


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Ryszard 2018-05-06 00:35:13 UTC
Created attachment 141917 [details]
correct way
Comment 2 Ryszard 2018-05-06 00:35:55 UTC
Created attachment 141918 [details]
Incorrect way
Comment 3 Ryszard 2018-05-06 00:36:55 UTC
Created attachment 141919 [details]
actuall document1
Comment 4 Ryszard 2018-05-06 00:38:14 UTC
Created attachment 141920 [details]
correct doc 2
Comment 5 Ryszard 2018-05-06 00:38:54 UTC
Created attachment 141921 [details]
Incorrect way Doc2
Comment 6 Ryszard 2018-05-06 00:40:13 UTC
Created attachment 141922 [details]
actuall document2
Comment 7 Xavier Van Wijmeersch 2018-05-06 14:57:39 UTC
Created attachment 141930 [details]
without tables within framebox

In OO also some wrong behaviour.
I have changed a bit the design of your framebox.
Have a look at the attachment

Version: 5.3.1.2
Build ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2
CPU Threads: 8; OS Version: Linux 4.14; UI Render: default; VCL: kde4; Layout Engine: new; 
Locale: nl-BE (en_US.UTF-8); Calc: group

regards
Comment 8 Ryszard 2018-05-06 22:35:00 UTC
I know I can redesign everything even using old document I just have to go to each text box and zero all spacing options for border (even border is not used) and for wrapping, and select through option that was originally set, the problem is I have hundreds of documents I'm re-printing  with part shipment(CofC document), so I can create new template for newer LO but changing every old one is not an option.
Comment 9 Dieter 2018-05-07 08:06:45 UTC
There are a lot of open bugs regarding to textboxes in a doc(x) document (see meta bug 112786 and meta bug 104449). Did you check for duplicates?
Can you also add the original doc-file, so that everybody is able to open it in LO and could see what happens?
Comment 10 Xisco Faulí 2018-06-07 08:45:32 UTC
(In reply to Dieter Praas from comment #9)
> There are a lot of open bugs regarding to textboxes in a doc(x) document
> (see meta bug 112786 and meta bug 104449). Did you check for duplicates?
> Can you also add the original doc-file, so that everybody is able to open it
> in LO and could see what happens?

Please attach a sample document, as this makes it easier for us to verify the bug. 
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)

I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Comment 11 Ryszard 2018-06-10 00:38:26 UTC
I do not really understand request for the document, two files were attached with the report,
under names - actual_document1 and 2
Comment 12 Dieter 2018-06-10 14:43:45 UTC
(In reply to Ryszard from comment #11)
> I do not really understand request for the document, two files were attached
> with the report,

Attachment in comment 4 contains only a screenshot of the doc-file. Please add the original doc-file itself.
Comment 13 Ryszard 2018-06-10 19:31:16 UTC
This file is in comment #6 please check all attachments.
You have correct and not correct pictures, and actual file for both cases.
Comment 14 Dieter 2018-06-10 19:36:49 UTC
(In reply to Ryszard from comment #13)
> This file is in comment #6 please check all attachments.
> You have correct and not correct pictures, and actual file for both cases.

Attachment in comment 6 containts an .ott file but not a doc-file.
Comment 15 Ryszard 2018-06-10 21:06:21 UTC
Yes,

This is LO template what doc (MS office file?) has to to with anything if you mean odt as doc file you may create it base on template. The moment you open template it becomes odt.
Comment 16 Dieter 2018-06-11 07:50:37 UTC
(In reply to Ryszard from comment #15)
> Yes,
> 
> This is LO template what doc (MS office file?) has to to with anything if
> you mean odt as doc file you may create it base on template. The moment you
> open template it becomes odt.

Sorry, it was not clear to me, what kind of files you are talking about in your original bug report. Now I assume, that it is nothing about doc-files.

I opened attachment 141919 [details] and got the same result as in the screenshot in attachment 141918 [details]

Version: 6.1.0.0.beta1 (x64)
Build ID: 8c76dfe1284e211954c30f219b3a38dcdd82f8a0
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
Locale: en-US (de_DE); Calc: CL


It opens correct in

Version: 4.4.7.2
Build-ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Gebietsschema: de_DE
Comment 17 raal 2018-06-11 16:06:00 UTC
This seems to have begun at the below commit.
Adding Cc: to Justin Luth ; Could you possibly take a look at this one?
Thanks
 17d8234546ccc7b6cd69f3288c5ee086d48b7b1c is the first bad commit
commit 17d8234546ccc7b6cd69f3288c5ee086d48b7b1c
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Thu Nov 3 22:33:58 2016 +0100

    source 5d9d0f3c979732ade57b9c4c4960dd030ffdc9f9
author	Justin Luth <justin_luth@sil.org>	2016-11-02 15:15:55 +0300
committer	Justin Luth <justin_luth@sil.org>	2016-11-03 19:02:41 +0000
commit 5d9d0f3c979732ade57b9c4c4960dd030ffdc9f9 (patch)
tree 5fec72a40be7dbf15f208498494213cd6f59c114
parent 2a818a0aafac218ca09bb079d7f2cf0879385e4a (diff)
there is a function for that: CalcLineSpace(xx, bEvenIfNoLine)
Comment 18 Justin L 2018-06-12 19:13:38 UTC
(In reply to raal from comment #17)
> there is a function for that: CalcLineSpace(xx, bEvenIfNoLine)
That irrelevant commit is going to haunt me forever. The real story is in bug 41542. Unfortunately for Ryszard, the ODF specs say that LO was SUPPOSED to honour the spacing definition, even though the borders were disabled. (That is also true for .doc*.)

Bug 41542 Comment 34 says "For a long time (at least since version 3.6) LibreOffice has reset the padding values to zero when borders were removed, but some older documents may still have padding values despite having no border - and thus may now render differently as the padding is activated."

So, I'm afraid that this needs to be chalked up to old bugs in LO, and you will just need to manually fix the documents that need the adjustment to look right. Sorry for the bad news.
Comment 19 Justin L 2018-06-12 19:18:00 UTC

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