Created attachment 61770 [details] Sample document to illustrate paragraph spacing at top of column See top of second column on page 10 of attached document. I would expect the spacing above the "Heading 1a" paragraph (1914 Translation...) at the top of the second column to be compressed/removed, to match the first column.
I can confirm this problem with LibO 3.6.2.1 on Bodhi Linux. The problem only occurs when you create the Manual Column Break using styles (header 1a), if you just do insert -> manual break it seems to work fine. The behavior is dependent on if you're on the left or right side (column). Marking as NEW and prioritizing.
*** Bug 53304 has been marked as a duplicate of this bug. ***
Please see the duplicate Bug 53304 for additional information and steps to reproduce.
Created attachment 114620 [details] An example using default styles, with non-zero spacing above paragraphs I've just come across this in 4.0.4.2 (official build) and 4.4.1.2 (PortableApps build) on Windows Vista. In case it's any help, it doesn't seem to be caused specifically by heading styles, but by having a non-zero spacing above the paragraph. It looks like the spacing above the paragraph is doubled following a manual column break within a section. Attached is another example, this time using default styles. The default paragraph style has simply been changed to have half a line spacing above each paragraph. The text of the second column, following a manual column break, is offset by an extra half a line compared to the first column.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
This bug is still reproducible (following the steps in 53304). -- LibreOffice 5.1.2.2 10m0(Build:2) Ubuntu 14.04 (x64)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
Still reproducible with LibreOffice 6.1.3.2 on Linux Mint, using the build from the LibreOffice PPA. Tested using the document I attached in comment 4, and also by recreating a similar document from scratch (in case an update fixed the issue for newly created documents but preserved the layout of existing documents). (It seems the last comment from QA requesting testing has been flagged as spam and hidden!)
Created attachment 147849 [details] tdf50068_columnSpacingAbove.odt: exaggerated example, 3 scenarios A big part of this bug is layout flowfrm.cxx's wonky HasParaSpaceAtPages(), which has untouched logic since first import. Sounds very dangerous.
Created attachment 147853 [details] tdf50068_columnOverflowUpperSpace.odt: if first paragraph padding is honored, then probably shouldn't align column tops, right? I haven't figured out why the first column's "upper" space spills over to the next column (and occasionally to the next page). It seems wrong to me because IF the spacing above the starting paragraph is honoured, THEN overflow from the paragraph should start at the top of the column (upper = 0), and not be lined up with the first paragraph (upper = x). For the previously given example documents, there is a compatibility setting that "fixes" these particular documents. Turn off Tools - Options - Writer - Compatibility - "Add paragraph and table spacing at tops of pages". Or alternatively, the user can just zero out the "space above" on the paragraphs that don't line up.
I'd better walk away from this bug, or else I'll get into deep trouble. For some reason, the section-frame itself gets the upper value from the first paragraph in sectfrm.cxx SwTwips nUpper = CalcUpperSpace(); So that is why all of the following columns use that as their "zero" height. Notes for whoever decides to tackle this: -HasParaSpaceAtPages is a big loop - moving outward until a condition is satisfied. So it is VERY hard to make a change here that doesn't have side effects. -make sure you also test against multiple pages because the first page is treated differently ( IsPageFrame() && !GetPrev() ). -
Created attachment 147869 [details] tdf50068_testsuite.zip: how spacing affects column breaks, page breaks, multiple sections, natural paragraph breaks Finding out what documentation says OUGHT to be happening in the case of DocumentSettingId::PARA_SPACE_MAX_AT_PAGES would be good to know, but no point in wasting Regina's time if it won't be acted on by a competent developer.
Created attachment 147870 [details] 0001-tdf-50068-partial-fix-sw-spacing-in-text-not-section.patch For those much braver than I, this might give a good starting point.
*** Bug 129304 has been marked as a duplicate of this bug. ***
Repro 6.5+. Also attachment 156452 [details] from duplicated bug 129304.
*** Bug 130504 has been marked as a duplicate of this bug. ***
> Libre Office 7 and the bug is ~~still~~ there. # What's the bug ? Okay there are some paragraphs of text. Select it and make it 2 columns. (Toggle Formatting Marks.) Shift+ctrl+Enter to add a 'Manual Column Break' Well that 'Manual Column Break' mark is shown on the beginning of the new column (and not at the end of the old one as I would expect) however that is not really a problem. Till that point everything is fine. Both text columns are well horizontal aligned ## Now the layout problem starts when I gonna use 'Above Paragraph Spacing' setting. The bug and unexpected behaviour is that the 'Above Paragraph Spacing' of the first paragraph also effects the spacing of the spacing of the following columns. ## Workaround Just put a 'dummy paragraph' in the first line of a section with columns by just **hitting enter** once. Set the **'Font Size' to 2pt** and ensure **'Above Paragraph Spacing' is 0 cm**.
The DOCX related report is bug 154082.
*** Bug 156064 has been marked as a duplicate of this bug. ***
Is it possible to increase the importance to something above minor, please? This is throwing off the entire layout and makes working with sections impossible. Plus, it would reduce work for bug maintainers, as it's only going to come up again and again only to be marked as a duplicate. People are struggling and will continue to struggle with it. Especially those, that experience the bug but have trouble to file a bug report and thus don't even show up in the data, here. I suggest marking it as a major issue and getting it squashed and out of the way once and for all :)