Description: If one selects e.g. centred-vertically in areas of a table, this formatting is very easily lost, for instance when another line is inserted If a field is spread vertically over two lines, and the insertion of another line higher above forces the second line onto a new page, the split reappears and the lower section becomes protected (read-only) Steps to Reproduce: 1. Set centred-vertically on a line 2. Insert a new line above 3. Centreing disappears. Can be only be restored by changing to top then back to centre Actual Results: Centreing disappears Expected Results: Centreing should remain Reproducible: Always User Profile Reset: No Additional Info: Open Office behaves similarly
Created attachment 156047 [details] Programme
I opend the attached document. Text in column Email ist not centered vertically. But when I click into the cell it becomes centered vertically. Just for clarifcation: "Step 2: Insert a new line above" means "insert a new table row above?"
Yes
(In reply to Peter Lawson from comment #0) > Steps to Reproduce: > 1. Set centred-vertically on a line > 2. Insert a new line above > 3. Centreing disappears. Can be only be restored by changing to top then > back to centre > > Actual Results: > Centreing disappears > > Expected Results: > Centreing should remain I can't reproduce it with Version: 6.4.0.0.beta1 (x64) Build ID: 4d7e5b0c40ed843384704eca3ce21981d4e98920 CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded
Created attachment 156062 [details] document
I should have stated before that I was using 6.2.2. I have since installed 6.3.3.2 and there is an improvement. It is now only necessary to click on a defective row and the vertical centering re-appears. This is as you reported. Sadly, if I save and close the document, when I re-open it the problems are back. How can I get 6.4.0.0 to test it?
Installed 6.4.0.0. Clicking in row restores centreing, saved it in this condition, re-opened and problems returned
Peter, your bug report is not clear. I change the wrong title (problems with document) to what I see here, although I don't understand: "Formatting: vertical alignment lost when row added to table" Instead of two similar large documents, you should've attached minimal sample (just one page with few rows) with text explaining the issue (like: insert new row above this one"). Please be exact: "1. Set centred-vertically on a line": How exactly did you do it? Which row? "2. Insert a new line above": Above which row and content?
The problem in fact only occurs when the document is saved. On re-loading, the incorrect vertical alignment re-appears, even though I fixed it prior to saving by clicking on the row It does not happen on the first page of the document, so creating a table with a few rows is unlikely to reveal any error "1. Set centred-vertically on a line": How exactly did you do it? Which row? I did it by selecting the row and then clicking on the 'Centre Vertically' icon Several rows are problematic, including most of those containing my name or 'Linda Rose' "2. Insert a new line above": Above which row and content? I am no longer sure that this is the cause of the problem Fortunately, when exported to pdf, the result is perfect
Report should've immediately pointed to: 'Linda Rose' and 'Peter Lawson ' in December 10 and 17, January 7 and 14. I see now on fileopen in LO 6.5+ and 6.2.8. Not in LO 6.1.6. Regression. Notes: I see that those texts in table have two text:style-name tags. Maybe this table was created with some content pasted from MSO or web.
Steps: 1. open ODT attachment 156062 [details] 2. both Win and Lin: see that some rows appear as Align Top: 'Linda Rose' and 'Peter Lawson ' in table December for 10 and 17, table January for 7 and 14. 3a. Windows: click in row changes them to Center Vertically OR 3b. Linux: add row above or below changes them to Center Vertically 4. save and reopen, shows them again as Align Top Bibisected: 54dcc59bd41665dfe5697ea05195b4ad0399dac9 is the first bad commit commit 54dcc59bd41665dfe5697ea05195b4ad0399dac9 Author: Jenkins Build User <tdf@pollux.tdf> Date: Fri May 10 16:39:16 2019 +0200 source 232b467083dd3b55f261bebe084e696bee200ec9 Previous: commit 416803c1c47c9bca7cee66d28fff4d8e36e00430 (HEAD, refs/bisect/good-416803c1c47c9bca7cee66d28fff4d8e36e00430) Author: Jenkins Build User <tdf@pollux.tdf> Date: Fri May 10 16:25:00 2019 +0200 source da5f9c68a253f28e9c0149e61b5662191a658af2 Single: https://gerrit.libreoffice.org/plugins/gitiles/core/+/232b467083dd3b55f261bebe084e696bee200ec9%5E!/ commit 232b467083dd3b55f261bebe084e696bee200ec9 [log] author Michael Stahl <Michael.Stahl@cib.de> Wed May 08 16:23:25 2019 +0200 committer Miklos Vajna <vmiklos@collabora.com> Fri May 10 13:25:52 2019 +0200 tree 01a607d9f95780e407f10c7bec1862f0d4fb2a76 parent da5f9c68a253f28e9c0149e61b5662191a658af2 [diff] tdf#124675 sw: fix crash when moving SwTextFrame in table to prev page CC: Michael. Please take a look if this needs to be fixed and if related to text:style-name tags.
Dear Michael Stahl, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assign it back to yourself if you're still working on this.
Magic words for search: Adding CC: to Michael Stahl
Interestingly, print preview matches exactly with the current layout. I also noticed that switching to view - web and then back to normal "fixed" everything.
Possibly related: https://bugs.documentfoundation.org/show_bug.cgi?id=154842
repro 24.2+
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bfa81a200ab59971b69823f9a29d8ce222d655e6 tdf#128437 tdf#128966 sw: layout: partially revert fix of tdf#124675 It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
seems this got a little better with previous commits (for no obvious reason), and with the one in comment#17 i dont see any row that isn't vertically centered. fixed on master
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4aa8fea8ac515e55bf3542e2717a3d85f1354054 tdf#128966 sw: add unit test It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/7272d2c152424255437f8fbda5ed31737404d52c tdf#128437 tdf#128966 sw: layout: partially revert fix of tdf#124675 It will be available in 7.6.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/649a34759bfed74e500de735d7ff52b5e4a651d8 tdf#128966 sw: add unit test It will be available in 7.6.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.