This touches UX (but likely more DEV department).. But kind of include person... so here it goes

Yes, lengthy operations should be done in the background. If possible, the thread should be canceled and/or paused by the user. And feedback on demand regarding the progress is also needed.

But I wonder how much processing is done on our side. Isn't the print job forwarded to the OS specific handler?

(In reply to Heiko Tietze from comment #2)
> But I wonder how much processing is done on our side. Isn't the print job
> forwarded to the OS specific handler?

What happens at least on Linux is basically:

1) LO generates PDF (or PostScript, if that option is set) print data
2) LO hands that over to CUPS (the printing system)

Moving 1) to a separate thread and editing the document (model) while it's being "converted" *might* cause inconsistencies (or at least require additional measures to avoid that, but I don't what happens here exactly)

After 2), LO is no longer be "blocked", since the LO part is done and everything else happens on CUPS side and is "independent" of LO

(In reply to Michael Weghorn from comment #3)
> (In reply to Heiko Tietze from comment #2)
> > But I wonder how much processing is done on our side. Isn't the print job
> > forwarded to the OS specific handler?
> 
> What happens at least on Linux is basically:
> 
> 1) LO generates PDF (or PostScript, if that option is set) print data
> 2) LO hands that over to CUPS (the printing system)
> 
> Moving 1) to a separate thread and editing the document (model) while it's
> being "converted" *might* cause inconsistencies (or at least require
> additional measures to avoid that, but I don't what happens here exactly)
> 
> After 2), LO is no longer be "blocked", since the LO part is done and
> everything else happens on CUPS side and is "independent" of LO

FWIW, as I tend to mix topic together
1) The origin of this bug is the printjob on Windows being really, really slow (for large jobs). It's appears to me the printer spooler being directly accessed (on Windows), without PDF creation step in between.. This based on the experience of PDF export being simply twice as fast on Windows, only sending a printjob slow (accessing fonts and stuff repeatedly). [No actual code knowledge]

2) Word 2003 has no progress bar at all (only a printer progress icon in status bar). Showing a printjob being send. 
It would be an improvement already if only a progress bar is shown for 'PDF conversion' LibreOffice getting unlocked at the point where they PDF is send to printer. And harmonize Windows/Linux code as far as possible (assuming I'm correct - mostly NOT the case - by assuming the printjob being handled differently on Windows]

-> And you could use they PDF progress bar, instead of the print progress dialog. I can't really stand that dialog anymore ;-).  

So separate thread must not be interpreted to strict from my perspective. Only suggesting an approach. Not necessary the needed approach. So not asking for rigorous overhaul if it can be improved a lot with some tweaking...

(In reply to Michael Weghorn from comment #3)
> What happens at least on Linux is basically:
> [...]

Just to emphasize that: My comment 3 was actually for Linux. Windows (and it's printing system) may well be a completely different thing.

(In reply to Michael Weghorn from comment #5)
> (In reply to Michael Weghorn from comment #3)
> > What happens at least on Linux is basically:
> > [...]
> 
> Just to emphasize that: My comment 3 was actually for Linux. Windows (and
> it's printing system) may well be a completely different thing.

I fear so, sadly :P. I personally preference/ideal  as much shared code/ behavior as possible.. If a PDF is generated under Linux and send to cups, maybe similar approach could be used under Windows (except the cups part of course).

@Offtopic
There are currently to many discrepancy with different back-ends (Skia/GDI/QT/GTK3), printing (in this case) or epub (slow under windows, not Linux). Now Linux/Mac users are complaining about image perf issues (previously a Windows issue), now gone under Windows (thanks to Skia). But reshuffling bugs not really helpful.  And with some bad luck the fix for solving the perf issue under Linux/Mac will bring back issues for Windows/Skia (Raster and/or Vulkan)

(In reply to Telesto from comment #6)
> I fear so, sadly :P. I personally preference/ideal  as much shared code/
> behavior as possible.. If a PDF is generated under Linux and send to cups,
> maybe similar approach could be used under Windows (except the cups part of
> course).

Yes, shared code is usually preferable. However, from the little knowledge I have about the Windows printing system, I think it just works differently and you can't just pass it a PDF file, and LO has to adhere to the way that the Windows printing system can be interacted with... (i.o.w. the designers of the Windows printing system and of the Linux printing system, CUPS, have made different decisions, and that's nothing LO can easily change.)

Dear Telesto,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug