Created attachment 32973 [details] incorectly rendered file As told in that thread, attached pdf, produced from following source: \documentclass{prosper} % %% Packages declaration \usepackage{HA-prosper} % %% Begin document \begin{document} % %% Outline % %% Slide 1 \begin{slide}{Slide 1} \begin{itemize} \item {One} \item {Two} \item {Three} \end{itemize} \end{slide} % \end{document} by a chain of 'latex;dvips;ps2pdf' renders incorrectly: 's' in place of '<square>' for list items. Interesting part is that pdftotext creates incorrect output (with 's'), pdftops produces a correctly displayed ps file, so not only is the content correct, but poppler tools handle the file inconsistently. Both evince and okular render it incorrectly, so probably not a frontend issue.
Works for me, which poppler version do you use? Do you have poppler-data installed?
My mistake - should have mentioned that from the start. It's 0.12.3.
Can you answer the second question? And while you are at it, attach a screenshot
Created attachment 32977 [details] just the missing bullets I do have poppler-data 0.4.0 installed, but most of it are CIDMaps, that shouldn't really affect anything. Unless you think it unicodeMap files.
Open the file with okular and paste the contents of File->Properties->Fonts
I don't have okular. But in evince, it's Helvetica, ZapfDingbats, Helvetica-Bold (all Type1). pdffonts gives: name type emb sub uni object ID ------------------------------------ ----------------- --- --- --- --------- Helvetica Type 1 no no no 13 0 ZapfDingbats Type 1 no no no 15 0 Helvetica-Bold Type 1 no no no 14 0 but that probably you can see yourself.
That doesn't help at all, i want okular because it says which *real* font it is using for non embedded fonts and i suspect you don't have the *correct* substitution for ZapfDingbats
I've got only a handful of qt apps and no KDE (no need for it too). I was not the original reporter and I doubt my font configuration matches his. I do have corefonfs, if that's what you're asking. Any other way to get that info ? As pdftotext fails too, there has to be one.
I may ask the original reporter, but that will take some time. Contact only through that forum thread.
I could code a new program for you, but that wuold be quite useless as i have already coded one that does it, if you refuse to use it, it's your problem, not mine. As pdftotext "failing", this is a completely different issue and i would even argue it's a failure.
> Any other way to get that info ? Yes. Use lsof(8) to see what files evince has open. To get definitive data, have only one evince window open. Open the pdf in evince, use 'ps xw|grep evince' to get the PID of the evince process (you may also be able to use »pidof evince« if you have pidof installed) and then use lsof: :; lsof -p $(pidof evince) | grep -v /fontconfig/ | grep font that should show all of the files evince has open which have the string font in their pathnames, excluding the fontconfig cache files.
Well, that user reported: /usr/share/fonts/urw-fonts/n019003l.pfb /usr/share/fonts/urw-fonts/n019004l.pfb /usr/share/fonts/mathematica-fonts/Vera.ttf For me, it's: evince 3007 voidspawn mem REG 259,786432 65932 474904 /usr/share/fonts/ttf-bitstream-vera/Vera.ttf evince 3007 voidspawn mem REG 259,786432 72400 401000 /usr/share/fonts/default/ghostscript/n019004l.pfb evince 3007 voidspawn mem REG 259,786432 68590 400996 /usr/share/fonts/default/ghostscript/n019003l.pfb evince 3007 voidspawn mem REG 259,786432 523804 318230 /usr/share/fonts/dejavu/DejaVuSans-Oblique.ttf evince 3007 voidspawn mem REG 259,786432 622280 318257 /usr/share/fonts/dejavu/DejaVuSans.ttf And I'd argue about it being unrelated: pdftotext output has that 's', pdftops output is correct. And while okular may not be that big, kdelibs are a completely different matter.
You can argue all you want, unless you know how PDF works your opinion is not really worth much. I'm closing this bug because the rendering is wrong because your system doesn't know it should use d050000l.pfb for rendering ZapfDingbats font. Configure your fontconfig properly and it should work like a charm. If you need help in doing that http://freedesktop.org/wiki/Software/poppler might help you (not sure that fontconfig rules are uptodate) If you think pdftotext giving a "s" is a bug please open a separate bug.
1. the config was one shipped with fontconfig: <alias binding="same"> <family>Zapf Dingbats</family> <accept><family>Dingbats</family></accept> </alias> <match target="pattern"> <test name="family"> <string>Symbol</string> </test> <edit name="family" mode="append" binding="same"> <string>Standard Symbols L</string> </edit> </match> when changed to 'prepend' form from poppler's page, pdf is indeed displayed correctly. 2. 's' is still there - is that not a bug ? Just making sure it's not a substitution char or such.
You are getting an 's' because it is an 's', just that the ZapfDingbats font draws a Square when asked for an 's' What you want pdftotext to do?
(In reply to comment #15) > You are getting an 's' because it is an 's', just that the ZapfDingbats font > draws a Square when asked for an 's' > > What you want pdftotext to do? > You could have started with that bit - postscript in that file is bit to complicated to simply read it, so I thought it was either a postscript graphic or something of the higher unicode range. If that's simply different *font* encoding, then you're probably right - pdftotext can't really do that much guessing.
Just a minor note: dvi2tty puts 'n' instead of 's' for the dvi file, from 'latexdvips;ps2pdf' chain, so it does seem that there's no good *and* simple solution here.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.