You are not logged in.

#1 2018-01-11 17:55:44

caj2arch
Member
Registered: 2014-03-31
Posts: 28

[SOLVED] Evince Document Viewer Renders .pdf Badly

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

#2 2018-01-11 19:47:41

caj2arch
Member
Registered: 2014-03-31
Posts: 28

Re: [SOLVED] Evince Document Viewer Renders .pdf Badly

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

#3 2018-01-11 21:05:51

seth
Member
Registered: 2012-09-03
Posts: 8,950

Re: [SOLVED] Evince Document Viewer Renders .pdf Badly

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.

Online

#4 2018-01-12 20:11:08

frabjous
Member
Registered: 2010-07-13
Posts: 326

Re: [SOLVED] Evince Document Viewer Renders .pdf Badly

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:

correct

However, since a recent update, on Arch, on mupdf, it now looks like:

incorrect

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

#5 2018-01-12 20:29:57

progandy
Member
Registered: 2012-05-17
Posts: 3,195

Re: [SOLVED] Evince Document Viewer Renders .pdf Badly

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

#6 2018-01-13 02:30:56

caj2arch
Member
Registered: 2014-03-31
Posts: 28

Re: [SOLVED] Evince Document Viewer Renders .pdf Badly

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

#7 2018-01-13 02:56:41

progandy
Member
Registered: 2012-05-17
Posts: 3,195

Re: [SOLVED] Evince Document Viewer Renders .pdf Badly

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

#8 2018-01-13 15:45:18

caj2arch
Member
Registered: 2014-03-31
Posts: 28

Re: [SOLVED] Evince Document Viewer Renders .pdf Badly

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

#9 2018-01-13 18:40:05

seth
Member
Registered: 2012-09-03
Posts: 8,950

Re: [SOLVED] Evince Document Viewer Renders .pdf Badly

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.

Online

#10 2018-01-13 18:52:08

progandy
Member
Registered: 2012-05-17
Posts: 3,195

Re: [SOLVED] Evince Document Viewer Renders .pdf Badly


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#11 2018-01-13 19:15:40

seth
Member
Registered: 2012-09-03
Posts: 8,950

Re: [SOLVED] Evince Document Viewer Renders .pdf Badly

"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.

Online

#12 2018-01-13 19:33:15

progandy
Member
Registered: 2012-05-17
Posts: 3,195

Re: [SOLVED] Evince Document Viewer Renders .pdf Badly

seth wrote:

"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

#13 2018-01-14 17:14:39

caj2arch
Member
Registered: 2014-03-31
Posts: 28

Re: [SOLVED] Evince Document Viewer Renders .pdf Badly

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

#14 2018-01-15 17:41:39

frabjous
Member
Registered: 2010-07-13
Posts: 326

Re: [SOLVED] Evince Document Viewer Renders .pdf Badly

progandy wrote:

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

#15 2018-01-30 11:51:03

marove
Member
Registered: 2015-12-17
Posts: 9

Re: [SOLVED] Evince Document Viewer Renders .pdf Badly

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 smile

Offline

Board footer

Powered by FluxBB