Description: Page metadata not used, keeps counting page on each file open Steps to Reproduce: 1. Open the attached file 2. Notice the page counter running 3. Save (after finish) 4. Reload FWIW -> Comments are not truly needed, but makes it more noticible Actual Results: Page counter is running on each file-open Expected Results: Page counter should show the number of pages based on metadata Reproducible: Always User Profile Reset: No Additional Info: Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7f4868348c14b305fcd75744e1e3544d0d3a5d61 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
Created attachment 202193 [details] Sample
@buovjaga This is in essence same file as bug 167775. Except I added quite a number of page-breaks. I would expect the page count metadata being present. Why isn't it used?
Indeed, in meta.xml we have meta:page-count="68". Checking in Windows 25.8 bibisect repo, apparently this issue was masked by the issue that was fixed with b6bcc7ac278e0db22df02707789730ec123bf934
Page count metadata is 100% irrelevant, and is not used for layout at all. It is for external readers that scan file, and report its properties without doing the proper layout: e.g., Windows Explorer file properties extension. In layout, what *could* be used, is the last page break elements inserted in the markup; but even that isn't used in our layout, as far as I know. *That* could possibly be used for potential speedup in the future (which would be an enhancement).
(In reply to Mike Kaganski from comment #4) > Page count metadata is 100% irrelevant, and is not used for layout at all. > It is for external readers that scan file, and report its properties without > doing the proper layout: e.g., Windows Explorer file properties extension. > In layout, what *could* be used, is the last page break elements inserted in > the markup; but even that isn't used in our layout, as far as I know. *That* > could possibly be used for potential speedup in the future (which would be > an enhancement). Thanks, I created bug 167828 for that to start from a clean slate.