Bug 91306 - ODF export: Page number 0 (zero) cannot be stored - filed OASIS proposal
Summary: ODF export: Page number 0 (zero) cannot be stored - filed OASIS proposal
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.7.2 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL: https://issues.oasis-open.org/browse/...
Whiteboard: odf
Keywords:
Depends on:
Blocks: ODF-export-invalid Fields-Page-Number
  Show dependency treegraph
 
Reported: 2015-05-15 13:06 UTC by Toni Ballesta
Modified: 2018-08-22 16:48 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Toni Ballesta 2015-05-15 13:06:55 UTC
When I insert Manual Break with "Default Style", I can select "Change page number" with value 0. It works and the next page is 0, but when I close the document and re-open, the page doesn't saved and is consecutive from the previous page.

This problem doesn't ocurr when I select value 1 or more: the document closed and restored ok.

===============

Example 1 (Problem):
- Creating document aaa
Page 1
Page 2
- Manual break starting page 0
Page 0
Page 1
- Save and close aaa
- Open aaa
Page 1
Page 2
Page 3
Page 4

===============

Example 2 (No problem):

- Creating document bbb
Page 1
Page 2
- Manual break starting page 1
Page 1
Page 2
- Save and close bbb
- Open bbb
Page 1
Page 2
Page 1
Page 2

===============

Regards.
Comment 1 Jan 2015-05-15 13:35:03 UTC
I can confirm the bug in LO 4.3.7.2 and LO 5.0 (trunk). The bug seems to be triggered by setting page-number to 0. If saving to odt content.xml contains the following line with "auto" instead of "0". 

<style:paragraph-properties style:page-number="auto"/>

Same works in docx so its a odt only bug.
Comment 2 Jan 2015-05-15 13:50:07 UTC
This seems to be a regression from commit 22355042a6fc7aecf3caab69b3fa3be1430b697f or bug #72452. However, it seems 0 is somehow not allowed in ODT. Therefore, its not clear to me how to fix this properly. There a several options:
a) Revert the "auto" part from the commit and allow to write 0 to ODT (need to change specs?)
b) Disallow 0 in gui (what happens when importing docx with page-number 0?)
c) Fix it in another way?
Comment 3 Michael Stahl (CIB) 2015-05-15 14:01:03 UTC
it's not a regression because page number 0 is a new feature (for MSO interop).

as the commit from comment #3 says:

    Unfortunately the type of style:page-number is positiveInteger so
    writing 0 would be invalid; write "auto" instead for now.

maybe we should do something about preventing 0 in the UI,
so it can only be set when you import MSO documents.
Comment 4 Jan 2015-05-16 09:58:27 UTC
I agree that b) is probably the best option. However, what should happen if sb loads an docx and saves it to odt? A warning that he might loose functionality because he uses odt? Would look kind of odd to me.
Comment 5 Thorsten Behrens (CIB) 2016-04-29 13:05:45 UTC
(In reply to Michael Stahl from comment #3)
> maybe we should do something about preventing 0 in the UI,
> so it can only be set when you import MSO documents.

Or maybe file this with OASIS:

--- OpenDocument-v1.2-cs01-schema.rng	2016-02-10 11:17:46.078922673 +0100
+++ OpenDocument-v1.2-cs01-schema.rng	2016-04-29 15:02:57.099053854 +0200
@@ -15663,7 +15663,7 @@
 		<optional>
 			<attribute name="style:page-number">
 				<choice>
-					<ref name="positiveInteger"/>
+					<ref name="nonNegativeInteger"/>
 					<value>auto</value>
 				</choice>
 			</attribute>

? It's a widening spec change, so perhaps uncontroversial?
Comment 6 Michael Stahl (CIB) 2017-03-01 11:27:14 UTC
filed OASIS proposal
https://issues.oasis-open.org/browse/OFFICE-3923
Comment 7 Toni Ballesta 2017-03-06 21:10:38 UTC
Sorry, but in the new release version this bug is not solved.
Comment 8 QA Administrators 2018-07-27 02:41:51 UTC Comment hidden (obsolete)
Comment 9 Michael Stahl (CIB) 2018-07-27 08:46:53 UTC
the OASIS proposal was accepted for ODF 1.3 so we just need to wait until the process is a bit further along with some committee draft or so and we have an ODF 1.3 export, then we can fix it
Comment 10 Toni Ballesta 2018-08-22 16:48:00 UTC
(In reply to Michael Stahl from comment #9)
> the OASIS proposal was accepted for ODF 1.3 so we just need to wait until
> the process is a bit further along with some committee draft or so and we
> have an ODF 1.3 export, then we can fix it

Thanks Michael for the clarification (the recent LO 6.0.6 have the same issue).