Ubuntu

Internal and external links diplay and print problem

Reported by Belcirelk on 2007-10-24
22
Affects Status Importance Assigned to Milestone
Evince
Invalid
Medium
evince (Ubuntu)
Low
Ubuntu Desktop Bugs

Bug Description

Binary package hint: evince

Evince display all the links in a document inside a pdf document inside a ugly red box. It's impossible to remove these box. These box also appear when you print the document. A example here : http://eric.beliweb.net/web/evince.png

Note that these box are not displaying in acroread.

ProblemType: Bug
Architecture: i386
Date: Wed Oct 24 07:13:47 2007
DistroRelease: Ubuntu 7.10
ExecutablePath: /usr/bin/evince
Package: evince 2.20.0-0ubuntu3
PackageArchitecture: i386
ProcCmdline: evince
ProcCwd: /home/eric
ProcEnviron:
 SHELL=/bin/bash
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=fr_CA.UTF-8
SourcePackage: evince
Uname: Linux beleport 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

Belcirelk (beliveau) wrote :
Pedro Villavicencio (pedro) wrote :

Thanks for your report, Does it happen with every pdf file you're viewing? i have a couple here with external links and they get printed fine. Can you attach the pdf with the problems? thanks.

Changed in evince:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete
Belcirelk (beliveau) wrote :

See the pdf sample in attachment.
Some pdf that i have works well.
For this one, i know it was working before on gentoo with evince 2.20.

Charles Roduit (charles-roduit) wrote :

I confirm,

PDF created with latex, viewed and printed in feisty, looked normal.

After upgrade to gutsy, internal link look red, bibliography link look green and web link look blue. This appears also in freshly installed gutsy.
These boxes are also present in the printed pages.

Something strange, I tried to look with xpdf and with acrobat reader and the same problem appears.

Belcirelk (beliveau) wrote :

In xpdf i also got the colored box (as always) on the screen but it print without the box.
In acroread, no box at all around links (see attachment).

Sisyphe (verslenet-buntu) wrote :

I have the same problem with latex created pdf files... except I do not use evince but kpdf !

As for others above, xpdf and acroread print fine. Since this problem arises only when using evince and kpdf, maybe it is due to something they have in common. Could it be poppler ?

Roel Huybrechts (rulus) wrote :

I can confirm the issue with pdf files created with LaTeX.

Michael R. Head (burner) wrote :

Yeah, these are really ugly. They must be new in gutsy, right?

At the very least, these boxes should be hidden in presentation mode.

Michael R. Head (burner) wrote :

I get the boxes when I use the hyperref in my latex documents (I don't recall every seeing them before gutsy, but so be it). What I found is that I can tell hyperref not to draw the boxes like so:

\usepackage[pdftex, pdfborderstyle={/S/U/W 0} % this disables the boxes around links
            ]{hyperref}

Then pdflatex doesn't put the boxes in the PDF.

(this is a copy of my comment in bug 157073)

Michael R. Head (burner) wrote :

This may be due to what's describe in the hyperref doc: http://www.tug.org/applications/hyperref/ftp/README

  * Be aware that not all PDF viewers support this feature, not
    even Acrobat Reader itself:

    Some support:
    * AR7/Linux: "underline" and "dashed", but the border width
      must be given.
    * xpdf 3.00: "underline" and "dashed"

    Unsupported:
    * AR5/Linux
    * ghostscript 8.50

So it may be that these boxes were there (in the doc) before, but weren't supported in poppler or acrobat reader, and now they are (?)

Sisyphe (verslenet-buntu) wrote :

Adding the pdfborderstyle={/S/U/W 0} to the hyperref package when producing a pdf suppresses all visual clues as to the existence of hyperlinks in the document. A strange idea to me : you create a pdf with hyperlinks yet there is nothing that tells the user that some part of the text is a link until, by chance, his cursor changes when passing over the link.

Anyway, let's not confuse the method of creation of the pdf with the display and print of the document. Evince and kpdf do the latter and usually the user (I mean the person reading the doc) has no control on how it was produced.

When Michael above says that these boxes were probably present in the documents in the past, he is right. For as long as I've used latex, I have made documents with those red boxes around links. And for years now I was able to see them in kpdf, xpdf and acroread (I don't use evince much to remember how it was then) when displaying the document but somehow they were ignored when printing. Now with latest versions of evince and kpdf (but not xpdf nor acroread), those red boxes are also printed and that is both ugly and useless.

Thank you Michael for your suggestion but I really want the best of both worlds : pdf with hyperlinks clearly visible on screen but invisible on paper. That's what we had in the past.

Now why has this changed ? Is this a bug or a feature ? When someone creates a pdf and puts those red boxes around links, does he intend to have them on screen only or on paper as well ? What shoud the reader do ? I for one wish this behaviour could be set as an option in the reader. If it can't, I'd rather go back to the former behaviour.

Michael R. Head (burner) wrote :

Evince didn't previously display support coloring around the links at all until 7.10 (I don't have proof of this in a changelog, but I've been using evince and submitting pdfs for publication for a while and would not have done so if the PDFs showed up to me with ugly squares painted around my links and references!).

You're right, though, the boxes should definitely not show up when printing. Nor should they show up in the nautilus thumbnail or in presentation mode, IMO.

Pedro Villavicencio (pedro) wrote :

Thanks for the info!, I've sent this upstream at : http://bugzilla.gnome.org/show_bug.cgi?id=503087

Changed in evince:
status: Incomplete → Triaged
Changed in evince:
status: Unknown → New
Pedro Villavicencio (pedro) wrote :

comments from upstream:

"The problem is that this document is wrong. It contains annotations like:

293 0 obj <<
/Type /Annot
/Border[000]/H/I/C[1 0 0]
/Rect [113.877 570.67 219.679 584.617]
/Subtype /Link
/A << /S /GoTo /D (chapter*.3) >>
>> endobj

The Border array is wrong. According to the PDF spec:

"the array consists of three numbers defining the horizontal corner
radius, vertical corner radius, and border width, all in default user space
units.
If the corner radii are 0, the border has square (not rounded) corners; if the
border width is 0, no border is drawn"

In this case the array has only one item, since there is no space between the
'0'. The spec also says that default value is [ 0 0 1 ].

I would like to know why acroread doesn't draw the borders.

In case of printing, it was already fixed in svn.
"

marking it as fix committed since the fix of the print problem is fixed in upstream svn, thanks you.

Changed in evince:
status: Triaged → Fix Committed
Changed in evince:
status: New → Invalid
Sebastien Bacher (seb128) wrote :

the bug should be fixed in hardy, feel free to reopen if you still get the issue using the new versions though

Changed in evince:
status: Fix Committed → Fix Released
Sebastian Senander (senanders) wrote :

this is occuring in hardy too....

Changed in evince:
status: Fix Released → New
Robert Jordens (jordens) wrote :

confirming it in hardy as well
take any pdf from arxiv and print it. the boxes appear.
http://de.arxiv.org/pdf/cond-mat/9809162v1

Changed in evince:
status: New → Confirmed
Roel Huybrechts (rulus) wrote :

Confirmed in Hardy. Excerpt from affected pdf:

obj <<./Type
/Annot./Border[0 0 1]/H/I/C[1 0
0]./Rect [425.531 286.992 432.9
78 298.682]./Subtype /Link./A <<
/S /GoTo /D (table.1) >>.>> end
obj

The border is shown in Evince (as it should, since the border width is 1), but appears too when the document is printed.. As you can see the Border array syntax is in accordance with the PDF spec as cited above.

Sebastien Bacher (seb128) wrote :

could you try if that's still an issue in intrepid?

Michael R. Head (burner) wrote :

It's definitely still there in intrepid. Still looks just like the screenshots posted from gutsy. (and the Acrobat Reader 8 still doesn't display the boxes).

Belcirelk (beliveau) wrote :

Are the box still diplayed when the document is printed ?

wilk (j-cubizolles) wrote :

For me the issue is resolved : the clickable box on the pdf file is not printed anymore.

I'm running evince : 2.24.1-ubuntu1

Michael R. Head (burner) wrote :

It's still displaying documents differently on screen that Acrobat Reader (ugly red and green boxes around links), which might not necessarily be a problem except that they still show in presentation mode, which makes Evince inappropriate for use as a presentation tool.

Sebastien Bacher (seb128) wrote :

upstream bug comment

"The problem is that this document is wrong. It contains annotations like:

293 0 obj <<
/Type /Annot
/Border[000]/H/I/C[1 0 0]
/Rect [113.877 570.67 219.679 584.617]
/Subtype /Link
/A << /S /GoTo /D (chapter*.3) >>
>> endobj

The Border array is wrong. According to the PDF spec:

"the array consists of three numbers defining the horizontal corner
radius, vertical corner radius, and border width, all in default user space
units.
If the corner radii are 0, the border has square (not rounded) corners; if the
border width is 0, no border is drawn"

In this case the array has only one item, since there is no space between the
'0'. The spec also says that default value is [ 0 0 1 ].

I would like to know why acroread doesn't draw the borders.

In case of printing, it was already fixed in svn. "

closing the bug in ubuntu too since the new version has been uploaded

Changed in evince:
status: Confirmed → Fix Released
Changed in evince:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.