After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 325919 - Evince ps misrendering starting from middle of the document
Evince ps misrendering starting from middle of the document
Status: RESOLVED FIXED
Product: evince
Classification: Core
Component: general
0.4.x
Other Linux
: Normal normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-01-05 22:46 UTC by Sebastien Bacher
Modified: 2006-01-06 23:59 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastien Bacher 2006-01-05 22:46:52 UTC
This bug has been opened here: http://bugzilla.ubuntu.com/show_bug.cgi?id=21703

"When opening the file located at http://nullinfinity.org/unt_granskning.ps.gz
for the first time, everything is displayed correctly. If I open the file a
second time, all the text is replaced by random characters. Removing
~/.gnome2/evince/ev-metadata.xml allows me to correctly view the file again.
This is with up-to-date dapper on amd64, evince version 
0.4.0-1ubuntu4, poppler version 0.4.2-1ubuntu5."
Comment 1 Nickolay V. Shmyrev 2006-01-05 23:22:41 UTC
I can't reproduce this with HEAD and suppose it's a 64-bit problem, so it would be hard to debug it. Any ideas how this bug can be tested?
Comment 2 Sebastien Bacher 2006-01-06 00:09:49 UTC
it happens with current tarballs on a i386 installation
Comment 3 Christian Persch 2006-01-06 12:16:31 UTC
I cannot reproduce this in current evince HEAD (i386).

The only 64bit problem I can see in ev-metadata-manager is this one in 

        /* FIXME: is the cast right? - Paolo */
        atime = g_strdup_printf ("%d", (int)item->atime);
        xmlSetProp (xml_node, (const xmlChar *)"atime", (const xmlChar *)atime);

time_t can be 64bit on some 64bit platforms, so this %d and the cast are definitely NOT right.

And in parseItem:

        item->atime = atol ((char *)atime);

it should then use g_ascii_strtoull.
Comment 4 Nickolay V. Shmyrev 2006-01-06 14:22:38 UTC
Ah, I see, I can reproduce this bug. The problem is certainly not in metadata and 64 bit, you should just start from the middle of the document. For example, if document position is saved on page 6 for the particular ps document above.
Comment 5 Martin Kretzschmar 2006-01-06 14:50:01 UTC
> time_t can be 64bit on some 64bit platforms, so this %d and the cast are
> definitely NOT right.

Isn't this "just" the year 2038 problem, i.e. no problems on current 64bit systems?

Comment 6 Nickolay V. Shmyrev 2006-01-06 18:18:16 UTC
Actually it's mozilla bug. The document is not correctly printed. By specs, postscript document must have the following layout:

......
%%BeginProlog
%%BeginResource
%%EndResource
%%EndProlog
%%BeginPage
....

But this one has:

......
%%BeginProlog
%%EndProlog
%%BeginResource
%%EndResource
%%BeginPage
....

So this document is broken, that is the reason of incorrect rendering, so I suspect you should report a mozilla bug instead.
Comment 7 Sebastien Bacher 2006-01-06 18:30:03 UTC
why is it displayed fine on the first opening so?
Comment 8 Nickolay V. Shmyrev 2006-01-06 19:25:11 UTC
Our parser think that first page begins here:

%%BeginProlog
%%EndProlog 
%%BeginResource  <- start of 1-st page
%%EndResource
%%BeginPage

so when you start display from the first page, missing resources are passed to ghostscript interpreter. If you start from the middle, only prolog is passed.
Comment 9 Nickolay V. Shmyrev 2006-01-06 23:59:33 UTC
I've committed workaround this bug into evince HEAD and filed mozilla bug:

http://bugzilla.mozilla.org/show_bug.cgi?id=322621

long vs int problem is also fixed.