Bug 120212 - Writer inserts empty pages when opening a generated file
Summary: Writer inserts empty pages when opening a generated file
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.6.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-30 11:27 UTC by Marko Mahnič
Modified: 2021-01-30 07:55 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Attachments
git-diff converted to odt (27.33 KB, application/vnd.oasis.opendocument.text)
2018-09-30 11:27 UTC, Marko Mahnič 		Details
git-diff conveted to odt, longer version (45.58 KB, application/vnd.oasis.opendocument.text)
2018-10-02 08:06 UTC, Marko Mahnič 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Marko Mahnič 2018-09-30 11:27:54 UTC 
Created attachment 145276 [details]
git-diff converted to odt

The attached generated file has no soft page breaks defined. When it is loaded into Writer, soft page breaks are added by the Writer, but also a number of empty pages are created. The file that should be 12-13 pages long has 41 pages including empty ones.

The problem can be fixed in Writer by saving and reloading the file a few times. In some documents (some) empty pages are removed automatically when editing or navigating the file, but I see no rule when that happens.

I think empty pages started appearing when sections were introduced in the generated file.

I see this happening on Linux and Windows.

The issue may be similar to this closed bug:
https://bugs.documentfoundation.org/show_bug.cgi?id=119584
Comment 1 Oliver Brinzing 2018-09-30 16:10:29 UTC 
confirming with lo 6.0.6.1

but i can not confirm with:
(status bar shows ~42 pages during file openening, but switches to 12 pages)

Version: 6.1.2.1 (x64)
Build-ID: 65905a128db06ba48db947242809d14d3f9a93fe
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc:

Version: 6.2.0.0.alpha0+ (x64)
Build ID: bc32f789bb3c079eba9c07275866a7b13f76dbcc
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: de-DE (de_DE); Calc: threaded
Comment 2 Marko Mahnič 2018-10-02 08:06:11 UTC 
Created attachment 145317 [details]
git-diff conveted to odt, longer version

I tried another, longer document with lo 6.1.2.1 (x64, Windows) and got the following results:

Expected result:
When the file is open the page indicator shows: Page 1 of 30

Actual result:
When the file is open the page indicator shows: Page 1 of 100

In the mean time I checked the generated file with an online Odf Validator and got some errors related to the manifest file. I opened the file in LO and saved it again. When I reopened the new file I got the following results:

Expected result:
When the file is open the page indicator shows: Page 1 of 30

Actual result:
When the file is open the page indicator shows: Page 1 of 32
In this case the 2 extra pages were at the end of the document and were removed when I scrolled with the mouse wheel to the end of the document -- the number of pages first dropped to 31 and then to 30.
Comment 3 Oliver Brinzing 2018-10-02 16:27:23 UTC 
with you second example file and 6.1.2.1 (x64, Windows) i have:

Actual result:
When the file is open the page indicator shows: Page 1 of 100

after switching to print preview: 30 pages

scrolling downwards give strange results ...
Comment 4 Xisco Faulí 2018-10-04 16:35:26 UTC 
(In reply to Oliver Brinzing from comment #3)
> with you second example file and 6.1.2.1 (x64, Windows) i have:
> 
> Actual result:
> When the file is open the page indicator shows: Page 1 of 100

I can't reproduce it... while loading it shows 100 pages, however it's updated to 30 after a couple of seconds...

Version: 6.2.0.0.alpha0+
Build ID: 8ea0b0f4dc5eba2d0bafc2e42415ef1824ff604e
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: threaded
Comment 5 Xisco Faulí 2018-10-04 16:37:04 UTC 
Same behaviour in

Versió: 6.1.2.1
ID de la construcció: 1:6.1.2~rc1-0ubuntu0.16.04.1
Fils de CPU: 4; SO: Linux 4.15; Renderitzador de la IU: per defecte; VCL: gtk3; 
Configuració local: ca-ES (ca_ES.UTF-8); Calc: group threaded

I don't see empty pages either.
@marko, do you have the same behaviour ?
Comment 6 Oliver Brinzing 2018-10-04 17:39:29 UTC 
i just tried again with lo 6.1.2.1:

> while loading it shows 100 pages,
> however it's updated to 30 after a couple of seconds...

yes it's updated after some seconds, but every time i open
the document the pages differ, for example: 90, 99, 72 ...

but if i switch to print previev as soon as possible after loading process
the status bar shows: "repagination..." and pages switch to 30.

this does not happen if i wait to long. in such a case the switch
to print preview happens without repagination and paes atay at 90,99,...

question: how can a repagination be forced ? is there an .uno: command?

with my *debug* version:
Version: 6.2.0.0.alpha0+ (x64)
Build ID: bc32f789bb3c079eba9c07275866a7b13f76dbcc
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: de-DE (de_DE); Calc: threaded

pages start at 100 and switch to 30 after some seconds.
Comment 7 Aron Budea 2019-01-18 11:57:40 UTC 
This looks a lot like bug 116872, where the fixes to bug 119458 had a positive impact (the fix was backported with 6.0.7 and 6.1.1).
Comment 8 QA Administrators 2021-01-25 04:17:16 UTC Comment hidden (obsolete)
Comment 9 Marko Mahnič 2021-01-30 07:55:00 UTC 
Version: 7.0.4.2 (x64)
Build ID: dcf040e67528d9187c66b2379df5ea4407429775
CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: sl-SI (sl_SI); UI: en-GB
Calc: CL

Version: 7.0.0.3 (x64)
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win
Locale: sl-SI (sl_SI); UI: en-GB
Calc: threaded