Evince not rendering Postscript files

[Walter Garcia-Fontes]

Since the last updates to Ubuntu 13.04, Evince is not rendering postscript files any more. I attach a very simple file I produced with LaTeX. I also attach a video that shows what happens, it tries to show the page, but then a 1 (for page 1) appears in the miniature sidebar at the left, and it says "Loading..." but nothing happens.

This is what evince shows from the terminal line:

undefined -21
undefined -21

(evince:6210): EvinceDocument-CRITICAL **: ev_document_misc_pixbuf_from_surface: assertion `surface' failed

(evince:6210): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
undefined -21

(evince:6210): EvinceDocument-CRITICAL **: ev_document_misc_pixbuf_from_surface: assertion `surface' failed

(evince:6210): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

(evince:6210): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.35.9/./gobject/gsignal.c:2593: instance `0x7fe4adceee30' has no handler with id `4363'

(evince:6210): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.35.9/./gobject/gsignal.c:2593: instance `0x7fe4adceee30' has no handler with id `4364'

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: evince 3.6.1-1ubuntu3
ProcVersionSignature: Ubuntu 3.8.0-14.24-generic 3.8.4
Uname: Linux 3.8.0-14-generic x86_64
ApportVersion: 2.9.2-0ubuntu2
Architecture: amd64
Date: Mon Mar 25 18:51:09 2013
InstallationDate: Installed on 2012-05-31 (298 days ago)
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
MarkForUpload: True
SourcePackage: evince
UpgradeStatus: Upgraded to raring on 2013-02-28 (25 days ago)

[Nqn1976 (nqn1976)]

With ghostscript 9.07, libspectre-based viewers like evince and okular can't display .ps files anymore. Reverting to 9.06 fixes it.

[Albert Astals Cid (aacid)]

Giving some files

https://bugs.kde.org/attachment.cgi?id=77770
https://bugs.kde.org/attachment.cgi?id=77771

[Albert Astals Cid (aacid)]

using LANG=C fixes it, i.e.

LANG=C okular myfile.eps
LANG=C evince myfile.eps

Will make it work

[Albert Astals Cid (aacid)]

Talked to the ghostcript devels and they agree it's a bug in their side, for now they said we can workaround it by adding
char *lala = setlocale(LC_ALL, "POSIX");
gsaspi_call
setlocale(LC_ALL, lala);

to our code.

Carlos, what do you think?

[Walter Garcia-Fontes (walter-garcia)]

Simple Postscript file that evince is not able to render

[Walter Garcia-Fontes (walter-garcia)]

Video showing what happens when I try to open the previous file

[Carlos Garcia Campos (carlosgc)]

(In reply to comment #3)
> Talked to the ghostcript devels and they agree it's a bug in their side, for
> now they said we can workaround it by adding
> char *lala = setlocale(LC_ALL, "POSIX");
> gsaspi_call
> setlocale(LC_ALL, lala);
>
> to our code.

for every call to the GS API?

> Carlos, what do you think?

The problem of that hack is that setlocale might affect other threads currently running. Do we know which versions exactly are affected by this bug? Is it fixed already? is there a patch distros could apply?

[Andre Herman (andre-herman)]

Same problem is occuring here, after a fresh install of ubuntu 13.04.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu Raring Ringtail (development branch)
Release: 13.04
Codename: raring

$ evince mm.eps
undefined -21
undefined -21

(evince:4843): EvinceDocument-CRITICAL **: ev_document_misc_pixbuf_from_surface: assertion `surface' failed

(evince:4843): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

(evince:4843): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.36.0/./gobject/gsignal.c:2593: instance `0x7f50ee622050' has no handler with id `4379'

(evince:4843): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.36.0/./gobject/gsignal.c:2593: instance `0x7f50ee622050' has no handler with id `4380'

I tried open other eps files and the same problem occured.

[Walter Garcia-Fontes (walter-garcia)]

Can you please click "This bug affects me" as this will confirm the bug automatically?

[Walter Garcia-Fontes (walter-garcia)]

Backtrace generated with gdb.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Albert Astals Cid (aacid)]

(In reply to comment #4)
> (In reply to comment #3)
> > Talked to the ghostcript devels and they agree it's a bug in their side, for
> > now they said we can workaround it by adding
> > char *lala = setlocale(LC_ALL, "POSIX");
> > gsaspi_call
> > setlocale(LC_ALL, lala);
> >
> > to our code.
>
> for every call to the GS API?

That's what they said

>
> > Carlos, what do you think?
>
> The problem of that hack is that setlocale might affect other threads
> currently running.

Oh, that's bad

> Do we know which versions exactly are affected by this
> bug?

9.07

> Is it fixed already? is there a patch distros could apply?
No clue, i told them on IRC and they said the bug has been there forever, but it's not since with 9.06 it works, they said they'd fix it but can't find anything in their git log that says it's been fixed. Going to download and compile now to try here

[Albert Astals Cid (aacid)]

Tried last git version and still fails :_/

[Albert Astals Cid (aacid)]

Upstream bug http://bugs.ghostscript.com/show_bug.cgi?id=693843

[Walter Garcia-Fontes (walter-garcia)]

According the bug upstream this is a problem in ghostscript 9.07 which is not handling the decimal separator correctly, when it is set locally as "," instead of "." by some languages. See:

http://bugs.ghostscript.com/show_bug.cgi?id=693843

A workaround until it is fixed is to set the "regional formats" of the language support to a language where the decimal separator is the dot ".", for instance English.

[AlessandroS (cicerone54)]

Answer #11 works for me.

[Albert Astals Cid (aacid)]

That's been fixed upstream, we can probably close this bug and just hope distros patch their stuff

[JMB (jmb-tux)]

I don`t understand while a bug known for so long seems to be still present in Xubuntu 13.04.
If ghostscript is the problem why is the buggy version still in use?
Or do I encounter a different problem?

Additional, the workaround (comment #11) given above is not effective (at least not
for me):

$ echo $LANG
en_US.UTF-8
evince <name>.ps
    "EvinceDocument-CRITICAL **: ev_document_misc_pixbuf_from_surface: assertion `surface' failed"

export LANG=C
$ echo $LANG
C
evince <name>.ps
    "EvinceDocument-CRITICAL **: ev_document_misc_pixbuf_from_surface: assertion `surface' failed"

Is there an effective workaround known (commandliner would be appreciated)?

Any fixed/improved packages available via PPA (if not generally)?

Or are users forced to use gv (it still works - so many users may use it as workaround - but I really
would like to use evince for PS viewing)?

[JMB (jmb-tux)]

After a little bit of experimenting I found a valid workaround for me:
   LANG=en_US evince <name>.ps
(which is also soltion for the search-problem in current google-earth).

Nevertheless one should fix this nasty regression for those users not accustomed to
setting variables, looking through forums and bug trackers etc.

[astroman (astrosousa)]

Hi,

Just to say that I have the same bug.
It is affecting me in the latest Ubuntu release as it is in the latest Lubuntu.

The setting of the variable is not a proper solution. Isn't there another way to fix this and behave more automatically?
I made a simple script to call evince/okular with the setting of the variable, but whenever I want to directly view a ps file from an email attachment or any other program that call okular/evince It's a mess.

Ps. I wonder why I only notice this bug today. I normally use this a lot and I am almost certain that this was working until very recently...

[Sebastien Bacher (seb128)]

The issue is fixed in saucy which has a newer ghostscript version