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.
text boxes are overlapping almost impossible to correct position of them without resetting all spacing to 0 and wrap setting
Should open file the way was created and still opens right way in last OO
User Profile Reset: No
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Created attachment 141917 [details]
Created attachment 141918 [details]
Created attachment 141919 [details]
Created attachment 141920 [details]
correct doc 2
Created attachment 141921 [details]
Incorrect way Doc2
Created attachment 141922 [details]
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
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
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.
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?
(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.
I do not really understand request for the document, two files were attached with the report,
under names - actual_document1 and 2
(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.
This file is in comment #6 please check all attachments.
You have correct and not correct pictures, and actual file for both cases.
(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.
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.
(In reply to Ryszard from comment #15)
> 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: 220.127.116.11.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
This seems to have begun at the below commit.
Adding Cc: to Justin Luth ; Could you possibly take a look at this one?
17d8234546ccc7b6cd69f3288c5ee086d48b7b1c is the first bad commit
Author: Jenkins Build User <email@example.com>
Date: Thu Nov 3 22:33:58 2016 +0100
author Justin Luth <firstname.lastname@example.org> 2016-11-02 15:15:55 +0300
committer Justin Luth <email@example.com> 2016-11-03 19:02:41 +0000
commit 5d9d0f3c979732ade57b9c4c4960dd030ffdc9f9 (patch)
parent 2a818a0aafac218ca09bb079d7f2cf0879385e4a (diff)
there is a function for that: CalcLineSpace(xx, bEvenIfNoLine)
(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.
*** This bug has been marked as a duplicate of bug 107946 ***