Writer allows to design COMPLETE books include front and back covers. The covers are usually made in a different material from book contents and are added (glued) at a late step in manufacturing. When it comes to count the pages, covers are excluded. Similarly, we can write a letter and keep the envelope in the same file. The fact that the envelope is part of the file renders quite useless the field "Page Count" to number the letter sheets as "x of y". There are complicated workarounds to display the "real" number of pages based on cross-references, but these workarounds are not in the immediate reach of most users. The Ask LO site shows that excluding pages from the count is a frequent requirement. My suggestion is to add a check box in the page style configuration dialog, perhaps in the Page tab: [ ] Exclude this style from page count. This may require the definition of a new field because ODF 1.3 § 7.5.18.2 states that the present Page Count field displays the count from "<meta:document-statistic>" and all pages should be kept in statistics. Alternatively, the present Page Count could be reassigned to a new field clearly identified as a statistics field because most users don't use the field for statistics but as a count of "meaningful" pages (page x of y where y is supposed to omit envelope, covers and others).
ADDENDUM My suggestion is similar to a feature of paragraph styles. In Outline & List tab, there is a checkbox [x] Include this paragraph in line numbering. This box is ticked by default. For consistency and uniformity reason, the kind of wording could be used in my proposal ("Include" instead of "Exclude") with the corresponding default.
After a quick search in Ask LibO I found a result that better explains the use case for this request: https://ask.libreoffice.org/t/writer-section-page-count-in-footer/41763 BTW the OP is the one who provided the chosen solution. I believe this is a valid request. Let's hear from the UX team.
Clearly a desired feature. MSO allows to manipulate field variables via "Insert field characters" (Ctrl+F9) and "{ = {NUMPAGES} - 1 }". Quite tedious too. And saving this as ODF document breaks the formula. Besides introducing a standard approach to not count pages with a certain style, I wonder if we should also consider bug 71583 "There is no page count field for different page styles or sections", which requests "page 1 of 10" for one part of the document and another "page 1 of 10" for a different part. A duplicate resp. different use case is bug 149981 "Footer Page numbers with endnotes". Usually we make the newer ticket a duplicate of the older but in this case I'd prefer the more generic description. And we have a kind of see also bug 99189 "Add option to exclude footnotes, endnotes and textboxes and inline citations from word count".
*** Bug 149981 has been marked as a duplicate of this bug. ***
(In reply to Heiko Tietze from comment #3) > Besides introducing a standard approach to not count pages with a certain > style, I wonder if we should also consider bug 71583 "There is no page count > field for different page styles or sections", which requests "page 1 of 10" > for one part of the document and another "page 1 of 10" for a different part. I read the request in bug 71583 but the suggestion of creating a field page-count-for-style does not solve the question for counting pages in chapters or parts, at least for me. My chapters are all laid out with the same page style with "dynamic" header and footer, thanks to fields. A style-page-count field would give me the total number of pages consumed by all chapters. In addition what constitutes a "part" has as many definitions as there are users. The only common criterion is: a part starts with a page break and ends with a page break. Consequently we could have a new setting in the manual page break dialog to restart page count. Related to this, a new field needs to be defined to return the value of the current part page count. We have then three fields: -1- the present Page Count field returning the effective total number of pages (related to document statistics, according to ODF) -2- a field omitting the pages excluding from the count -3- a field for the current "part" defined by the aforementioned setting in the page break dialog -2- covers the request for "This books contains x pages", not counting covers et al. -3- covers the request for chapters However, it is not possible to have "My document is 132 pages long including 14 appendix pages." because there is presently no way to capture a field value into a variable. This could be another enhancement request.
(In reply to ajlittoz from comment #5) > Consequently we could have a new setting in the > manual page break dialog to restart page count. My approach was to exclude page styles from the total count (and ditch the request in bug 71583). Restarting the count makes it somewhat inconsistent and error-prone thinking of moving a page around. But nevertheless worth to discuss, back to UX.
(In reply to Heiko Tietze from comment #6) > (In reply to ajlittoz from comment #5) > My approach was to exclude page styles from the total count (and ditch the > request in bug 71583). Restarting the count makes it somewhat inconsistent > and error-prone thinking of moving a page around. You're right. I was only trying to consolidate both requests. Implementing bug 71583 would be quite tricky because it requires to maintain one count per page sequence (delimited by "special" manual page breaks) and "page sequences" are not primary objects in Writer.
We discussed this topic in the design meeting. Adding some flag to the page break means to have it on the paragraph style, which would be quite odd. The idea of a page style attribute to include/exclude a certain styles from counting seems to be better. Such an option could be handy on other modules too, for example bug 115288. We also discussed briefly bug 71583 and believe there are use cases where counting a certain kind of page styles makes sense (eg. pages with images). But this number wouldn't be the total number of pages usable as variable in the document but rather some kind of document information.
*** Bug 154809 has been marked as a duplicate of this bug. ***
*** Bug 157078 has been marked as a duplicate of this bug. ***