https://bugs.documentfoundation.org/show_bug.cgi?id=173496
Bug ID: 173496
Summary: Regression: Writer Print dialog initializes “Pages”
with the full document range instead of the current
page
Product: LibreOffice
Version: 26.8.0.3 release
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: [email protected]
Reporter: [email protected]
There appears to be a regression in the Print dialog.
When printing from Writer, the "Pages" field used to be initialized
automatically with the page currently containing the cursor. For example, if
the document has 1687 pages and the cursor is currently on page 700, the
expected initial value is:
700
With LibreOffice 26.8.0.3, the field is instead initialized to:
1-1687
The same happens regardless of which page is currently selected.
This is particularly inconvenient because the "Pages" field is effectively
initialized to the same range as "All pages", so the user has to manually
replace the range when intending to print only the current page.
Steps to reproduce:
1) Open a Writer document containing many pages (for example, 1687 pages).
2) Place the cursor on a page somewhere in the middle of the document, e.g.
page 700.
3) Open File → Print.
4) Look at the "Pages" field.
Actual result:
The field contains:
1-1687
instead of the current page.
Expected result:
The field should contain the current page number:
700
(or whatever page currently contains the cursor).
Technical investigation:
This does not appear to be caused by Writer losing knowledge of the current
page. Writer still obtains the current page using GetPageNum() and passes
nCurrentPage to SwPrintUIOptions. Furthermore,
sw/source/uibase/uno/printdata.cxx explicitly initializes the PageRange value
using:
OUString::number(nCurrentPage)
with the comment:
/* set text box to current page number */
Therefore, Writer appears to provide the correct initial value.
The generic VCL print dialog contains code which can subsequently replace the
range with the complete document range. In vcl/source/window/printdlg.cxx,
updatePageRange() constructs:
1-N
where N is the document page count, and writes this value back to the
PrinterController. For a 1687-page document this produces exactly:
1-1687
The relevant sequence appears to be approximately:
Writer
|
| nCurrentPage = 700
| PageRange = "700"
v
PrintDialog
|
| preview update
v
preparePreview()
|
v
updatePageRange(1687)
|
v
PageRange = "1-1687"
The important condition in updatePageRange() is that it operates when the
"Pages" radio button is not active. This suggests that the regression may be
related not to the calculation of nCurrentPage, but to the interaction between:
- PrintContent
- the initial state of the Pages radio button
- PageRange
- the initial preview update.
Historical reference:
The behavior of initializing the print range with the current page was
intentionally introduced by:
be6629ac7481dd68cb2f2b52927f1dcd975d6ac9
“Print current page in the Print dialog”
This commit added the current-page handling to Writer, including passing
nCurrentPage and initializing the page-range edit field with that value.
Therefore, the current behavior in 26.8 appears to be a regression of an
established Writer feature rather than a new feature request.
Suspected regression:
A potentially relevant change is:
25fa5e4 — “Avoid duplicate preview timers”
with parent:
0470118
The reason this commit is suspicious is that it changes the scheduling of
preview updates in the Print dialog. In particular, the previous separate
preview timers were consolidated, and calls now go through
schedulePreviewUpdate(false) / preparePreview(false). This is relevant because
preparePreview(false) can call updatePageRange(), which is the code that
ultimately replaces the current-page value with the complete range 1-N.
I have not bisected the regression to 25fa5e4, so this should be considered a
suspected regression commit rather than a confirmed one.
Request:
Could someone please investigate whether the changes around 25fa5e4 caused an
initial preview update to call updatePageRange() at a point where Writer has
already supplied the current page as PageRange?
In particular, it would be useful to verify whether the intended sequence
should preserve:
PageRange = current page
during the initial construction of the Print dialog, rather than replacing it
with:
PageRange = 1-N
when the Pages radio button is not yet active.
The expected behavior is the one implemented by be6629ac: when opening the
Print dialog from Writer, the Pages field should initially contain the current
page.
--
You are receiving this mail because:
You are the assignee for the bug.
