Description: Opening any LO document results in "Please wait for printer connection or cancel connection". Clicking cancel opens the document normally. This problem is apparently caused by recent Windows update (confirmed in Windows 11 but I think in Windows 10 as well), replacing all 3rd party print drivers with their own universal IPP print driver. Steps to Reproduce: 1. Update Windows 2. Open LibreOffice document Actual Results: 1. Dialog appears. Must click "cancel" to proceed. Expected Results: Should open document immediately Reproducible: Always User Profile Reset: Yes Additional Info: Work around: The problem goes away after reinstalling my vendor's print driver. However, this option will not work in the future as Microsoft says eventually installing 3rd party print drivers won't be allowed. LibreOffice must be updated to work with Microsoft's IPP Printer Driver. My OS: Edition Windows 11 Pro Version 23H2 OS build 22631.4317 Experience Windows Feature Experience Pack 1000.22700.1041.0 My Printer: HP LaserJet 400 M401dne HP Print driver: upd-pcl6-x64-7.2.0.25780
I should have also said, this happens when the printer is offline or powered off.
Believe we do not need to have a default printer set, and can force LibreOffice to ignore any prior printer by unchecking the 'Load printer settings with document' then saving/reopening the document. Also you can uncheck Windows 'Let Windows manage my default printer'. Then set the os default to a print to file printer. LibreOffice will honor that. The "Microsoft Print to PDF" works well, or look at a ghostscript based PDF printer. But agree there can be issues when a MS generic IPP driver does not fully implement printer device settings that vendor driver. E.g. paper tray, duplexer, document finisher/collator etc. @Mike, what do you think, a future issue for native code to better interface with a Microsoft IPP on Windows builds? Microsoft does seem to be moving to generic IPP [1] =-ref-= [1] https://learn.microsoft.com/en-us/windows-hardware/drivers/print/end-of-servicing-plan-for-third-party-printer-drivers-on-windows
There is no "incompatibility" with printer drivers of any architecture. The problem is that we need to connect to printer for something, which we should avoid until printing. Basically, this is duplicate of bug 42673 - it is not a slightly different, only MS changed their silent timeout into more friendly dialog. *** This bug has been marked as a duplicate of bug 42673 ***
"Believe we do not need to have a default printer set, and can force LibreOffice to ignore any prior printer by unchecking the 'Load printer settings with document' then saving/reopening the document. Also you can uncheck Windows 'Let Windows manage my default printer'. Then set the os default to a print to file printer. LibreOffice will honor that. The "Microsoft Print to PDF" works well, or look at a ghostscript based PDF printer." These are the solutions provided for this bug on other forums. (This issue has been reported many times previously.) However, the comments state these solutions don't work in general. Additionally, changing the default printer would require additional steps whenever printing from any application. So such a workaround, even if it worked in all cases, which they don't, is not ideal. Perhaps just adding an option to bypass the printer connection stuff at startup would be sufficient. Best would be to work with Microsoft's new IPP driver.
(In reply to Mike Kaganski from comment #3) > There is no "incompatibility" with printer drivers of any architecture. The > problem is that we need to connect to printer for something, which we should > avoid until printing. Basically, this is duplicate of bug 42673 - it is not > a slightly different, only MS changed their silent timeout into more > friendly dialog. > > *** This bug has been marked as a duplicate of bug 42673 *** Bug 42673 is 13 years old! With the change Microsoft is making, a lot more folk will be affected. Please at least make this bug a higher priority!
(In reply to Wayne Pollock from comment #5) > Bug 42673 is 13 years old! No, it's at least 20 years old - that's how old the https://bz.apache.org/ooo/show_bug.cgi?id=34140 is.
(In reply to Wayne Pollock from comment #5) > Please at least make this bug a higher priority! And by the way: marking this bug as the duplicate of that one is exactly how we increase the importance of the original bug: the metrics we look for are the number of duplicates, and the number of CCed people. And that one is already High/Major.