Does it happen for all PDFs, or just some specific ones? Can you please share that specific PDF which can't be printed?

Created attachment 104598 [details]
Original plus re-rendered pdf from Libreoffice Draw

Not all PDFs are affected so I guess it depends on how images are included in the PDF. It seems 50% of PDFs I have downloaded recently. It may be significant that these are from sites which generate PDFs on demand like utility bills. Being a web developer I know there are a variety of back end libraries which output PDF files for download.
The Libreoffice output may give the clue as to what is re-written to then be acceptable to Okular.

You attached two files but didn't give any hint as to which one is supposed to be the original and which is not.

DM200_UM_EN.pdf is the original and DM200_UM_EN_3.pdf is the re-saved version from Libre Office

All files I have tried open and print as expected with LibreOffice Draw. The print dialogue displays a scaled view of the document. Is this dialogue available to Okular or is it part of LibreOffice? It may be a good place to start by looking at the processing for print in Okular. Could these libraries be used? Just a thought?

I just printed the example file into a pdf file using the current Okular git master.  That worked flawlessly, besides the fact that a few fonts got rasterized (which may be a feature).

BTW, printing still involves conversion to postscript and a call to gs, so your problem may be in that direction.  Looking at the intermediate files may be interesting, but I do not know how to do that.

There still is the 'pdfprintpdf' branch which removes the postscript indirection, but I do not know what state it is in.

Created attachment 104687 [details]
Another file which will not print

I have just built from Git repo and now have v1.1.7 in place of 1.0.3 however this does not resolve printing. I'm attaching another apparently normal PDF manual which does not print.

Building branch pdfprintpdf to see what that does?

OK the pdfprintpdf branch seems to make no difference. Builds as v1.0.7

Your bug seems very much like the bug where the broken gs interpreter breaks everything https://bugs.kde.org/show_bug.cgi?id=371887

Checked the gs on my system which is 9.20 the init file has the mod suggested in the gs issue. Is there some debug I can get to tell us what is going on? The current journal output may not give the detail needed?

I just tried to reproduce with one of the attached documents and did not encounter the problem.

Is the problem still present for you?
Is it specific to a specific printer? (As a test, you can try for example whether the problem also occurs with the "CUPS-PDF" printer that prints to a file if you just have one physical device.)

If so, could you please attach the PPD file of the printer on which the problem occurs for you? (It should be located at /etc/cups/ppd/<PRINTERNAME>.ppd .)

(In reply to Michael Weghorn from comment #14)
> I just tried to reproduce with one of the attached documents and did not
> encounter the problem.
> 
> Is the problem still present for you?
> Is it specific to a specific printer? (As a test, you can try for example
> whether the problem also occurs with the "CUPS-PDF" printer that prints to a
> file if you just have one physical device.)
> 
> If so, could you please attach the PPD file of the printer on which the
> problem occurs for you? (It should be located at
> /etc/cups/ppd/<PRINTERNAME>.ppd .)

I'm setting the status to NEEDINFO, since the question has not been answered yet and that additional information is required to analyse the problem further.

Returning to this problem I have checked if this is specific to the Printer driver WF-2530 Series, Epson Inkjet Printer Driver (ESC/P-R) for Linux () the same result of 0 pages and no preview content occurs if I select another printer  such as Google cloud print 1.0 (print to Google drive)
The Journal output for "Print Preview" with the Epson selected is:


May 20 09:02:50 sabayonx86-64 dbus[2232]: [system] Activating via systemd: service name='org.freedesktop.Avahi' unit='dbus-org.freedesktop.Avahi.service'
May 20 09:02:50 sabayonx86-64 dbus[2232]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.Avahi.service': Unit dbus-org.freedesktop.Avahi.service not found.
May 20 09:02:50 sabayonx86-64 dbus[2232]: [system] Activating via systemd: service name='org.freedesktop.Avahi' unit='dbus-org.freedesktop.Avahi.service'
May 20 09:02:50 sabayonx86-64 dbus[2232]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.Avahi.service': Unit dbus-org.freedesktop.Avahi.service not found.
May 20 09:02:50 sabayonx86-64 okular[1392]: Settings::instance called after the first use - ignoring
May 20 09:02:50 sabayonx86-64 plasmashell[3137]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:334: Unable to assign [undefined] to int
May 20 09:02:50 sabayonx86-64 plasmashell[3137]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:334: Unable to assign [undefined] to int
May 20 09:02:50 sabayonx86-64 okular[1392]: org.kde.okular.generators.spectre: Generated image does not match wanted size: [0x0] vs requested [576x815]
May 20 09:02:50 sabayonx86-64 okular[1392]: QImage::scaled: Image is a null image
May 20 09:02:50 sabayonx86-64 okular[1392]: org.kde.okular.generators.spectre: Generated image does not match wanted size: [0x0] vs requested [565x799]
May 20 09:02:50 sabayonx86-64 okular[1392]: QImage::scaled: Image is a null image
May 20 09:02:51 sabayonx86-64 okular[1392]: org.kde.okular.generators.spectre: Generated image does not match wanted size: [0x0] vs requested [565x799]
May 20 09:02:51 sabayonx86-64 okular[1392]: QImage::scaled: Image is a null image
May 20 09:02:51 sabayonx86-64 okular[1392]: org.kde.okular.generators.spectre: Generated image does not match wanted size: [0x0] vs requested [80x113]
May 20 09:02:51 sabayonx86-64 okular[1392]: QImage::scaled: Image is a null image
May 20 09:02:52 sabayonx86-64 plasmashell[3137]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:334: Unable to assign [undefined] to int

Trying to resolve the "dbus-org.freedesktop.Avahi.service" issue as in https://bugs.archlinux.org/task/31470 does not solve the issue. The result is still "QImage::scaled: Image is a null image" etc

Created attachment 112761 [details]
Epson WF2530 ppd file

As above the journal output when launching print preview and the missing symlink for launching avahi-daemon results in a second attempt to launch the daemon. I'll keep this symlink as the result is tidier

May 20 10:08:09 sabayonx86-64 dbus[2234]: [system] Activating via systemd: service name='org.freedesktop.Avahi' unit='dbus-org.freedesktop.Avahi.service'
May 20 10:08:09 sabayonx86-64 systemd[1]: Starting Avahi mDNS/DNS-SD Stack...
May 20 10:08:09 sabayonx86-64 systemd[1]: avahi-daemon.service: Main process exited, code=exited, status=255/n/a
May 20 10:08:09 sabayonx86-64 avahi-daemon[5869]: Daemon already running on PID 0
May 20 10:08:09 sabayonx86-64 systemd[1]: Failed to start Avahi mDNS/DNS-SD Stack.
May 20 10:08:09 sabayonx86-64 systemd[1]: avahi-daemon.service: Unit entered failed state.
May 20 10:08:09 sabayonx86-64 systemd[1]: avahi-daemon.service: Failed with result 'exit-code'.
May 20 10:08:11 sabayonx86-64 plasmashell[3162]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:334: Unable to assign [undefined] to int
May 20 10:08:11 sabayonx86-64 plasmashell[3162]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:334: Unable to assign [undefined] to int
May 20 10:08:34 sabayonx86-64 dbus[2234]: [system] Failed to activate service 'org.freedesktop.Avahi': timed out
May 20 10:08:34 sabayonx86-64 dbus[2234]: [system] Activating via systemd: service name='org.freedesktop.Avahi' unit='dbus-org.freedesktop.Avahi.service'
May 20 10:08:34 sabayonx86-64 systemd[1]: Starting Avahi mDNS/DNS-SD Stack...
May 20 10:08:34 sabayonx86-64 avahi-daemon[5917]: Daemon already running on PID 0
May 20 10:08:34 sabayonx86-64 systemd[1]: avahi-daemon.service: Main process exited, code=exited, status=255/n/a
May 20 10:08:34 sabayonx86-64 systemd[1]: Failed to start Avahi mDNS/DNS-SD Stack.
May 20 10:08:34 sabayonx86-64 systemd[1]: avahi-daemon.service: Unit entered failed state.
May 20 10:08:34 sabayonx86-64 systemd[1]: avahi-daemon.service: Failed with result 'exit-code'.

May 20 10:08:59 sabayonx86-64 dbus[2234]: [system] Failed to activate service 'org.freedesktop.Avahi': timed out
May 20 10:08:59 sabayonx86-64 okular[3547]: Settings::instance called after the first use - ignoring
May 20 10:08:59 sabayonx86-64 plasmashell[3162]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:334: Unable to assign [undefined] to int
May 20 10:09:00 sabayonx86-64 okular[3547]: org.kde.okular.generators.spectre: Generated image does not match wanted size: [0x0] vs requested [576x815]
May 20 10:09:00 sabayonx86-64 okular[3547]: QImage::scaled: Image is a null image
May 20 10:09:00 sabayonx86-64 okular[3547]: org.kde.okular.generators.spectre: Generated image does not match wanted size: [0x0] vs requested [565x799]
May 20 10:09:00 sabayonx86-64 okular[3547]: QImage::scaled: Image is a null image
May 20 10:09:00 sabayonx86-64 okular[3547]: org.kde.okular.generators.spectre: Generated image does not match wanted size: [0x0] vs requested [80x113]
May 20 10:09:00 sabayonx86-64 okular[3547]: QImage::scaled: Image is a null image

This sounds a bit similar to bug 385456. Is there any useful output when starting Okular from the command line?

There may be something here in the output from the command line. Once the print preview is requested we get:

Settings::instance called after the first use - ignoring
invalidfont -10
invalidfont -10
org.kde.okular.generators.spectre: Generated image does not match wanted size: [0x0] vs requested [576x815]
QImage::scaled: Image is a null image
invalidfont -10
invalidfont -10
org.kde.okular.generators.spectre: Generated image does not match wanted size: [0x0] vs requested [565x799]
QImage::scaled: Image is a null image
invalidfont -10
invalidfont -10
org.kde.okular.generators.spectre: Generated image does not match wanted size: [0x0] vs requested [80x113]
QImage::scaled: Image is a null image

Surely any fonts not on the system should be substituted by local fonts? The simpler qpdfview seems to print the same files OK I guess using local fonts and can handle the image embed coding even if it is incorrect. 

How is the the avahi-daemon.service involved? Is this a result of the font/image issue where it seems to try to re-launch the daemon rather than simply using the running instance?

Resolved the avahi-daemon failure as in https://bugzilla.redhat.com/show_bug.cgi?id=1050201

"I had some stale files in /var/run/avahi-daemon, cleaning those out seems to have fixed it"

However the Journal output to display print preview is now:

May 24 00:59:34 sabayonx86-64 okular[24434]: Settings::instance called after the first use - ignoring
May 24 00:59:34 sabayonx86-64 okular[24434]: org.kde.okular.generators.spectre: Generated image does not match wanted size: [0x0] vs requested [576x815]
May 24 00:59:34 sabayonx86-64 okular[24434]: QImage::scaled: Image is a null image
May 24 00:59:35 sabayonx86-64 okular[24434]: org.kde.okular.generators.spectre: Generated image does not match wanted size: [0x0] vs requested [565x799]
May 24 00:59:35 sabayonx86-64 okular[24434]: QImage::scaled: Image is a null image
May 24 00:59:35 sabayonx86-64 okular[24434]: org.kde.okular.generators.spectre: Generated image does not match wanted size: [0x0] vs requested [565x799]
May 24 00:59:35 sabayonx86-64 okular[24434]: QImage::scaled: Image is a null image
May 24 00:59:35 sabayonx86-64 okular[24434]: org.kde.okular.generators.spectre: Generated image does not match wanted size: [0x0] vs requested [80x113]
May 24 00:59:35 sabayonx86-64 okular[24434]: QImage::scaled: Image is a null image

Good that the avahi issue is solved now.

What versions of libspectre and ghostscript do you have?

These are the current versions
libspectre 0.2.8 (January 06, 2017)
ghostscript 9.21 (May 19, 2018)

(In reply to Ian Newton from comment #23)
> These are the current versions
> libspectre 0.2.8 (January 06, 2017)
> ghostscript 9.21 (May 19, 2018)

I can't reproduce the described bug with the versions that are currently contained in Debian testing, i.e. libspectre 0.2.8 and ghostscript/libgs9 9.22.

However, I am able to reproduce when using the older libgs9, version 9.21.

It seems the bug has been fixed in a newer Ghostscript version.
Do you have the possibility to try whether the problem goes away for you with a 
Ghostscript version >= 9.22?

My distribution is currently on gs 9.21 so I have located and compiled from source gs 9.23

$ gs -v
GPL Ghostscript 9.23 (2018-03-21)
Copyright (C) 2018 Artifex Software, Inc.  All rights reserved.

Unfortunately this does not fix the problem.

Looking again at the output when launched from the command line it looks like libspectre is having a problem with the rendering.

invalidfont -10
org.kde.okular.generators.spectre: Generated image does not match wanted size: [0x0] vs requested [80x113]
QImage::scaled: Image is a null image

Or is the origin a problem fonts or font substitution?

I actually do get similar error messages when using Ghostscript 9.21 instead of 9.22, but it works fine with version 9.22 in my case.

libspectre itself uses Ghostscript, or to be more precise, the Ghostscript library, libgs.

Therefore, you need to make sure that the self-compiled libgs is used.
I did not mention it that explicitly before; these are possible steps to achieve this (maybe you already did this...):

* build the library by using the command 'make so' from the directory containing the Ghostscript sources

* locate the library (so file), which was in the 'sobin' subdirectory in my case:
$ find . -name libgs.so.9

* set the environment variable 'LD_LIBRARY_PATH' to the path of the directory holding the 'libgs.so.9' file and start okular with the sample file, e.g.
$ LD_LIBRARY_PATH=/path/to/ghostscript/sobin okular atcom_ip0x_quick_start_guide.pdf

* test whether the behaviour is still the same

In order to verify that the self-compiled library is actually used, you can e.g. use 'strace' to start okular and see from where the libray is loaded, e.g.
$ LD_LIBRARY_PATH=/path/to/ghostscript/sobin strace -f -o /tmp/strace-output.log okular atcom_ip0x_quick_start_guide.pdf
$ grep open /tmp/strace-output.log | grep libgs

The output should then indicate the path of the library being used.

Did you do this already? If so, it seems I'm unable to reproduce the exact issue you had...

Great your analysis was spot on!

Compiling again to get the libgs.so.9.23 file allowed me to manually replace the libgs.so.9.21 file and sym-links libgs.so and libgs.so.9 in /usr/lib64 on my system. This worked straight away showing that the ghostscript version was the problem.

Now I must persuade the packaging team at Gentoo/Sabayon to include this later version as it is a dependency for many packages. There may be an issue in that they chose 9.21 as the last fully GPL licensed version. 

Ghostscript as you surely know is heading for a commercial licensing model which may be holding back inclusion in core repositories. Which would also be the case for other distributions. 

In the meantime I know what to do if it breaks by being replaced by the 9.21 version files.

Many thanks!

Created attachment 113058 [details]
Print preview of PDF file which previously failed.

Thanks for the update. Great to hear it works with the latest version of Ghostscript. I'm therefore closing this issue now.

Thanks for the info about the upcoming license change in Ghostscript, I hadn't heard about this yet (or at least I can't remember...).  Debian testing however does have version 9.22 in its "main" component and Debian is very strict about only free software being accepted there. They do repackage the sources, removing non-free parts (and have been doing so for very long already). I'm not sure whether that might be an option for other distributions as well...

Also Fedora ships newer Ghostscript versions (9.22 in F27, 9.23 in F28).

Ghostscript in the past had a mixed development model with commercial versions released before the FLOSS ones, then they changed a bit, and I don't remember recent changes. Do you have any reference to recent changes? Anyway, if two major distribution which checks licenses carefully are shipping a newer version, I'm sure that it's possible for others too.