Description: After each page break an empty pages is added Steps to Reproduce: 1. Open attachment 113464 [details] (bug 89435) 2. Go to multi page view. Compare it with Word or LibO5.0.6.3 Actual Results: LibO will add a empty page after each page break Expected Results: No empty pages Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 5.4.0.0.alpha0+ Build ID: 99eed82939999d9a9689788a4134dd05d5c20c5a CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-01-14_23:37:40 Locale: nl-NL (nl_NL); Calc: CL and in Version: 5.2.5.0.0+ Build ID: a4d4fbeb623013f6377b30711ceedb38ea4b49f8 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-2, Time: 2016-12-24_14:43:55 Locale: nl-NL (nl_NL); Calc: CL but not in Version: 5.0.6.3 Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa Locale: nl-NL (nl_NL) User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Regression introduced by: author Justin Luth <justin_luth@sil.org> 2016-09-09 09:42:55 (GMT) committer Justin Luth <justin_luth@sil.org> 2016-09-09 12:54:23 (GMT) commit bdd4a238a1d8a0cbbebbd759011050659668f92b (patch) tree dcf2a125482a84bd416c197a64d492407b1bf699 parent 20c14c812ccc00692d42d294d3b8dea1774e3511 (diff) tdf#86926 writerfilter allow fallback if exceptions The multiset routine was put in to increase the speed of applying properties. However, if one property causes an exception, the remaining properties are never applied. There is already a fallback routine (if the multiset can't be created), so use that instead of returning in a failed state. Adding Cc: to Justin Luth
before: 380 pages. Gibberish table of contents and extremely narrow margins for the entire document. after: 362 pages. legible table of contents, and reasonable margins for the document. The "empty" pages have approximately three carriage returns on each one. Where is the problem here?
(In reply to Justin L from comment #2) > before: 380 pages. Gibberish table of contents and extremely narrow margins > for the entire document. > > after: 362 pages. legible table of contents, and reasonable margins for the > document. The "empty" pages have approximately three carriage returns on > each one. > > Where is the problem here? if you see for instance the TOC, you will notice there are empty pages between pages...
(In reply to Xisco Faulí from comment #3) > if you see for instance the TOC, you will notice there are empty pages > between pages... What currently is one page of TOC, and one supposedly empty page (with several carriage returns and a hard coded page number) previously was two or three pages of gibberish content (for example what supposedly is page 4 on pages 6-8 in version 5.1).
Created attachment 130680 [details] comparison ok, so Justin is right, it can be seen in the image attached. Removing the keywords but I think there's still a bug as it can be seen compared to MSO Word
Interesting -.04 margins for the top and bottom page margins exist in this document, but not in LibreOffice, which will account for most of the space issues. Negative margins were not supported in LO3.5 either.
Justin Luth committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1dadd312e5cb3c95f1e3cd5a1776830b7056bc6b tdf#105490: writerfilter exception - ULSpace must be >= 0 It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.