You are not logged in.
Hello,
I have a problem with a pdf document which I receive regularly. It's a bill I receive from a firm. The document is displayed properly with xpdf, but
not with okular or zathura. Because the two are my pdf viewer of choice I would like to also use them to have a look at the pdf document.
If I open it with xpdf I get the following messages:
Warning: Cannot convert string "-*-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1" to type FontStruct
Warning: Cannot convert string "-*-courier-medium-r-normal--12-*-*-*-*-*-iso8859-1" to type FontStruct
Warning: Cannot convert string "-*-times-bold-i-normal--20-*-*-*-*-*-iso8859-1" to type FontStruct
Warning: Cannot convert string "-*-times-medium-r-normal--14-*-*-*-*-*-iso8859-1" to type FontStruct
But the document is displayed properly. With Okular I get:
$ okular(652)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(652)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(652)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(652)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(652)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
I think here nothing special. But there is no text in the document. With zathura:
$ Syntax Error: could not create truetype face<0a>
some font thing failed
Syntax Error: could not create truetype face<0a>
some font thing failed
Syntax Error: could not create truetype face<0a>
some font thing failed
Syntax Error: could not create truetype face<0a>
some font thing failed
Syntax Error: could not create truetype face<0a>
some font thing failed
Syntax Error: could not create truetype face<0a>
some font thing failed
Syntax Error: could not create truetype face<0a>
some font thing failed
Syntax Error: could not create truetype face<0a>
some font thing failed
Here the same as okular: no text is displayed. I assume there is something
bad with the fonts. If I have a look at the properties of the document in okular I have the following
for the fonts:
HH_10G TrueType Fully embedded
HH_12G TrueType Fully embedded
HV_10G TrueType Fully embedded
HV_10N TrueType Fully embedded
HV_8N TrueType Fully embedded
HV_9N TrueType Fully embedded
Ocrb_12N TrueType Fully embedded
I don't know what I have to search. Does somebody have an idea what can be wrong ? What do I have to search ?
If the document is needed to have a look at it, I'll try to have a copy of it. Because it's personal, I can't simply send it.
Thank you!
Offline
Can you reproduce the problem with a pdf you could share? (Does the firm provide pdf documentation which might demonstrate the same problem, for example?)
Which backend are you using with zathura? If you are currently using poppler, see if you can reproduce the problem using the mupdf backend as it might be an issue with poppler.
pdffonts and pdfinfo might provide helpful information about the pdf.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Thank you, it helped me!! I uninstalled zathura-pdf-poppler and replaced it by zathura-pdf-mupdf. The document
is correctly displayed now! But for me it's not clear what it means. Could you help me ? The problem remains with
okular. I think it's because it uses the poppler library. Some output which can be interesting:
$ pdffonts mutuel.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
HV_8N TrueType WinAnsi yes no no 5 0
HV_10G TrueType WinAnsi yes no no 8 0
HV_10N TrueType WinAnsi yes no no 11 0
HH_12G TrueType WinAnsi yes no no 13 0
HH_10G TrueType WinAnsi yes no no 16 0
HV_9N TrueType WinAnsi yes no no 18 0
Ocrb_12N TrueType WinAnsi yes no no 20 0
and
$ pdfinfo mutuel.pdf
Title: OpenPrint Document
Subject: Driver PDF
Keywords: OpenPrint Driver PDF
Author: OpenPrint
Creator: OpenPrint
Producer: Composeur Ver. VERSION 4.7.1.83
CreationDate: 03:57 27/01/2013
ModDate: 03:57 27/01/2013
Tagged: no
Form: none
Pages: 1
Encrypted: no
Page size: 700.16 x 861.73 pts
Page rot: 0
File size: 164982 bytes
Optimized: no
PDF version: 1.2
I will try to get a pdf which I can share unless the infomations I provided are enough to see the problem.
Offline
I can't really tell but somebody more knowledgeable might know. I'm wondering if this is a bug in poppler. The fact that it works fine with the other backend suggests it might be. It seems, as you say, very likely Okular has problems because it also uses poppler. There is an AUR package you might try (okular-backend-mupdf) to try to confirm this.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
I have just installed okular-backend-mupdf and the document is displayed correctly. So I will try
to contact a developper from okular to be sure it's a bug in poppler. If it's confirmed, I will
report a bug and I will also try to get a document I can share with the same problem.
Thank you for your help!
Offline
I recently sumbled upon some pretty frustrating font issues with one of my programs that uses poppler. It turns out that there are limitations in poppler-glib's use of fontconfig when rendering to xlib surfaces. I don't know exactly what these problems stem from, but they are there. If I render a pdf that has a font that needs to be replaced via font-config settings, the replacement font will not be displayed when the pdf is rendered to an xlib surface (eg a window or a pixmap) - nothing will be displayed at all for the font in question.
My solution for this, though, came from looking at zathura's code and instead of rendering directly to an xlib surface, I had poppler render the pdf to a image buffer which properly replaced the font. Then I was able to copy the image buffer to the xlib surface with cairo.
This clearly isn't the *same* issue as you are seeing symptoms with zathura too, but it does sound related. I have no idea how okular renders, except that it does use poppler (right?).
As in cfr's question, if you have a pdf that you can share that will replicate the issue, I could dig a little deeper and see under which rendering conditions it will and will not work which might better pinpoint the issue.
EDIT: Zathura gets around the direct pdf->xlib-surface issues by using a gdk-pixbuf surface as a go-between. I was able to get around the issue by using a cairo image surface as the go between. okular - being a qt program - obviously doesn't use gdk-pixbuf, and I also don't see cairo in it's dependency tree either. So if it doesn't use some other adequate rendering middle-man this might be part of the issue ... but I just don't know the q/k brand libs that well.
Last edited by Trilby (2013-09-10 22:12:51)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I have to say I don't understand everything. But for the moment I think it's not so important. I was able to edit
the pdf with pdfedit and now I can share a modified version which has the same problem. So I will send you a version
so you can have a look. And you are right, okular uses poppler.
Offline
Yes, sorry, my last post was poorly written.
I have experience with this from the program author perspective, and I was trying to translate it to user perspective, but I don't think I did very well. The short version is that going from a pdf file to something visible on the screen requires at least two distinct libraries to work together with the program. And some lines of communication between those two libraries seem to lead to problems like what you are experiencing.
EDIT: I received the test pdf and can confirm that it also doesn't display the text here, this seems distinct from what I had mentioned above as even with the 'fix' that I implemented, this still doesn't display the text. This is probably why it also fails with zathura. I'll investigate further.
Last edited by Trilby (2013-09-14 15:08:54)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I have experience with this from the program author perspective, and I was trying to translate it to user perspective, but I don't think I did very well. The short version is that going from a pdf file to something visible on the screen requires at least two distinct libraries to work together with the program. And some lines of communication between those two libraries seem to lead to problems like what you are experiencing.
Ok, now it's clearer and I understand it better. I notice that you have much more experience than I have!
I'll investigate further.
Thank you so much for the help! I'll wait if you find something and depending what you find, I can do a bug report.
If I can do something, just tell me.
Offline