Created attachment 291594 [details]
test file to compare with

and here is the comparison screenshot

Created attachment 291595 [details]
bad looking evince compared to xpdf screenshot

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

Created attachment 297316 [details]
screenshot at 400% in evince of the reviewd test file:

Created attachment 297317 [details]
revised test PDF file built in LaTeX without \usepackage[T1]{fontenc}

Is any further information needed to advance this bug?  I see it is still in NEW
status?

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

three more months and still untouched -- what is needed?

Any way to get a reply on this?

This bug has been triaged

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

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 ~]$

the needinfo flag did not clear -- clearing

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)

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

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.

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

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

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

Sorry forgot to paste:

xpdf-3.02-13.fc12.x86_64

Kristian Høgsberg (krh) 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

(In reply to comment #22)
> Kristian Høgsberg (krh) 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.

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

(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.]

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!

There was one thought, are you running a gnome desktop, with gnome-settings-daemon running?

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) 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

(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]#

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

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

(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

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]$

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

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

Hi,

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

Marek

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

Do you still see the problem on Fedora 12?

Marek

I see something similar when the document is rotated -90 degrees.

Marek

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

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

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

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

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

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

Hi Russ,

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

Marek

Hi Russ,

do you still see the problem in rawhide?

Marek

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

Hi,

I'm closing this then.

Regards

Marek