Description: After printed document spell check does not underlining the words in that document. Actual Results: Write some text. Print document. Try edit document with unknown words. Theses words (and some existing text) do not underlining with red wave lines. Expected Results: Unknown words should be underlining as in new document before print document. Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: pl Module: TextDocument [Information guessed from browser] OS: Windows (All) OS is 64bit: no
I can confirm this. What I have found is that when one right-clicks the newly entered misspelled word, then this word gets underlined. Otherwise nothing happens. Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: en-CA (en_CA); UI: en-GB Calc: CL threaded
*** Bug 165364 has been marked as a duplicate of this bug. ***
We know from the duplicated bug 165364 that is a problem from 7.0 version, thanks to Stefan ("Since LO version 7 up to version 24.8...").
Stefan description is better, I think. 1. Write text with spelling mistakes (is marked/underlined) 2. Print document 3. Write more text with spelling mistakes (isn't marked/underlined anymore)
(In reply to BogdanB from comment #3) > We know from the duplicated bug 165364 that is a problem from 7.0 version, So why wasn't this bibisected then? It was backported to 7.2.3, starting with commit 20ddabc88b6b45ea3efcc44ede5244ea526b09c4 Author: Michael Stahl on Thu Nov 4 18:50:42 2021 +0100 tdf#144989 sw: disable idle jobs during printing or PDF export Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124721
The problem here is that 'BlockIdling' is a counter, and it is being blocked more often than it is being unblocked. Fixing for PDF should be easy - that just looks like PDFExport::Export + pDoc->getIDocumentTimerAccess().BlockIdling(); const sal_Int32 nPageCount = xRenderable->getRendererCount ... ... if ( mxStatusIndicator.is() ) mxStatusIndicator->end(); + pDoc->getIDocumentTimerAccess().UnBlockIdling(); However, for the print dialog, it isn't so clear. Currently first blocks in PrintDialog::PrintDialog. I guess that since in the past 4 years there is no massive functionality break reported in the print dialog, we could simply explicitly block in the CTOR, and unblock in the DTOR. But now, how to tell XRenderable to Prepare/Finish...