Created attachment 125731 [details] Sample base document The report builder generates empty pages for some reason. The pages are not displayed in the print preview, which is good. It is still confusing that it shows many empty pages in the preview. With my actual database document there are tens of empty pages. It somehow might depend on the total number of table entries. This does not happen with LO 4.5. Only 5.x shows this behavior. Open the attached testform.odb, and then the report PruefungslisteDatum. The report will show a couple of empty pages with only page numbers at the end.
Confirming with Version: 5.3.0.0.alpha0+ Build ID: c375089034e5baff7b56a62dfa052a1e3265c062 CPU Threads: 2; OS Version: Mac OS X 10.11.5; UI Render: default; Locale: fr-FR (fr.UTF-8)
No addtional blank pages in Version: 4.4.5.2 Build ID: a22f674fd25a3b6f45bdebf25400ed2adff0ff99 Locale: fr.UTF-8 OSX 10.11.5 ==>> regression
Bug visible in Version: 5.0.0.2 Build ID: a26d58f11b99b6aeddf7f7884effea188cc6e512 Locale: fr-FR (fr.UTF-8) OSX 10.11.5
Couldn't confirm the buggy behavior with OpenSUSE 42.1 LEAP, Version: 5.1.3.2 Build-ID: 644e4637d1d8544fd9f56425bd6cec110e49301b - 64bit rpm Linux. Only 8 pages with content visible.
@Gerhard : could you let us know which OS you are using ? Thanks.
Sorry, got distracted. Windows 7 64 bit, LibreOffice 5.0.5 32bit and 5.1.3 32bit. Java 8.91. It works with LO 4.4.5 32bit.
So this bug seems to affect Win/OSX versions ≥ 5.0.x
Bonjour, This bug seems present again in 6.01 ; but it's difficult to reproduce, it seems it depends of the table content. The problem is that the table I use is quite a confidential one and I have some problem to reproduce the bug with test table of my own. I cannot use the attached file of this bug report, perhaps because I have no database installed on my system. It's a regression in the 6.0 branch and,fortunately, the problem is still not present in the 5.45 version.
Created attachment 139723 [details] demo base
I've reached to reproduce this bug : it seems linked with french accentuated letters letters. I've made 2 tables that are the same except that I have added accentuated letters in the first records and the bug appears. Note that, in the report, these records appears at the end of the list because I've replace «o» by «ô» for example. So, to put these modified records at the top of the list created by the report, I've changed the first letter from «P» to «B» ; surprise, in this particular case, the bug disappears ! I've joined demo.odb file with 3 tables and 3 reports (name are explicit). cordialement,
(In reply to moebius20 from comment #10) > I've reached to reproduce this bug : it seems linked with french accentuated > letters letters. > > I've made 2 tables that are the same except that I have added accentuated > letters in the first records and the bug appears. > Note that, in the report, these records appears at the end of the list > because I've replace «o» by «ô» for example. > So, to put these modified records at the top of the list created by the > report, I've changed the first letter from «P» to «B» ; surprise, in this > particular case, the bug disappears ! > > I've joined demo.odb file with 3 tables and 3 reports (name are explicit). > Confirming with Version: 6.0.1.1 Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6 Threads CPU : 8; OS : Mac OS X 10.13.3; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group
In Gerhard's example table, it is not the data that contains extended characters, but the labels, so it would appear that the presence of extended characters anywhere within the report causes the issue.
(In reply to Alex Thurgood from comment #12) > In Gerhard's example table, it is not the data that contains extended > characters, but the labels, so it would appear that the presence of extended > characters anywhere within the report causes the issue. Forget that theory. I changed the labels in Gerhard's sample report, and still got extra blank pages at the end.
Regression introduced by: author Jan-Marek Glogowski <glogow@fbihome.de> 2016-09-14 15:33:54 +0200 committer Jan-Marek Glogowski <glogow@fbihome.de> 2017-07-13 12:10:23 +0200 commit 7a1c1699a61a77d0228417da9922812c9b893b9d (patch) tree 9ded7bd1fe28e211df290090a8b49690696fcc63 parent 503eba23c9a199583eddee9e169a4fddbecf416f (diff) Run Idle tasks immediatly There is really no reason to wait a millisecond for an idle. Bisected with: bibisect-linux64-6.0 Adding Cc: to Jan-Marek Glogowski
(In reply to moebius20 from comment #9) > Created attachment 139723 [details] > demo base On pc Debian x86-64 with master sources updated today, I confirm that as soon as the last record contains an accent, the report display 2 extra "empty" pages at the end. "empty" because there's the initial layout without any rows. For the test, I changed the last record of table 2 (p-to-b) to add an accent, the report2 p-to-b displays 2 extra "no rows" pages. Badfully, no specific logs on console which may provide some code pointer.
Created attachment 140161 [details] another database to demo this bug This has been around ever since I've been using LO (5.x). Attached database demonstrates it. I have tried to make this demonstration as simple as possible. Yes, it's hard to sometimes demonstrate this bug. It appears to be involved with possibly a number of things. I can change any number of things in this demonstration and this bug goes away, e.g. delete one of the groupings, delete one of the fields, resize the height of one of the fields, and the extra pages go away. That not withstanding, when I want it to go away in my other more private reports I can't make it go away, not without super-simplifying them, e.g. getting rid of a bunch of critical features. Then the bug goes away. :-) I love bugs. Especially good, hard to find ones. GNU/Linux Debian 9.3 x86-64 kernel 4.9.0-5-amd64 w/ cinnamon 3.2.7 graphics card: AMD/ATI RV710/M92 Mobility Radeon HD 4530/4570/545v
Bonjour, Still present in 6.02, not really a surprise... Strange bug that disappears in 5.4 series and goes back in 6.0. I hope that it will be resolved before 7.0 series ! cordialement,
Version must correspond to the oldest one, so let's revert back.
Ok :) Still present in 6.0.3 ; surprised ?! cordialement,
*** Bug 117236 has been marked as a duplicate of this bug. ***
Created attachment 141730 [details] Sample base file A sample base which has the problem.
*** Bug 118039 has been marked as a duplicate of this bug. ***
This is quite probably the same bug as 113326 and 116872. And this bug is actually old. It was confirmed against 5.0.0.2 in comment 3 and never fixed, just look in the history and read the comments. BTW - 5.0 got the first scheduler patches, long before I tried to fix stuff. Now what is actually happening in all cases: there are "really empty" pages at the end of the document due to whatever reason. If you open the RTF document from 113326 with LO 5.4 and look at the page count in the bottom-left area of the writer status bar, you can see, that the initial document also has 6 pages. But these get reduced to 4, because the last two pages are "really empty". At least I can see this, when opening the document in a remote LO via SSH X forwarding. Reducing always happens, if LO decides it needs to do some layouting, so it happens for the bug 116872 document, if you scroll with the keyboard. "Really empty" means you can't click into these pages via mouse or scroll to them via keyboard, which is an invalid document state AFAIK. So just scroll to these pages via mouse and try to put the cursor in the page. Really the page, not the header or footer! All of my (bi)bisected patches increased the performance of LO job processing. My guess is, something schedules this cleanup job, but this depends on some layouting, which is not finished, when the cleanup job is run. Someone want to debug writer layouting code?
Bonjour, The problem is that, since a very long time, no change or debug action has be done in base module ; when taking a look to the release notes of any version, there's always nothin for the base module ; it seems it is completely abandoned. So the only hope is that this bug could appear in writer module ! cordialement,
(In reply to moebius20 from comment #24) > Bonjour, > > The problem is that, since a very long time, no change or debug action has > be done in base module ; when taking a look to the release notes of any > version, there's always nothin for the base module ; it seems it is > completely abandoned. No, not the whole Base-module. See migration to Firebird and some little changes in the past (query-editor, macro-connection ...) Report-builder hasn't created as planned. There have been planned more features but then the project stopped in 2008 - before LibreOffice appears in 2011. Report-Builder needs somebody, who has enough knowledge and enough time and enthusiasm for it ...
I tried this one with libo-master~2018-08-29_04.32.58_LibreOfficeDev_6.2.0.0.alpha0_Win_x86 and it's 8 pages, not 10, no empty pages at the end. Seems solved with Bug 119458 as Bug 116872. Since Base I'll just mark WFM. Reporter may test master from https://dev-builds.libreoffice.org/daily/master/Win-x86@42/current/ or wait 6.1.2. You can uninstall it later. Note: I see some slowliness with generating report, but that's another issue.
WFM relates to original attachment 125731 [details] that's 8 pages. attachment 139723 [details] is 5 pages in all 3 reports. Guess OK. attachment 140161 [details] is 3 pages, used to be 6 attachment 141730 [details] is 14 pages, used to be 24. That's duplicate Bug 117236. You who report, be precise about Experienced and Expected. Jose, please test your Bug 118039 with master. Sorry for not going into that.
Bonsoir, The bug seems fixed in 6.1.3 cordialement,