Bug 100477 - Report builder generates empty pages
Summary: Report builder generates empty pages
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.0.0.1 rc
Hardware: x86-64 (AMD64) All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 117236 118039 (view as bug list)
Depends on:
Blocks: Database-Reports-Builder Additional-Blank-Pages
  Show dependency treegraph
 
Reported: 2016-06-19 11:29 UTC by Gerhard Schaber
Modified: 2018-11-18 21:58 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample base document (49.19 KB, application/vnd.sun.xml.base)
2016-06-19 11:29 UTC, Gerhard Schaber
Details
demo base (29.83 KB, application/vnd.oasis.opendocument.database)
2018-02-09 11:13 UTC, moebius20
Details
another database to demo this bug (9.00 KB, application/vnd.oasis.opendocument.database)
2018-02-26 17:55 UTC, Howard Johnson
Details
Sample base file (8.65 KB, application/vnd.sun.xml.base)
2018-04-28 02:21 UTC, twisterddfsl83823
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerhard Schaber 2016-06-19 11:29:08 UTC
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.
Comment 1 Alex Thurgood 2016-06-20 07:54:16 UTC
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)
Comment 2 Alex Thurgood 2016-06-20 07:56:55 UTC
No addtional blank pages in 

Version: 4.4.5.2
Build ID: a22f674fd25a3b6f45bdebf25400ed2adff0ff99
Locale: fr.UTF-8

OSX 10.11.5

==>> regression
Comment 3 Alex Thurgood 2016-06-20 07:59:38 UTC
Bug visible in 

Version: 5.0.0.2
Build ID: a26d58f11b99b6aeddf7f7884effea188cc6e512
Locale: fr-FR (fr.UTF-8)

OSX 10.11.5
Comment 4 Robert Großkopf 2016-06-20 14:01:43 UTC
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.
Comment 5 Alex Thurgood 2016-06-20 15:06:58 UTC
@Gerhard : could you let us know which OS you are using ? Thanks.
Comment 6 Gerhard Schaber 2016-06-20 18:32:31 UTC
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.
Comment 7 Alex Thurgood 2016-08-31 09:27:37 UTC
So this bug seems to affect Win/OSX versions ≥ 5.0.x
Comment 8 moebius20 2018-02-09 10:25:07 UTC
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.
Comment 9 moebius20 2018-02-09 11:13:07 UTC
Created attachment 139723 [details]
demo base
Comment 10 moebius20 2018-02-09 11:15:56 UTC
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,
Comment 11 Alex Thurgood 2018-02-12 10:37:15 UTC
(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
Comment 12 Alex Thurgood 2018-02-12 10:44:11 UTC Comment hidden (obsolete)
Comment 13 Alex Thurgood 2018-02-12 10:47:10 UTC
(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.
Comment 14 Xisco Faulí 2018-02-13 11:30:57 UTC
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
Comment 15 Julien Nabet 2018-02-13 19:58:48 UTC
(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.
Comment 16 Howard Johnson 2018-02-26 17:55:23 UTC
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
Comment 17 moebius20 2018-03-09 22:29:12 UTC
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,
Comment 18 Julien Nabet 2018-04-17 09:18:53 UTC
Version must correspond to the oldest one, so let's revert back.
Comment 19 moebius20 2018-04-17 10:12:39 UTC
Ok :)

Still present in 6.0.3 ; surprised ?!

cordialement,
Comment 20 Xisco Faulí 2018-04-27 15:09:26 UTC
*** Bug 117236 has been marked as a duplicate of this bug. ***
Comment 21 twisterddfsl83823 2018-04-28 02:21:47 UTC
Created attachment 141730 [details]
Sample base file

A sample base which has the problem.
Comment 22 Xisco Faulí 2018-06-06 16:32:45 UTC
*** Bug 118039 has been marked as a duplicate of this bug. ***
Comment 23 Jan-Marek Glogowski 2018-07-03 14:39:27 UTC
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?
Comment 24 moebius20 2018-08-30 11:51:16 UTC
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,
Comment 25 Robert Großkopf 2018-08-30 14:41:21 UTC
(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 ...
Comment 26 Timur 2018-08-30 14:55:29 UTC
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.
Comment 27 Timur 2018-08-30 15:07:24 UTC
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.
Comment 28 moebius20 2018-11-18 21:58:16 UTC
Bonsoir,

The bug seems fixed in 6.1.3

cordialement,