In an existing document page ranges are not handled correctly.
The error does not show in newly created files.
A newly added range always takes the full available space, not only the space needed.
In file Short with ranges.odt the Limit is by the Picture on page 2 and by the page border on page 4.
There is no equal distribution of text between the columns
Steps to Reproduce:
1.Just enter a new page range
Range taking the whole page (page 4)
Range with two columns of same length, ending somewhere in the middle of the page
User Profile Reset: No
Created attachment 145768 [details]
*** Bug 120645 has been marked as a duplicate of this bug. ***
Works correctly in 22.214.171.124 (Win 64)
I'm sorry Wilfried, but I don't know what you mean with "page range" and I also couldn't find it in the help-index. So I don't understand your steps to reproduce. When I open your document with LO master, everything looks fine to me on pages 2 and 4.
Concerning the terms: I used page range = (Seiten-) Bereich resp. Bereich in German.
Meanwhile I have the following workaround: I create the range (Bereich) in 126.96.36.199. Faulty ranges are corrected and recreated if necessary.
Generally I work in 188.8.131.52. now. This is due to Speed reasons for the 300 page document. I don't touch the ranges in 184.108.40.206. and everything is OK. When I make changes here (e. g. changing the number of coulumns forth and back) there is often (maybe not always) a wrong appearance of the range.
If you feel it could be helpful, I will care for screenshots, but that could take some time.
Question: What stands LO (LibreOffice I assume) >> master << for?
Thank you for clarification:
Steps to reproduce:
1. Open attachment from comment 1
2. Put cursor before image on page 2
3. Insert => Section => Columns => 2 columns =>Insert
2 columns until the end of the page
If you enter a 2 column section at the beginning of a page, column covers the the whole page.
Only one line like a section with one column.
Wilfried, does this decscribe your problem? I'm sure that such a bugreport already exists, but I couldn't find it.
Version: 220.127.116.11.alpha0+ (x64)
Build ID: 48cfa0b00b22f11ade53aec79b2fdddad253e1bd
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win;
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-03_02:01:42
Locale: en-US (de_DE); Calc: CL
Version: 18.104.22.168 (x64)
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard;
Gebietsschema: de-DE (de_DE); Calc: group
The description of the bug is OK.
(In reply to Wilfried Koch from comment #7)
> The description of the bug is OK.
The bug seems to be not present in 22.214.171.124
Repository used: 6.0
Bad commit: bc1845d882e52469a4583747881a465749177829
Adding cc to Noel Grandin
Sorry, that bisection result is not useful, because it doesn't tell me what commit in the main source repo is the problem.
Addition to comment 9: Meanwhile I handled the document where the bug came up in nearly all versions up to 126.96.36.199. No problems, even in several 450 pages documents. For my opinion as a heavy user, the bug is fixed.