Sigil-1.9.30 Released

[KevinH]

Understood. If we leave the whole silly issue of dealing with dark mode to the user to handle *before* using print, and with full mathml support, I am pretty sure we can get down to one WebEngine Widget to keep the memory footprint low.

Removing all the dark mode cruft while allowing user css and mathml was the issue.

[DiapDealer]

I see no horrible delays with the new feature on my underpowered, and aging Windows laptop. But then I refuse to work with epubs that have "large" xhtml files.

[RbnJrg]

Originally Posted by KevinH

Understood. If we leave the whole silly issue of dealing with dark mode to the user to handle *before* using print, and with full mathml support, I am pretty sure we can get down to one WebEngine Widget to keep the memory footprint low.

Removing all the dark mode cruft while allowing user css and mathml was the issue.

I think the user can deal with the "dark mode issue" before "printing". By the way, if I choose to print to file (PDF), the .pdf generated by Sigil is huge; that's not happens for the same content in PageEdit.

[KevinH]

Sigil uses a much higher print quality setting, not just screen dpi.

[DiapDealer]

Having to change out of dark mode just to print something might be a little counterintuitive to many users. But if it makes things work better, I'm not opposed. I never print ebooks (or convert them to pdf) anyway.

[RbnJrg]

Originally Posted by DiapDealer

Having to change out of dark mode just to print something might be a little counterintuitive to many users. But if it makes things work better, I'm not opposed. I never print ebooks (or convert them to pdf) anyway.

As I said, I use dark mode and custom .css; so in PP I have white text on a dark background. But I only have to do a mouse click on the respective icon in PP to put black text on a white background. It seems that you (both Kevin and Diap) forgot that valuable feature also in PP

[RbnJrg]

Originally Posted by KevinH

Sigil uses a much higher print quality setting, not just screen dpi.

Can the user to control the printing dpi usted By Sigil?

[DiapDealer]

I think we're going to find that the QPrinter::HighResolution in the Preview dialog is the larger culprit of the overall performance hit, here (as opposed to dark mode diddling). On some only moderately long xhtml files (text and links only), my development machine will lock up waiting on the Print Preview dialog. Remove QPrinter::HighResolution and its display is almost instantaneous.

[KevinH]

We can revert that for the next release if you want.

[RbnJrg]

Originally Posted by KevinH

We can revert that for the next release if you want.

Please, do that. It can't be a .pdf (only text) of just 5 pages with a size of 22MB! Can't be possible to set a medium quality of printing (300/600dpi)?

[KevinH]

I was actually asking DiapDealer that question.

[DiapDealer]

Definitely seeing some historical evidence of different behavior of QPrinter::HighResolution on Unix compared to Windows/Mac. Perhaps an os-based ifdef is in order.

Also, I can crash Sigil on Arch (invalid pointer) by clicking the print button again while waiting on the print preview dialog from the first click. Interestingly enough, the same action will produce the same rare Gumbo assertion error you just fixed recently (with the 1.9.30 codebase). After the fix, there is only the invalid pointer when clicking the button twice.

[KevinH]

Yes, we will need an ifdef. On macOS I need the high dpi setting to get any type of quality pdf generated. I think since Qt on the mac uses pseudo pixels to prevent scaling issues, it produces a very poor 72 dpi instead of something reasonable.

[KevinH]

And if we have to redesign webviewprinter a bit, we may want to have it clean up after itself (delete view widget (if we decide to keep using a second widget) once the printing has concluded. That will reduce the memory footprint instead of waiting until the next print to clear it.

[KevinH]

FWIW, I just tried double clicking fast on the Preview print button but only the first click registered and subsequent clicks were properly ignored on macOS. No issues.