https://bugs.documentfoundation.org/show_bug.cgi?id=42673
--- Comment #44 from Mike Kaganski <mikekagan...@hotmail.com> --- Possible code pointers: For Calc, there is ScDocumentConfiguration::setPropertyValue [1], called when loading ODS (other modules might have similar code). It has several cases that call pDocShell->GetPrinter and pDocShell->SetPrinter. The calls may create both system-default printers, and/or printers defined in the document properties (so the problems experienced may depend both on system-default, and non-default printers). The code that makes system calls is, in Windows case, in vcl/win/gdi/salprn.cxx (e.g., WinSalInstance::GetDefaultPrinter calls GetDefaultPrinterW [2], which is documented to possibly block). But that low-level WinSalInstance code is called from Printer class [3], and it is subject to some environment variables (SAL_DISABLE_DEFAULTPRINTER and SAL_DISABLE_PRINTERLIST; see calls to 'getenv') - defining those variables might possibly help workaround the problem. The possible fix could be delay-loading the printer data, only storing the information for initialization in ScDocumentConfiguration::setPropertyValue for a future use, when it is really needed by other code (like display of page breaks). Another possibility would be moving the initialization into separate threads - but that would be likely difficult, given that there might be several printer-related properties in the document, and then asynchronous setting of one of those would still block when another one needs to be set, and thus needs to wait for the first one to finish. [1] https://opengrok.libreoffice.org/xref/core/sc/source/ui/unoobj/confuno.cxx?r=88d8c9af&mo=6051&fi=134#134 [2] https://docs.microsoft.com/en-us/windows/win32/printdocs/getdefaultprinter [3] https://opengrok.libreoffice.org/xref/core/vcl/source/gdi/print.cxx?r=14b21954#442 -- You are receiving this mail because: You are the assignee for the bug.
