Created attachment 188834 [details] The document with the embedded Calc table The update to LO 7.4.7.2 makes it impossible to work with one special embedded Calc table in Writer documents. The same error shows up with LO 7.5.5. I could reproduce the behaviour on my old Laptop (Win10-64 Pro) with LO 7.4.7.2 and a plain install without any Add-ons. Any table with random inputs behaves normally. So it must be the identified one wich I created a few years ago. Over the time some changes were done in the content of some of the cells. If I double-click the table to change the displayed data by scrolling down to the needed date the opened frame shows up distorted in some way, so it gets very difficult to work with it as far as I don't get the usual WYSIWYG. I added the whole file since it contains only open data. For the moment I got back to LO 7.4.6.2 where everything is working as intended. I don't know how to describe the odd behaviour better - my English may be not good enough.
Created attachment 188835 [details] An picture of the distortion
Maybe you have not resize properly. It's not the same, resize the object in writer, than enter in the object and resize it in calc. Please take a look it this can solve your issue.
I opened the attached document. Couldn't see column "G" directly after opened. So I double clicked on the table and extended the Calc-window to show this column "G". Closed the Calc window and reduced the width of the embedded object. There is no different behavior of this document when opening with LO 7.3.6.2 instead ob 7.5.5.2. But the system is different: OpenSUSE 15.4 64bit rpm Linux. Might be I haven't understood the description right way… Feel free to contact me directly per private mail to solve the problem. I'm also German.
(In reply to m.a.riosv from comment #2) > Maybe you have not resize properly. > > It's not the same, resize the object in writer, than enter in the object and > resize it in calc. > > Please take a look it this can solve your issue. @m.a.riosv I know that. In the working file are ranges (?) ("Bereiche") wich should not be altered in Format etc - I attached a modified version since my Working file was disrupted by the bug. To prevent the mentioned problem I added the "ranges" (?) ("Bereiche") because this problem accured several times.
(In reply to Robert Großkopf from comment #3) > I opened the attached document. Couldn't see column "G" directly after > opened. So I double clicked on the table and extended the Calc-window to > show this column "G". Closed the Calc window and reduced the width of the > embedded object. > > There is no different behavior of this document when opening with LO 7.3.6.2 > instead ob 7.5.5.2. But the system is different: OpenSUSE 15.4 64bit rpm > Linux. > > Might be I haven't understood the description right way… Feel free to > contact me directly per private mail to solve the problem. I'm also German. @Robert Großkopf Well I try to answer here in English. So others can join if they want. May be it's a windows issue. I will test it at home with one of my Ubuntu computers. I know that there is a certain change of look while working within the table wich normally switches back to the "normal" look. In may case it switches not bach to first size - it makes its own desicion to resize the "normal" look. It is reproducable for me on two computers with Windows 10 pro 64bit - so ... I will see what Ubuntu does.
Created attachment 188883 [details] A film shows the from my point of view odd behaviour of the table
My Ubuntu is rather old (2004). I use it for some private things so I don't update manually to the latest LO - don't need it there. In some of the newer live systems, I looked at, also only older versions of LO are included. I added a little film, that shows how an additional column appeares if I change the number of lines. Also is shown some other from my point of view odd behaviour. It's the same clean install I used to proove whether it seams to be a bug or not, e.g. like the size of the frame changes when getting back to writer. May be this helps.
[Automated Action] NeedInfo-To-Unconfirmed
I found another "issue" within the attached table: If you scroll up to the first line and scroll to the right you see the columns wich contains the base data for the first 7 columns. If I try to change the font of the base data columns I get a heterogenic result: all lines within most of the cells still are showing the old font. Within some cells the first line is changed to the chosen font. May be here is where comes the odd behaviour of the table from ...? I will try to change all the cells manually to one font and see if there is any change of behaviour described in this bug report.
Tested as described - no change of in the bug report described and in video shown behavoir.
(In reply to birquito from comment #9) > I found another "issue" within the attached table: If you scroll up to the > first line and scroll to the right you see the columns wich contains the > base data for the first 7 columns. If I try to change the font of the base > data columns I get a heterogenic result: all lines within most of the cells > still are showing the old font. Within some cells the first line is changed > to the chosen font. May be here is where comes the odd behaviour of the > table from ...? > > I will try to change all the cells manually to one font and see if there is > any change of behaviour described in this bug report. You can select those lines and Ctrl-M to clear direct formatting and they will show in the font you selected. I don't see the distortion upon opening in the first columns, but the text in the columns starting from K do look strangely squished. It's the same in 7.0, 6.0, 5.0, 4.3, but I don't know if it's a bug. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 486ae5db6987411d5e394de94b2b077099d03856 CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: default; VCL: win Locale: en-US (en_FI); UI: en-US Calc: threaded
Hello Buoviaga, when I made the first version of this file I copy-pasted the groups in column K and folowing from a pdf file, to make the data sheet the easy way - may be this is where the latest described "scrambling" comes from. Lately I reformated all the scrambled cells manually and copy pasted the data several times into a new table which I afterwards pasted into the document. No scrambled text is shown anymore but the descripted behaviour as shown in the film still remains within the plain install of LO 7.4.7.2. So I think it sems not to be any scrambled data from the pdf copy-pasted into the table. I will test the "Crtl-M" to claer the format later. Thanks for the hint.
With LO 7.6.2.1 the "bug" semms to be solved. No glitches no "interesting" behavior. So - thank you for your efforts - no one knows where the issue came from.