Description: Number of pages in a document changed from 954 to 979 since 5.3 Steps to Reproduce: 1. Open the attached file 2. Page counter shows stored info: 980 = wrong 3. Wait 30 seconds or update the index with 5.2 and prior 954. With 5.3 976 With 6.0 979 4. Save the file to doc 5. File -> Reload -> 954 (or update index) -> What should be expected.. Actual Results: th 5.2 and prior 954. With 5.3 976 With 6.0 979 4. Save the file to doc 5. File -> Reload -> 954 (or update index).. Expected Results: 954 Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: a35c18aeff3b1d8f270db7e094850fb8ba1ab84a CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL and 5.3
Created attachment 162076 [details] Bibisect log I attempted a bibisect..Windows/Linux but ended up crashing; skipping; crashing.. Hoping someone else with more bibisect experience.. to reduce the range some more
Created attachment 162077 [details] Example file
Note.. in the given range is probably one page difference .. so 953 instead of 954.. started by enabling Harfbuzz again.. The layout engine doesn't matter, so opting for old layout engine is probably the best choice export SAL_USE_COMMON_LAYOUT=0
Reproduced in: Version: 7.1.0.0.alpha0+ (x64) Build ID: 33a720ab802491f15b247e09755cd36205b6f435 CPU szálak: 4; OS: Windows 10.0 Build 17134; Felületmegjelenítés: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: CL
not a hight/critical bug at all. @Telesto, any chance we could have a minimal document?
(In reply to Xisco Faulí from comment #5) > not a hight/critical bug at all. > @Telesto, any chance we could have a minimal document? -> I really, really disagree: it's high/major at minimum. It means a really unstable layout.. You write a book, expect 979 pages.. export it to doc and you get 945? I'm would become pretty (actual more extremely) nervous/scared. And would have practical consequences too. Say I work with ODS.. I save a file to DOC for sharing. I write an email.. look at page 340.. Page 340 ODS is not Page 340 doc. I really would consider looking for another product.. if you can't even get the page count right! Export PDF -> 979 Print -> 978 Export DOC: 945 Copy DOC RTF paste -> 945 Save RTF -> 943 It was always proper, from 4.0.0.3 to 5.2.. It's going under the radar for way to long.. And if the result would be consistent all over the board.. not nice, but fine.. however it's different depending what you do And the number of pages is quite essential feature, IMHO. This is one of those issues where people with large docs complain about.. --- Feel free to create.. however this type of issue start at certain number of pages.. the deviation will become rather small.
And talking about priority.. There quite a number of bugs with a quite dubious HIGHEST/HIGH setting, for my taste.. And based on your pattern of downgrades bugs, I increased probably even more (even if i'm not only the reporter, but also the one who increased priority). And I also wonder.. how can a bug still high priority after 6 or 12 months by default. The should be reset to normal, or get a special status.. wish-list.. but high priority makes no sense.. else someone would have picked it up already.
As long as there's no data loss, the number of pages is irrelevant. Spacing issues make the documents have less or more pages. Depending on the space available, images will be placed on one page or the next one. Nothing wrong with that. IMHO, this issue should be splitted into different issues with minimal reproducers which address each particular issue the document has, if any. For me, having a different number of pages is not an issue per se. By the way, don't be so irresponsible to write a 900+ pages document. Use master documents for that
(In reply to Xisco Faulí from comment #8) > As long as there's no data loss, the number of pages is irrelevant. Spacing > issues make the documents have less or more pages. Depending on the space > available, images will be placed on one page or the next one. Nothing wrong > with that. (A) The doc in question has no images.. so that can be ruled out. (B) Nice, but what about RTF paste & DOC export.. what makes that it fitting on exact 954 pages.. It would be consistent.. expect of data got lost.. And it would matter to 2/3 pages.. not the 25 pages.. quite a lot! > By the way, don't be so irresponsible to write a 900+ pages document. Use > master documents for that (A) Tell that the author the specific document attachment 161979 [details] (B) Quite some documents with 450 - 750 pages around.. Or its the advice to use hard page break on every page.. to prevent some page flow issue.. The footnotes in the bug doc are the likely the cause.. and let there be an overall issue with footnotes + layout.. And this still is a regression; as it has been working before, not by an incident.. it worked until 5.3 came along.. and someone broke it. This can happen on every file opening.. and this is not the first report about something fishy with the page numbering.. But there is always an argument.. different font rendering, different layout because of anchoring.. to many pages.. cross page tables.. In this case someone obviously broke something.. and is not a minor shift in pages. Nearly everything is ruled out in this bug, except for many pages and footnotes
(In reply to Telesto from comment #0) > Description: > Number of pages in a document changed from 954 to 979 since 5.3 > > Steps to Reproduce: > 1. Open the attached file > 2. Page counter shows stored info: 980 = wrong > 3. Wait 30 seconds or update the index with 5.2 and prior 954. > With 5.3 976 > With 6.0 979 With the oldest of both Win 5.2 and 5.3 repo, I see 992 pages after step 3 update index. Does the document use some non-standard fonts that not everyone has? With this sort of a topic, I think this would make testing a nightmare. Please advise.
From older version to now, the way changed, how padding is handled. In older versions it was (erroneously) ignored, if no border was set. In current versions padding is interpreted in all cases. In the attached document the problem is in paragraph style "Footnote". In the tab "Border" it has set a padding of 0.3cm. Set it to 0cm in the current version and the page count will be the same as in older versions.
(In reply to Regina Henschel from comment #11) > From older version to now, the way changed, how padding is handled. In older > versions it was (erroneously) ignored, if no border was set. In current > versions padding is interpreted in all cases. > > In the attached document the problem is in paragraph style "Footnote". In > the tab "Border" it has set a padding of 0.3cm. Set it to 0cm in the current > version and the page count will be the same as in older versions. Ah, thanks for the explanation Regina! So not a bug after all..
*** Bug 133401 has been marked as a duplicate of this bug. ***