You are not logged in.
Subject is a poor summary, but here are the circumstances:
Up through my October 2017 Verizon Wireless bill, Evince did a perfectly fine job of displaying the downloaded .pdf file. The November 2017 and later bills are unreadable. It looks like all the characters are fat-bitted and jammed together, something like a bad fax.
It's possible that Verizon has changed the way it formats bills. Two apparent contrasts 'twixt October and November are file size (older bills are in the 230 - 240 kB range, while newer bills run 310 - 340 kB) and color (old bills include red line work and accept text, but new ones are all black).
For comparison, the new bills show up fine in Adobe Acrobat Reader DC on Windows 7 (far from my favorite operating environment). Evince shows non-Verizon .pdf files just fine, too.
Installed versions are Arch Linux 4.14.10-1 and Evince 3.26.0+14+g2a499547-1.
I will post screenshots that illustrate the problem if I can figure out how. Would prefer not to share full Verizon .pdf files unless absolutely necessary.
Any guidance the community can provide, including redirection to a more appropriate forum or site, would be appreciated. Thanks.
Last edited by caj2arch (2018-01-23 15:50:26)
Offline
Tried a couple of the Troubleshooting suggestions on https://wiki.archlinux.org/index.php/GN … ent_viewer :
* pacman -Q reports that I'm at gtk3 3.22.26+47+g3a1a7135a2-3
* $ gsettings set org.gnome.Evince override-restrictions false makes no difference
Offline
Please post the ouputs of "pdfinfo", "pdffonts" "pdffonts -subst" on a good and a bad file.
Cross check the rendering with xpdf and mupdf/llpp (either will do; llpp is only available on AUR and mupdf on OpenGL)
You can upload screenshots to imgur or so; please only paste thumbnails or links on this board.
Offline
I've also been having trouble with viewing PDFs in poppler or mupdf based PDF systems in the past day. My only guess is that this has something to do with recent changes to freetype2.
It seems to be a problem with certain fonts. One of them is the version of TeX Gyre Pagella that the LaTeX newpxtext package uses.
I've created a sample document here: test.pdf
Here's how this document is supposed to look, and more or less how it does still look when loaded with pdf.js in firefox, or with adobe reader:
However, since a recent update, on Arch, on mupdf, it now looks like:
It looks similarly garbled in okular. Evince completely fails to show it, and barfs when you try to load the PDF.
I think this has something to do with freetype2, since (1) that's the only relevant thing I can find that's updated in the past couple days (mupdf hasn't), (2) both evince and mupdf send freetype2 warnings or errors when launched from the command line when opening this pdf.
For the record, this PDF was created by first running pdflatex on this source:
\documentclass{article}
\usepackage{newpxtext}
\pagestyle{empty}
\begin{document}
abcdefghijklmnopqrstuvwxyz 0123456789
ABCDEFGHIJKLMNOPQRSTUVWXYZ 01234567890
\end{document}
And then using pdfcrop to crop it (though the behavior is the same pre-crop.)
pdfinfo test.pdf:
Creator: TeX
Producer: pdfTeX-1.40.18
CreationDate: Fri Jan 12 14:50:36 2018 EST
ModDate: Fri Jan 12 14:50:36 2018 EST
Tagged: no
UserProperties: no
Suspects: no
Form: none
JavaScript: no
Pages: 1
Encrypted: no
Page size: 237 x 22 pts
Page rot: 0
File size: 30128 bytes
Optimized: no
PDF version: 1.5
pdffonts test.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
JURAPZ+TeXGyrePagellaX-Regular Type 1 Custom yes yes no 8 0
Last edited by frabjous (2018-01-12 20:12:42)
Offline
frabjous, your problem seems to be an error in freetype2 2.9, but it is already fixed with the current git version. It is probably this change:
https://git.savannah.gnu.org/cgit/freet … 9ab740231a
$ # with freetype2 2.9-1
$ pdftocairo -png /tmp/test.pdf
Internal Error: cairo context error: error occurred in libfreetype<0a>
cairo error: error occurred in libfreetype
cairo error: error occurred in libfreetype
$
$ # with heftig/freetype2-git 1:2.9+p3+g707cd028b-1
$ # available in AUR or https://bbs.archlinux.org/viewtopic.php?id=117157
$ pdftocairo -png /tmp/test.pdf
$
Last edited by progandy (2018-01-13 02:51:04)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Thanks for picking up the gauntlet, seth. For ease of identification, I have renamed the Verizon bill files Good.pdf and Bad.pdf.
Here are the poppler outputs for the good file:
$ pdfinfo Good.pdf
Title:
Subject:
Keywords:
Author:
Creator:
Producer: Actuate Content Services Document Transform - 5.0.21
CreationDate: Fri Oct 13 12:36:14 2017 EDT
ModDate: Fri Oct 13 12:36:14 2017 EDT
Tagged: no
UserProperties: no
Suspects: no
Form: none
JavaScript: no
Pages: 10
Encrypted: no
Page size: 594 x 792 pts
Page rot: 0
File size: 234672 bytes
Optimized: no
PDF version: 1.4
$ pdffonts Good.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
[none] Type 3 Custom yes no yes 18 0
[none] Type 3 Custom yes no yes 17 0
[none] Type 3 Custom yes no yes 16 0
FABADA+Helvetica 57 Condensed Oblique TrueType WinAnsi yes yes no 15 0
[none] Type 3 Custom yes no yes 14 0
[none] Type 3 Custom yes no yes 13 0
DBAAFC+Helvetica 77 Bold Condensed TrueType WinAnsi yes yes no 12 0
ADAFCD+Helvetica 57 Condensed TrueType WinAnsi yes yes no 11 0
[none] Type 3 Custom yes no yes 10 0
[none] Type 3 Custom yes no yes 9 0
[none] Type 3 Custom yes no yes 8 0
Helvetica-Bold Type 1 WinAnsi no no no 24 0
Helvetica Type 1 WinAnsi no no no 23 0
[none] Type 3 Custom yes no yes 44 0
[none] Type 3 Custom yes no yes 43 0
[none] Type 3 Custom yes no yes 42 0
Times-Roman Type 1 WinAnsi no no no 41 0
$ pdffonts -subst Good.pdf
name object ID substitute font substitute font file
------------------------------------ --------- ------------------------------------ ------------------------------------
Helvetica-Bold 24 0 NimbusSans-Bold /usr/share/fonts/gsfonts/NimbusSans-Bold.otf
Helvetica 23 0 NimbusSans-Regular /usr/share/fonts/gsfonts/NimbusSans-Regular.otf
Times-Roman 41 0 NimbusRoman-Regular /usr/share/fonts/gsfonts/NimbusRoman-Regular.otf
And for the bad one:
$ pdfinfo Bad.pdf
Author: "AFP2PDF.verizon.com"
Creator: Ricoh Americas Corporation, AFP2PDF Plus Version: 1.016.6
Producer: Ricoh Americas Corporation, AFP2PDF
CreationDate: Fri Nov 17 13:57:07 2017 EST
ModDate: Fri Nov 17 13:57:07 2017 EST
Tagged: no
UserProperties: no
Suspects: no
Form: none
JavaScript: no
Pages: 11
Encrypted: no
Page size: 594 x 792 pts
Page rot: 0
File size: 317080 bytes
Optimized: no
PDF version: 1.4
$ pdffonts Good.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
[none] Type 3 Custom yes no yes 18 0
[none] Type 3 Custom yes no yes 17 0
[none] Type 3 Custom yes no yes 16 0
FABADA+Helvetica 57 Condensed Oblique TrueType WinAnsi yes yes no 15 0
[none] Type 3 Custom yes no yes 14 0
[none] Type 3 Custom yes no yes 13 0
DBAAFC+Helvetica 77 Bold Condensed TrueType WinAnsi yes yes no 12 0
ADAFCD+Helvetica 57 Condensed TrueType WinAnsi yes yes no 11 0
[none] Type 3 Custom yes no yes 10 0
[none] Type 3 Custom yes no yes 9 0
[none] Type 3 Custom yes no yes 8 0
Helvetica-Bold Type 1 WinAnsi no no no 24 0
Helvetica Type 1 WinAnsi no no no 23 0
[none] Type 3 Custom yes no yes 44 0
[none] Type 3 Custom yes no yes 43 0
[none] Type 3 Custom yes no yes 42 0
Times-Roman Type 1 WinAnsi no no no 41 0
$ pdffonts -subst Good.pdf
name object ID substitute font substitute font file
------------------------------------ --------- ------------------------------------ ------------------------------------
Helvetica-Bold 24 0 NimbusSans-Bold /usr/share/fonts/gsfonts/NimbusSans-Bold.otf
Helvetica 23 0 NimbusSans-Regular /usr/share/fonts/gsfonts/NimbusSans-Regular.otf
Times-Roman 41 0 NimbusRoman-Regular /usr/share/fonts/gsfonts/NimbusRoman-Regular.otf
From the output of pdfinfo it is clear that Verizon changed their .pdf generation process between the two billing cycles.
I installed both xpdf and llpp. For Good.pdf, llpp renders the file slightly better than xpdf and roughly equal in quality to evince; all three are excellent quality. For Bad.pdf, llpp is quite a bit better than xpdf and both are vastly superior to evince. I realize these are far from quantitative assessments. Sorry about that.
Attempting to keep the zoom factor the same, I loaded screenshots from Good.pdf and Bad.pdf on imgur.com as follows:
* evince: https://imgur.com/a/qJ89s
* llpp: https://imgur.com/gallery/ofX5k
* xpdf: https://imgur.com/gallery/8JsfA
I've not used imgur before, so my success at loading images is suspect. If they are somehow garbled, it may be easier if I just email the six .png files to you; total size is less than 600kB.
I think fonts are a likely culprit here. Is there a good way to determine which fonts I actually have installed?
Again, thanks for looking into this situation.
Offline
You seem to have given us the pdffonts output for good.pdf instead od Bad.pdf.
I think fonts are a likely culprit here. Is there a good way to determine which fonts I actually have installed?
pdffonts -subst should show you which fonts will be used from your local fonts. Embedded fonts (emb = yes in pdffonts) are part of the PDF and your local files are not relevant.
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Rats. The perils of cursor-up. Here's the full set for Bad.pdf, tough pdffonts is curiously quiet:
$ pdfinfo Bad.pdf
Author: "AFP2PDF.verizon.com"
Creator: Ricoh Americas Corporation, AFP2PDF Plus Version: 1.016.6
Producer: Ricoh Americas Corporation, AFP2PDF
CreationDate: Fri Nov 17 13:57:07 2017 EST
ModDate: Fri Nov 17 13:57:07 2017 EST
Tagged: no
UserProperties: no
Suspects: no
Form: none
JavaScript: no
Pages: 11
Encrypted: no
Page size: 594 x 792 pts
Page rot: 0
File size: 317080 bytes
Optimized: no
PDF version: 1.4
$ pdffonts Bad.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
[none] Type 3 Custom yes no yes 2 0
[none] Type 3 Custom yes no yes 3 0
[none] Type 3 Custom yes no yes 4 0
[none] Type 3 Custom yes no yes 5 0
[none] Type 3 Custom yes no yes 6 0
[none] Type 3 Custom yes no yes 7 0
[none] Type 3 Custom yes no yes 8 0
[none] Type 3 Custom yes no yes 9 0
[none] Type 3 Custom yes no yes 10 0
[none] Type 3 Custom yes no yes 11 0
[none] Type 3 Custom yes no yes 12 0
[none] Type 3 Custom yes no yes 13 0
[none] Type 3 Custom yes no yes 15 0
[none] Type 3 Custom yes no yes 16 0
[none] Type 3 Custom yes no yes 21 0
[none] Type 3 Custom yes no yes 22 0
[none] Type 3 Custom yes no yes 23 0
[none] Type 3 Custom yes no yes 26 0
[none] Type 3 Custom yes no yes 27 0
[none] Type 3 Custom yes no yes 30 0
[none] Type 3 Custom yes no yes 33 0
[none] Type 3 Custom yes no yes 34 0
[none] Type 3 Custom yes no yes 47 0
[none] Type 3 Custom yes no yes 48 0
[none] Type 3 Custom yes no yes 49 0
[none] Type 3 Custom yes no yes 50 0
$ pdffonts -subst Bad.pdf
name object ID substitute font substitute font file
------------------------------------ --------- ------------------------------------ ------------------------------------
Offline
Seems like a cairo ./. type-3 (ancient format, no hinting support) rendering issue - no font from your system is used or required. The fonts could also be bitmaps and cairo is trying some DPI-aware scaling.
Try converting it with pdftocairo and check whether the antialias switch (manpage for valid strings) makes a difference.
Offline
This might be the same issue: https://bugs.freedesktop.org/show_bug.cgi?id=103690
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
"pdftocairo -png test.pdf" produces the same problems here while llpp reders it "ok" - and so does pdftoppm, so it's more a cairo than a poppler issue.
Offline
"pdftocairo -png test.pdf" produces the same problems here while llpp reders it "ok" - and so does pdftoppm, so it's more a cairo than a poppler issue.
It is either cairo or the cairo backend of poppler.
You can build yourself a working pdf like this:
pdftops -origpagesizes IN.pdf - | ps2pdf - OUT.pdf
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
The character rendering in the evince output from the test file at https://bugs.freedesktop.org/show_bug.cgi?id=103690 looks very much like that of my Bad.pdf file. The test.pdf file from frabjous above doesn't successfully open in my installation of evince.
progandy's pdftops|ps2pdf conversion does indeed produce a result from Bad.pdf that is very well rendered in evince. Also, it's only about 5% larger, so not much efficiency loss.
I can easily convert the Verizon files after I download them. Does it make sense to pursue this issue or mark is [closed]?
For the record, pacman -Q shows the following poppler package versions for me:
poppler 0.61.1-1
poppler-data 0.4.8-1
poppler-glib 0.61.1-1
poppler-qt5 0.61.1-1
Thanks for everybody's analysis.
Offline
frabjous, your problem seems to be an error in freetype2 2.9, but it is already fixed with the current git version. It is probably this change:
https://git.savannah.gnu.org/cgit/freet … 9ab740231a
Thanks a lot. Yes, I installed freetype2-git from the heftig repo and everything works now; I'll use that until Arch's freetype2 gets updated.
Offline
Thank you for this post. Had a similar Problem with the Font TeXGyrenPagellaX-Regular which comes with the package:
\usepackage{newpxtext,newpxmath}
Replacing freetype2 with freetype2-git solved the Problem. I just write this, because google hasn't (yet) found this solution. Thanks a lot
Offline