Bug 317407 - can't print pdf, when unknown font (windings) is used
Summary: can't print pdf, when unknown font (windings) is used
Status: RESOLVED UPSTREAM
Alias: None
Product: okular
Classification: Applications
Component: printing (show other bugs)
Version: 0.16.1
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-26 20:53 UTC by suse
Modified: 2014-07-21 23:02 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
test case with windings font (not embedded) (9.83 KB, application/pdf)
2013-03-26 20:55 UTC, suse
Details
valgrind output, but there was no error message by okular (38.17 KB, text/plain)
2013-04-08 21:36 UTC, suse
Details

Note You need to log in before you can comment on or make changes to this bug.
Description suse 2013-03-26 20:53:24 UTC
I have an pdf where the font windings is used, but not embedded (see the list bullets of attached example).
Trying to print this file on my real printer (PCL 6 / LAN-printer) ends up in a hanged/freezed printer.
Furthermore on one of the test machine I'm getting the error message: "Could not print the document. Detailed error is "Printing process crashed". Please report to bugs.kde.org" when I try to print it to a pdf file.

Installing the windings font from a windows installation is a workaround. Now it prints on my real printer.

Reproducible: Always

Actual Results:  
PCT printer freezes

Expected Results:  
It should be possible to print such files even when the font is missing and therefore there a some broken symbols.

The attached example is also using arial and symbol, but have no influence on my freezed-printer-issue.
Comment 1 suse 2013-03-26 20:55:18 UTC
Created attachment 78412 [details]
test case with windings font (not embedded)
Comment 2 Albert Astals Cid 2013-04-07 16:58:20 UTC
Can't reproduce the problem, it prints fine here (with the wrong wingdings, but that's a different story) and can also print without issues to pdf file

Not sure how to debug the first issue, but for the second this may help, please do
valgrind --trace-children=yes myfile.pdf
and then try to print to pdf file and attach the output of the valgrind command. Note it'll run slower
Comment 3 suse 2013-04-08 21:35:41 UTC
I did a fresh installation (without any updates) of openSUSE 12.3 64-bit (in VirtualBox) which ships KDE SC 10.0.  (host 64-bit, opensuse 12.2, upgraded kde 4.10.2)
Opened the pdf with okular and print to pdf 18 times:
- 2 times it was printed (=pdf created)
- 9 times error message and the created pdf was empty
- 7 times error message and no file has been created

Then I installed valgrind. execute
valgrind --trace-children=yes okular 3_pdfsam_allianz.pdf
and print to pdf 5 times.
- 5 times it was printed (=pdf created) and no error message

Well, same procedure on my second computer, laptop. (32-bit, opensuse 12.2, upgraded kde 4.10.2)
Installed also openSUSE 12.3 64-bit (in VirtualBox) repeated the test:
- print to pdf works always without any error message.

I'll attach the logs from valgrind anyway, but it's just weird. It looks like it depends on the host.
And this makes it hard/impossible for other to reproduce the issue. And more worse, with running debug tools, the issue disappears :-(((

I don't mind to stop here and focus on the first issue.
I installed inside the fresh opensuse installation on my laptop (where print to pdf works) my PCL printer and tried print the document. printer freezes. :-(

Well, if you have a PCL printer and it works, then it's maybe my printers fault. (konica minolta mc2550).

Any further tips or other test persons?
Comment 4 suse 2013-04-08 21:36:47 UTC
Created attachment 78741 [details]
valgrind output, but there was no error message by okular
Comment 5 suse 2013-04-09 14:35:27 UTC
Note to myself:
Workaround for issue 1 (freezed printer):
first print to pdf, then print that pdf on the real printer.

The reason why this works could be, because the new pdf doesn't contain the unknown windings font but the replaced font. (e.g. Helvetica)
Comment 6 Albert Astals Cid 2013-04-10 22:30:19 UTC
First issue: I'd say it's your printer fault
Second issue: It seems that the process we call to print is crashing, most probably not our fault, but can't confirm since the valgrind trace reports nothing

To be honest not sure there's much we can do to help here.
Comment 7 Albert Astals Cid 2014-05-10 15:12:38 UTC
Have you tried this with a newer version of Okular? Do you still have this problem?
Comment 8 suse 2014-05-11 07:25:38 UTC
Issue still exists with okular 0.18.5 (KDE 4.12.5)  (with Fedora 20)
Comment 9 Albert Astals Cid 2014-05-11 14:33:15 UTC
Just to confirm, you still get

Could not print the document. Detailed error is "Printing process crashed"

Right?
Comment 10 suse 2014-05-11 17:44:44 UTC
Yes, I still can't print the document.
And the printer itself crashes. That means I could not print any pages from any PCs in the network (incl. windows 7) anymore until I switch the printer off and on. (just to repeat your comment#6 :-)

the second issue disappeared. (=printing to pdf crashs with error message)
tested now on opensuse 13.1 64-bit host:
1. virtualbox: opensuse 13.1 64-bit, KDE 4.11.5, okular 0.17.5 => OK
2. virtualbox: opensuse 12.3 32-bit, KDE 4.12.4, okular 0.18.4 => OK
3. virtualbox: opensuse 12.3 64-bit, KDE 4.10.0, okular 0.16.0 => OK

=> I could not reproduce my error case as described in comment#3 anymore. It looks like upgrading the from openSUSE 12.2 to 13.1 solves that issue.

Summary: 
the remaining issue is the printer freeze, which is the printers fault, but could be workaround by KDE (okular) (see comment #5)
Comment 11 Albert Astals Cid 2014-05-15 20:08:16 UTC
Please do this in a command shell:
 * pdftops myfile.pdf
// This will generate myfile.ps
 * lpr myfile.ps

What happens?
Comment 12 suse 2014-05-15 21:57:17 UTC
pdftops and lpr are working. Printer prints.
Comment 13 Albert Astals Cid 2014-05-20 21:15:17 UTC
Are saying that pdftops+lpr work but Okular doesn't?
Comment 14 suse 2014-05-21 07:09:42 UTC
yes, exactly.
Just re-tested it again with KDE 13.1; Okular 0.19.1
Comment 15 Albert Astals Cid 2014-05-24 11:20:02 UTC
This is very confusing since pdftops+lpr is exactly what Okular uses to print

Can you enable all okular debug in kdebugdialog, print something, there will be a line about the exact lpr call we use, and then do the same pdftops + lpr call but passing all the parameters we pass to lpr?
Comment 16 suse 2014-05-30 20:25:04 UTC
this is the debug output of okular when printing the pdf file:

dom@linux-q8mt:~> okular 3_pdfsam_allianz.pdf
Fontconfig warning: "/etc/fonts/conf.d/56-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated.
okular(3971)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from "/var/tmp/kdecache-dom/ksycoca4"
okular(3971)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(3971)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(3971)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(3971)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(3971)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(3971)/kparts KParts::ReadWritePart::setModified: setModified( false )
okular(3971)/kparts KParts::ReadWritePart::setModified: setModified( false )
okular(3971)/kdecore (trader) KMimeTypeTrader::query: query for mimeType  "application/pdf" ,  "okular/Generator"  : returning  1  offers
okular(3971)/okular (app) Okular::Document::requestPixmaps: request observer=0x93db864 656x937@0
okular(3971)/okular (app) Okular::DocumentPrivate::sendGeneratorPixmapRequest: sending request observer=0x93db864 656x937@0 async == true isTile == false
okular(3971)/okular (app) Okular::Document::requestPixmaps: request observer=0x93db864 656x937@0
okular(3971)/okular (app) Okular::Document::requestPixmaps: request observer=0x9388ed4 82x117@0
okular(3971)/okular (app) Okular::Document::requestPixmaps: request observer=0x93db864 639x913@0
okular(3971)/okular (app) Okular::Document::requestPixmaps: request observer=0x93db864 639x913@0
okular(3971)/okular (app) Okular::Document::requestPixmaps: request observer=0x93db864 639x913@0
okular(3971)/okular (app) Okular::DocumentPrivate::sendGeneratorPixmapRequest: sending request observer=0x93db864 639x913@0 async == true isTile == false
okular(3971)/okular (app) Okular::DocumentPrivate::sendGeneratorPixmapRequest: sending request observer=0x9388ed4 82x117@0 async == true isTile == false
okular(3971)/okular (app) Okular::FilePrinter::doPrintFiles: Executing "lpr" with arguments ("-P", "mc2550", "-#1", "-J", "3_pdfsam_allianz.pdf", "-o", "media=A4", "-o", "portrait", "-o", "sides=one-sided", "-o", "outputorder=normal", "-o", "Collate=True", "-o", "page-left=10", "-o", "page-top=10", "-o", "page-right=10", "-o", "page-bottom=10", "-o", "fit-to-page", "-r", "/tmp/kde-dom/okulareD3971.ps")


and here the command to print the *converted* pdf file:
lpr 3_pdfsam_allianz.ps -P mc2550 -#1 -J 3_pdfsam_allianz.pdf -o media=A4 -o portrait -o sides=one-sided  -o outputorder=normal -o Collate=True -o page-left=10 -o page-top=10 -o page-right=10  -o page-bottom=10 -o fit-to-page

Sadly, this works. :-(     Weird.
Do you know how I can preserve the temporary file /tmp/kde-dom/okulareD3971.ps which okular creates? Maybe something is wrong with this file. (if okular does only a pure pdftops which means that this temporary ps file is totally equal to my manually created ps file, then we can give up... )
Comment 17 Albert Astals Cid 2014-06-17 22:39:39 UTC
You'd need to either be very fast copying the file or modify okular sources and recompile it.

Do you feel confortable recompiling okular?
Comment 18 suse 2014-06-24 21:05:10 UTC
Challenge accepted. :-)
I will have enough spare time mid of July. Not earlier.
Then I can try to recompile okular. I have some experience with compiling from source, but I'm not very skilled yet. Sometimes I succeed, sometimes not. It depends mostly, how detailed the INSTALL file is...

I will add a new comment, when I'm ready.
Comment 19 suse 2014-07-21 22:50:27 UTC
OK, I finally managed to compile okular from git source.
(with thanks to https://techbase.kde.org/Development/Tutorials/Building_An_Existing_Application)

After removing the "-r" option from the lrp command, I was able to get the temporary .ps file.
At this point I realized my huge mistake:
At comment#11 you request me to use pdftops. But I've executed pdf2ps. :-(
(I checked the .bash_history logs!)

These are to separate programs, different file sizes, different behaviours.
- pdf2ps works for me.
- pdftops doesn't work for me.

According to
http://stefaanlippens.net/pdf2ps_vs_pdftops
this makes sense for me. pdf2ps converts fonts to bitmap fonts which can be handled by my printer. pdftops keeps the fonts and my printer crashes.

However, I know that pdf2ps is not a valid option for the majority of the okular users.

looks like a sad end for me. (although I've learned much about building KDE applications. :-)
Comment 20 Albert Astals Cid 2014-07-21 23:02:03 UTC
So now that we've found out that pdftops does not create a ps file that your printer understands, please go to poppler's bugzilla https://bugs.freedesktop.org and report a bug there, even though i'm thinking more and more than your printer is at fault.

To temporary fix up this problem you can always force rasterization in print -> options -> pdf options