Bug 428677 - evince output renders poorly side-by-side to xpdf
Summary: evince output renders poorly side-by-side to xpdf
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: poppler   
(Show other bugs)
Version: rawhide
Hardware: All Linux
low
medium
Target Milestone: ---
Assignee: Marek Kašík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Triaged
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-01-14 15:30 UTC by R P Herrold
Modified: 2013-01-10 04:32 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-13 09:42:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test file to compare with (992.99 KB, application/pdf)
2008-01-14 15:30 UTC, R P Herrold
no flags Details
bad looking evince compared to xpdf screenshot (106.69 KB, image/jpeg)
2008-01-14 15:31 UTC, R P Herrold
no flags Details
screenshot at 400% in evince of the reviewd test file: (59.48 KB, image/jpeg)
2008-03-08 19:23 UTC, R P Herrold
no flags Details
revised test PDF file built in LaTeX without \usepackage[T1]{fontenc} (849.82 KB, application/pdf)
2008-03-08 19:25 UTC, R P Herrold
no flags Details

Description R P Herrold 2008-01-14 15:30:04 UTC
Description of problem:

evince output is markedly less readible than that from xpdf on the same input
file, and at the same resulution

Version-Release number of selected component (if applicable):

ongoing problem -- it has always looked 'cheesies' and 'not ready for prime time'

How reproducible:

1. retrieve test file:  http://www.herrold.com/commands.pdf
2. open the file with evince; set to 125%; expand the display panel width so
that the full width displays.
3. open file with xpdf; set to 125%
4. compare rendition

Steps to Reproduce:
1.  as above
  
Actual results:

evince just looks bad -- check the left stroke on 'P' compared to the 'R' to ies
left, and lower case 'e' s throughout

Expected results:

at least as good a render.  if not, evince needs to be declared less acceptible
than xpdf and replace by xpdf if not fixed by a specified future Fedora release date

Additional info:

the test file is attached.

Comment 1 R P Herrold 2008-01-14 15:30:04 UTC
Created attachment 291594 [details]
test file to compare with

Comment 2 R P Herrold 2008-01-14 15:30:47 UTC
and here is the comparison screenshot

Comment 3 R P Herrold 2008-01-14 15:31:38 UTC
Created attachment 291595 [details]
bad looking evince compared to xpdf screenshot

Comment 4 R P Herrold 2008-03-08 19:21:43 UTC
Commenting out in the underlting TeX

\usepackage[T1]{fontenc}

in the sources and rebuilding also helps, but of course this only applies to
sources under the control of the viewer (a very rare case).. I will upload a
revised screenshot at 400% in a moment of the rebuilt PDF sample in a moment

Comment 5 R P Herrold 2008-03-08 19:23:05 UTC
Created attachment 297316 [details]
screenshot at 400% in evince of the reviewd test file:

Comment 6 R P Herrold 2008-03-08 19:25:34 UTC
Created attachment 297317 [details]
revised test PDF file built in LaTeX without \usepackage[T1]{fontenc}

Comment 7 R P Herrold 2008-04-08 18:04:39 UTC
Is any further information needed to advance this bug?  I see it is still in NEW
status?

Comment 8 Bug Zapper 2008-05-14 04:46:30 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 9 R P Herrold 2008-07-28 21:41:14 UTC
three more months and still untouched -- what is needed?

Comment 10 R P Herrold 2008-10-14 07:06:56 UTC
Any way to get a reply on this?

Comment 11 John Poelstra 2008-10-15 21:24:05 UTC
This bug has been triaged

Comment 12 Bug Zapper 2008-11-26 02:04:58 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 13 R P Herrold 2008-11-26 14:08:58 UTC
I have tracked updated evince .. this poor display compared to xpdf remains an issue in Raw Hide with the current release and test case; moving back to raw hide

[herrold@centos-5 ~]$ srcfind -r evince
evince   /mnt/nfs/var/ftp/pub/mirror/redhat/rawhide/SRPMS/evince-2.24.1-3.fc10.src.rpm
[herrold@centos-5 ~]$

Comment 14 R P Herrold 2008-11-26 14:11:58 UTC
the needinfo flag did not clear -- clearing

Comment 15 Theodore Tso 2009-02-18 21:51:23 UTC
Looks like the version of evince shipped with Fedora isn't capable of handling anti-aliased fonts (or at least as encoded in the pdf found in this bug report).    

Using evince 2.24.1-0ubuntu1 from Ubuntu Jaunty, the pdf looks fine, without the jaggies seen in screenshot attached to this bug.  So this looks like a difference in how evince is getting compiled or what libraries are available in its compilation environment.  But it *is* possible for evince to DTRT with this pdf file.  Ubuntu's evince handles it just fine....

BTW:
% ldd /usr/bin/evince
	linux-gate.so.1 =>  (0xffffe000)
	libSM.so.6 => /usr/lib/libSM.so.6 (0xb80b9000)
	libICE.so.6 => /usr/lib/libICE.so.6 (0xb80a1000)
	libevbackend.so.0 => /usr/lib/libevbackend.so.0 (0xb808c000)
	liblaunchpad-integration.so.1 => /usr/lib/liblaunchpad-integration.so.1 (0xb8087000)
	libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb8081000)
	librt.so.1 => /lib/librt.so.1 (0xb8078000)
	libglade-2.0.so.0 => /usr/lib/libglade-2.0.so.0 (0xb8061000)
	libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7cc3000)
	libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb7b86000)
	libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb7b6a000)
	libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb7b42000)
	libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0xb7b10000)
	libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0xb7af3000)
	libdbus-1.so.3 => /lib/libdbus-1.so.3 (0xb7aba000)
	libgnome-keyring.so.0 => /usr/lib/libgnome-keyring.so.0 (0xb7aa9000)
	libpoppler-glib.so.3 => /usr/lib/libpoppler-glib.so.3 (0xb7a82000)
	libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb79f6000)
	libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb79dc000)
	libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb79d1000)
	libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0xb7968000)
	libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7925000)
	libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb78b2000)
	libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb7870000)
	libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb77fa000)
	libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb77cd000)
	libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb77a6000)
	libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0xb77a1000)
	libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0xb7799000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb7780000)
	libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7776000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0xb7687000)
	libz.so.1 => /usr/lib/libz.so.1 (0xb7670000)
	libm.so.6 => /lib/libm.so.6 (0xb764a000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb760c000)
	libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7607000)
	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7550000)
	libpthread.so.0 => /lib/libpthread.so.0 (0xb7538000)
	libc.so.6 => /lib/libc.so.6 (0xb73f4000)
	/lib/ld-linux.so.2 (0xb80d2000)
	libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb73f0000)
	libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb73ed000)
	libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb73e8000)
	libdl.so.2 => /lib/libdl.so.2 (0xb73e3000)
	libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0xb7390000)
	libnsl.so.1 => /lib/libnsl.so.1 (0xb7379000)
	libpoppler.so.3 => /usr/lib/libpoppler.so.3 (0xb71d5000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb70e7000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb70d7000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0xb70c8000)
	libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb70c5000)
	libXi.so.6 => /usr/lib/libXi.so.6 (0xb70bb000)
	libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb70b4000)
	libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb70aa000)
	libselinux.so.1 => /lib/libselinux.so.1 (0xb7090000)
	libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7069000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0xb7066000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7060000)
	libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb705d000)
	libpcre.so.3 => /lib/libpcre.so.3 (0xb7033000)
	libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7013000)

Comment 16 Bug Zapper 2009-06-09 09:25:49 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 17 Tom London 2009-06-25 23:50:55 UTC
I believe this is still broken in current rawhide.....

Printouts from evince look lousy (grey, jagged, barely legible), printouts from xpdf look dark and crisp.

Comment 18 R P Herrold 2009-06-26 19:05:08 UTC
Tom -- I'll change back in the RawHide status v F11 automove

Could you please note the specific evince version you are using? 

Thanks -- Russ herrold

Comment 19 Tom London 2009-06-27 01:48:16 UTC
evince-dvi-2.27.3-1.fc12.x86_64
poppler-glib-0.11.1-2.fc12.x86_64
poppler-utils-0.11.1-2.fc12.x86_64
evince-djvu-2.27.3-1.fc12.x86_64
evince-libs-2.27.3-1.fc12.x86_64
poppler-0.11.1-2.fc12.x86_64
evince-2.27.3-1.fc12.x86_64

Comment 20 Tom London 2009-07-09 16:02:42 UTC
Adding xpdf version, as it has no issues with rendering.

The difference between printed outputs of the same document to the same printer (xpdf vs. evince) is quite striking...

Comment 21 Tom London 2009-07-09 16:11:44 UTC
Sorry forgot to paste:

xpdf-3.02-13.fc12.x86_64

Comment 22 R P Herrold 2009-07-14 14:42:31 UTC
Kristian Høgsberg (krh@redhat.com) ping .. missing committer - pre-notice -- no comment in over a year

PDF output still looks horrible; as I see it evince should be pulled, and xpdf made the lead PDF viewer in Fedora

Comment 23 Tom London 2009-07-14 16:11:41 UTC
(In reply to comment #22)
> Kristian Høgsberg (krh@redhat.com) ping .. missing committer - pre-notice -- no
> comment in over a year
> 
> PDF output still looks horrible; as I see it evince should be pulled, and xpdf
> made the lead PDF viewer in Fedora  

I agree with this: let's fix or pull evince.

Don't know if the problem is with evince, poppler or .... , but I can't use evince to print pdf docs at all.  Xpdf output looks just fine.

Comment 24 Matthias Clasen 2009-07-15 16:42:10 UTC
> I agree with this: let's fix or pull evince.

Threats like that are not going to help fix your problem.
Fwiw, the document thats attached further up renders just fine on my system, in evince.

Comment 25 Tom London 2009-07-15 16:53:07 UTC
(In reply to comment #24)
> > I agree with this: let's fix or pull evince.
> 
> Threats like that are not going to help fix your problem.
> Fwiw, the document thats attached further up renders just fine on my system, in
> evince.  

Sorry, not meant to be a threat.....

Not sure this is helpful, but I decided to strace both xpdf and evince on the same 2 page document.

Running "grep 'open.*font'" on both of these seems to show some different fonts being loaded:

First for xpdf:

[root@tlondon Download]# grep 'open.*font' xpdf.txt | grep -v ENOENT
open("/usr/share/fonts/default/Type1/n022003l.pfb", O_RDONLY) = 4
open("/usr/share/fonts/default/Type1/n022004l.pfb", O_RDONLY) = 4
open("/usr/share/fonts/default/Type1/n022024l.pfb", O_RDONLY) = 4
open("/usr/share/fonts/default/Type1/n022023l.pfb", O_RDONLY) = 4
open("/usr/share/fonts/default/Type1/n019003l.pfb", O_RDONLY) = 4
open("/usr/share/fonts/default/Type1/n019004l.pfb", O_RDONLY) = 4
open("/usr/share/fonts/default/Type1/n019024l.pfb", O_RDONLY) = 4
open("/usr/share/fonts/default/Type1/n019023l.pfb", O_RDONLY) = 4
open("/usr/share/fonts/default/Type1/s050000l.pfb", O_RDONLY) = 4
open("/usr/share/fonts/default/Type1/n021004l.pfb", O_RDONLY) = 4
open("/usr/share/fonts/default/Type1/n021024l.pfb", O_RDONLY) = 4
open("/usr/share/fonts/default/Type1/n021023l.pfb", O_RDONLY) = 4
open("/usr/share/fonts/default/Type1/n021003l.pfb", O_RDONLY) = 4
open("/usr/share/fonts/default/Type1/d050000l.pfb", O_RDONLY) = 4
[root@tlondon Download]# 

Second for evince:

[tbl@tlondon Download]$ grep 'open.*font' evince.txt | grep -v ENOENT | grep -v '/etc/fonts'
open("/usr/lib64/libfontconfig.so.1", O_RDONLY) = 3
open("/var/cache/fontconfig/3830d5c3ddfd5cd38a049b759396e72e-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/1248881498ac025e45c3042f6afe9284-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/e19de935dec46bbf3ed114ee4965548a-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/ba36aa39dd649ae7ae3c14b18156d394-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/0251a5afa6ac727a1e32b7d4d4aa7cf0-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/12b26b760a24f8b4feb03ad48a333a72-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/b4d0b56f766d89640448751fcd18ec1e-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/46b47dbc682d2ca4191e148ea7bde7f2-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/d3379abda271c4acd2ad0c01f565d0b0-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/b67b32625a2bb51b023d3814a918f351-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/e61abf8156cc476151baa07d67337cae-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/6082f993537e886e2b8c280984f3ae67-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/6fcb01a03a016cc71057b587cdea6709-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/044963cbb93fcb06c61d94a50dee394f-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/6cfc7d49b27ba7d3eb71ab86e04def2c-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/81a173283b451552b599cfaafd6236bd-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/830f035fa84a65ce80e050178dbb630d-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/3f821257dd33660ba7bbb45c32deb84c-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/5c755b2f27115486aa6359c84dd3cbda-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/2e1514a9fdd499050989183bb65136db-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/b79f3aaa7d385a141ab53ec885cc22a8-x86-64.cache-2", O_RDONLY) = 10
open("/var/cache/fontconfig/87f5e051180a7a75f16eb6fe7dbd3749-x86-64.cache-2", O_RDONLY) = 10
open("/usr/share/fonts/dejavu/DejaVuSans.ttf", O_RDONLY) = 10
open("/usr/share/fonts/dejavu/DejaVuSans-Oblique.ttf", O_RDONLY) = 18
[tbl@tlondon Download]$ 

Is there some simple way to get an "index" from fontconfig to see what fonts are being loaded?  

[My issues are mostly with printing and the above font lists did not include any font loading specifically for printing.]

Comment 26 Tom London 2009-07-15 17:05:46 UTC
Printing the first page of the "revised pdf" attached above (its the title page) shows the problem: the evince output looks like it was printed on an old dot-matrix printer, while the xpdf output looks "pretty good".

Suggestions/hints on how to help track this down welcomed!

Comment 27 Jesse Keating 2009-07-15 17:08:07 UTC
There was one thought, are you running a gnome desktop, with gnome-settings-daemon running?

Comment 28 R P Herrold 2009-07-15 17:08:49 UTC
Characterizing a comment as a threat is not helpful, and frankly, if a bug
reproduces on a sustained basis (which this has), and it takes special handling
(one assumes fonts, although identical fonts are installed in my tests), evince
is broken as to what it is specifying as its Requires  or how it is using fonts

Matthias Clasen (mclasen@redhat.com) as to comment 24, what is used on your box
that makes it different?  That information would be a more helpful response
that a 'snipe', perhaps.

As the sole person in Fedora to whom evince bugs are assigned, has never
commented, we are left to speculate as to that is needed.

Fix evince, or pull it as a preferred PDF viewer, is all I can see as a path
forward.  It is not ready for prime time, and has been this way for three
Fedora release cycles.

xpdf (and for that matter the commercial Adobe reader) have not problem with
extreme magnifications; do not have the nasty background wash; print well, and
are faster, and searchible with much greater ease.

I don't care WHAT solution is adopted, but the current evince is not usable for
18 months

-- Russ herrold

Comment 29 Tom London 2009-07-15 17:20:48 UTC
(In reply to comment #27)
> There was one thought, are you running a gnome desktop, with
> gnome-settings-daemon running?  

Yes:

[root@tlondon tbl]# ps agx | grep settings
 1091 ?        S      0:00 /usr/sbin/nm-system-settings --config /etc/NetworkManager/nm-system-settings.conf
 1712 ?        Ssl    0:07 /usr/libexec/gnome-settings-daemon
11790 pts/0    S+     0:00 grep settings
[root@tlondon tbl]#

Comment 30 Tom London 2009-07-15 17:24:30 UTC
Getting both evince and xpdf to write postscript to files instead of printer, and then looking at font stuff:

First evince:
[root@tlondon tbl]# grep -i font evince-print.out 
2 lt { /Helvetica findfont 12 scalefont setfont 50 500 moveto
    { show } { -0.001 mul 0 cairo_font_matrix dtransform rmoveto } ifelse
/cairo_selectfont { cairo_font_matrix aload pop pop pop 0 0 6 array astore
    cairo_font exch selectfont cairo_point_x cairo_point_y moveto } bind def
/Tf { pop /cairo_font exch def /cairo_font_matrix where
      { pop cairo_selectfont } if } bind def
/Td { matrix translate cairo_font_matrix matrix concatmatrix dup
      /cairo_font_matrix exch def dup 4 get exch 5 get cairo_store_point
      /cairo_font where { pop cairo_selectfont } if } bind def
/Tm { 2 copy 8 2 roll 6 array astore /cairo_font_matrix exch def
      cairo_store_point /cairo_font where { pop cairo_selectfont } if } bind def
%!FontType1-1.1 f-0-0 1.0
/FontName /f-0-0 def
/FontType 1 def
/FontMatrix [0.001 0 0 0.001 0 0] readonly def
/FontBBox {0 -16 744 702                                     } readonly def
%!FontType1-1.1 f-1-0 1.0
/FontName /f-1-0 def
/FontType 1 def
/FontMatrix [0.001 0 0 0.001 0 0] readonly def
/FontBBox {0 -192 852 694                                    } readonly def
[root@tlondon tbl]# 

Second xpdf:
[tbl@tlondon ~]$ grep -i font xpdf-print.out 
  /pdfFontSize 0 def
% build a font
/pdfMakeFont {
  4 3 roll findfont
  4 2 roll matrix scale makefont
  definefont pop
/pdfMakeFont16 {
  exch findfont
  definefont pop
/Tf { dup /pdfFontSize exch def
      exch findfont exch makefont setfont } def
    currentfont /FontType get 0 eq {
    currentfont /FontType get 3 eq { fCol } { sCol } ifelse
/TJm { pdfFontSize 0.001 mul mul neg 0
/TJmV { pdfFontSize 0.001 mul mul neg 0 exch
%%BeginResource: font SUWLFF+CMR12
%!FontType1-1.0: SUWLFF+CMR12
/FontInfo 10 dict dup begin
/FontName /SUWLFF+CMR12 def
/FontType 1 def
/FontMatrix [0.001 0 0 0.001 0 0] readonly def
/FontBBox [-34 -251 988 750] readonly def
pdfMakeFont
%%BeginResource: font LCEMKZ+CMR17
%!FontType1-1.0: LCEMKZ+CMR17
/FontInfo 10 dict dup begin
/FontName /LCEMKZ+CMR17 def
/FontType 1 def
/FontMatrix [0.001 0 0 0.001 0 0] readonly def
/FontBBox [0 -204 744 702] readonly def
pdfMakeFont
%%+ font SUWLFF+CMR12
%%+ font LCEMKZ+CMR17
[tbl@tlondon ~]$ 

Are the fonts that evince/xpdf select different ("f" vs. "SUWLFF+CMR12")?

Sorry if this is a misdirect........

Comment 31 Matthias Clasen 2009-07-15 17:41:41 UTC
Tom, I am not sure if we are mixing two issues here. My comments so far have all been related to on-screen rendering of the original reporters document that is attached earlier.

> I don't care WHAT solution is adopted, but the current evince is not usable for
> 18 months

I'm sorry that evince does not work perfectly for you, but that is a pretty apodictic statement to make. I know plenty of people who consider evince perfectly usable, and I had at least 4 people tell me that they cannot reproduce your rendering problem either.

As a first step towards finding where your problem lies, maybe you could tell us what desktop environment you are running evince in. Is gnome-settings-daemon running ?

I have no problems with your document with

evince-2.27.4-1.fc12.x86_64
poppler-0.11.1-2.fc12.x86_64
cairo-1.8.8-1.fc12.x86_64
freetype-2.3.9-4.fc12.x86_64

Comment 32 Tom London 2009-07-15 17:55:01 UTC
(In reply to comment #31)
> Tom, I am not sure if we are mixing two issues here. My comments so far have
> all been related to on-screen rendering of the original reporters document that
> is attached earlier.
> 
Looks like I may have "jumped" on this BZ.  Sorry.

Shall I open a separate BZ just for my printing issue?

For the record, I see no difference with on screen rendering of the "command.pdf" document @ 400%.  Both are clear/crisp and look identical.

I only see a problem when I print.

I am running:

poppler-0.11.1-2.fc12.x86_64
cairo-1.8.8-1.fc12.x86_64
gnome-settings-daemon-2.27.4-1.fc12.x86_64
freetype-2.3.9-4.fc12.x86_64
evince-2.27.4-1.fc12.x86_64

Comment 33 R P Herrold 2009-07-15 17:56:00 UTC
thank you

WM is xfce

evince seems not to be in last night's RawHide mirror snapshot for me -- I'll build the rest to your versions, and put a watch for evince to appear

[herrold@centos-5 evince]$ srcfind -r evince
/home/herrold/.tmp/srcfind.cache.txt
evince     nil

[herrold@centos-5 evince]$ srcfind -r poppler
/home/herrold/.tmp/srcfind.cache.txt
poppler          /mnt/nfs/var/ftp/pub/mirror/redhat/rawhide/SRPMS/poppler-0.11.1-2.fc12.src.rpm

[herrold@centos-5 evince]$ srcfind -r cairo | grep cairo-[0-9]
cairo    /mnt/nfs/var/ftp/pub/mirror/redhat/rawhide/SRPMS/cairo-1.8.8-1.fc12.src.rpm

[herrold@centos-5 evince]$ srcfind -r freetype | grep freetype-[0-9]
freetype         /mnt/nfs/var/ftp/pub/mirror/redhat/rawhide/SRPMS/freetype-2.3.9-4.fc12.src.rpm

[herrold@centos-5 evince]$ rpm -q evince poppler cairo freetype | sort | uniq
cairo-1.2.4-5.el5
freetype-2.2.1-21.el5_3
package evince is not installed
poppler-0.5.4-4.4.el5_3.9
[herrold@centos-5 evince]$

Comment 34 R P Herrold 2009-09-15 13:26:30 UTC
I see one has appeared -- will retest with: evince   /mnt/nfs/var/ftp/pub/mirror/redhat/rawhide/SRPMS/evince-2.27.90-1.fc12.src.rpm

Comment 36 Bug Zapper 2009-11-16 08:00:24 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 37 Marek Kašík 2010-03-25 13:21:04 UTC
Hi,

this is a bug in poppler. You can see it when converting those files using pdftoppm which is from poppler-utils.

Marek

Comment 38 Marek Kašík 2010-03-25 16:28:17 UTC
I was wrong. I commented about difference between version which has \usepackage[T1]{fontenc} and the second one. I see the text a little jagged.
But still, drawing of Type 3 fonts included in the pdf is performed by poppler.

Marek

Comment 39 Marek Kašík 2010-03-25 16:29:36 UTC
Do you still see the problem on Fedora 12?

Marek

Comment 40 Marek Kašík 2010-03-25 17:00:54 UTC
I see something similar when the document is rotated -90 degrees.

Marek

Comment 41 Bug Zapper 2010-11-04 12:03:29 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 42 R P Herrold 2010-11-04 13:50:57 UTC
The suggestion is that this is a poppler bug  -- and this ticket is now in that component ---

Is more testing to demonstrate the issue needed somehow?

moving away from the auto-closer

Comment 43 Marek Kašík 2010-11-04 15:01:38 UTC
Hi Russ,

which operating system do you use? I see in comment #33 that you have el5 packages installed but the report is against Fedora.
I've just tested it on rawhide since you changed the version to it but I can not reproduce it.

Marek

Comment 44 R P Herrold 2010-11-04 15:38:51 UTC
I alternately run several distributions; if anything it is RawHide that I live in

[my 'stable' starting point 'home base' began life as a CentOS 5, but is heavily modified -- my /home (partly NFS shared to many boxes), and usual X-desktop mainly live there]

This is so I may ssh to a remote X-client, and drill in testing of self-built leaf nodes from RawHide on various later distributions (I am setting up the F14 unit today, for example)

I will re-test and advise -- as I read the comment noted, the matter was not addressed, and I do not see it in the changelog for RawHide's poppler

-- Russ herrold

Comment 45 Marek Kašík 2010-11-09 09:12:50 UTC
Could you post here results of this command?:

ldd `rpm -ql evince-libs | grep libpdfdocument` | grep poppler

Could you also run "rpm -qf" on those absolute paths returned by the command?

Marek

Comment 46 R P Herrold 2010-11-09 15:38:09 UTC
When I went to move to HEAD, I do not see that an evince is presently in my RawHide mirror ...

[herrold@centos-5 ~]$ srcfind -r evince 
evince     nil

I have not set up a mirror on 14 yet

Is 
   fedora/13/updates/SRPMS/evince-2.30.3-1.fc13.src.rpm
current enough, and if so I will solve and retest?

-- Russ herrold

Comment 47 Marek Kašík 2010-11-10 08:14:49 UTC
Hi Russ,

evince-2.30.3-1.fc13.src.rpm is current enough (together with poppler-0.12.x).

Marek

Comment 48 Marek Kašík 2010-12-02 13:56:08 UTC
Hi Russ,

do you still see the problem in rawhide?

Marek

Comment 49 R P Herrold 2010-12-13 04:26:19 UTC
sadly, I cannot get a clean install to build and test with -- 

Please close as I cannot presently reproduce the effect

Thanks for checking this

-- Russ herrold

Comment 50 Marek Kašík 2010-12-13 09:42:06 UTC
Hi,

I'm closing this then.

Regards

Marek


Note You need to log in before you can comment on or make changes to this bug.