Created attachment 114681 [details]
Stripped down test case that's not working
The .DOC importer now sometimes ignores the Different First Page Headers and Footers flag. I've noticed this in several documents and have made a very simple test case.
Steps to reproduce:
1. Open DifferentFirstPageChecked-good.doc in OpenOffice or MS Word
2. Open DifferentFirstPageChecked-good.doc in LibreOffice Writer
Page 1 should be 0, while Page 2 should be 1.
Created attachment 114682 [details]
Comparision MS Word vs AOO 4.2 vs LO 4.5
Reproducible with LO 126.96.36.199, Win 8.1
But I was wondering what does this number in the header makes? How did you insert it?
It doesn't mean anything. It's just a "zero" and a "one" that I entered with the keyboard. I could have typed anything.
The issue is that when the "Different First Page" flag is set, the general header is supposed to be replaced with the title page header. OpenOffice's importer seems to always honor the flag, while Libreoffice's seems to have problems with complex documents.
Works ok in 3.6, already broken in 4.2.
Ubuntu 14.10 64-bit
Version 188.8.131.52 (Build ID: e183d5b)
Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
Somehow this has ended up the opposite of bug 77111, which traces back to the same commit.
Adding Cc: to email@example.com; Could you possibly take a look at this one? Thanks
Author: Adam Co <firstname.lastname@example.org>
Date: Thu Aug 29 17:16:44 2013 +0300
fdo#44689: fix for specific case of page restart-value 0
This bug fix is for roundtripping a DOCX that has
a specific 'start value' for the page numbers.
In most cases LO imports it ok.
However - until now - Word allowed you to start page number
from 0, while LO only allowed starting page numbers from 1.
This was because the 'start value' was stored in an 'unsigned int',
and the value '0' was used to mark 'there is no start value'.
This patch changes the way the 'start value' is stored
from 'unsigned int' to 'optional unsigned int'.
This way - if there is no value applied - the variable will hold NULL.
However - if a value is set - it can be 0 or more.
This meant also tweaking all the places that used to get this value,
so that now they handle an 'optional uint', instead of a 'uint'.
This issue is still present in
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale: es-ES (es_ES)
on Windows 7 (64-bit)
Migrating Whiteboard tags to Keywords: (bibisected)
Confirmed in 4.2.0, worked in 3.6.7. Set version number accordingly.
Best regards. JBF
*** This bug has been marked as a duplicate of bug 77111 ***
Not a duplicate. This header value (which happens to have 0 in it) is not related to the page number (which however IS zero). That's just coincidence.
The problem is that the very first page header is always stored in the ODD page format, but page 0 is an even page. Either store the EVEN header if the page number is already known (haven't checked into that yet), or else bOdd = bOdd || bFirst (known to work for this document).
Created attachment 130521 [details]
patch that isn't good enough: can't find where FirstLeft is being overwritten
This patch shows that upon initial load, everything is fine, but as soon as you do anything, the first/even header is reset. I haven't located what is causing that reset.
Created attachment 131570 [details]
Stripped down test modified to work
I found the exact setting that breaks our importer.
In Word if I go to
Design->Page Number->Format Page Number->Page Numbering
And I change the value
from "Start at 0"
to "Continue from Previous" OR "Start at 1"
Writer successfully imports the file.
The source of the regression that caused Bug 77111 is the same commit that caused this bug. Do you need to make similar changes to the .doc importer to fix this issue too?
Bug no longer reproducible in
Build ID: 38a8157d9447134913d88c6c373d99a7aa472857
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Closing as RESOLVED WORKSFORME
[Improvement found by office-interoperability-tools]
fixed and backported to 5.4 with bug 94882 by Luke Deller on 2017-08-22 15:07:23 UTC
*** This bug has been marked as a duplicate of bug 94882 ***