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 674613 - Evince cannot display angled symbols (arrow)
Evince cannot display angled symbols (arrow)
Status: RESOLVED NOTGNOME
Product: evince
Classification: Core
Component: PDF
3.2.x
Other Linux
: Normal normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-04-23 10:15 UTC by Jorge Cabaleiro
Modified: 2016-06-29 11:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Tikz-uml user guide in french (418.34 KB, application/pdf)
2012-04-23 10:15 UTC, Jorge Cabaleiro
Details
TEX file from which a PDF demonstrating the problem can be created (860 bytes, text/x-tex)
2016-06-29 11:02 UTC, Michael Jacobs
Details
PDF file demonstrating the problem and its dependence of angle AND zoom level (22.94 KB, application/pdf)
2016-06-29 11:04 UTC, Michael Jacobs
Details

Description Jorge Cabaleiro 2012-04-23 10:15:24 UTC
Created attachment 212594 [details]
Tikz-uml user guide in french

With a pdf file generated using package tikz-uml some angled arrows and other symbols cannot be seen.

Pdf with figure is attached: imagen is in page 7 (number 6), in chapter 1.2.1. There is a correct reference image in online documentation from tikz-uml here on chapter "Relations entre classes > Commande générale":
http://www.ensta-paristech.fr/~kielbasi/tikzuml/index.php?id=doc#t-1
Comment 1 André Klapper 2012-04-23 13:05:38 UTC
Confirming in evince-3.2.1-2.fc16.i686. 
Works correctly in xpdf-3.03-1.fc16.i686.
Comment 2 Carlos Garcia Campos 2012-05-02 17:55:33 UTC
Looks like a poppler issue, Forwarded it to fdo bugzilla:

https://bugs.freedesktop.org/show_bug.cgi?id=49393

Thanks for reporting
Comment 3 Michael Jacobs 2016-06-29 11:01:05 UTC
This bug seems to still not be solved.

Moreover, the behavior seems to depend on the actual zoom level.

I created the following small example with latex/tikz:
\begin{tikzpicture}[state/.style={circle,fill=black,draw,inner sep=0pt,minimum size=0.2cm}]
	\node[state] (s) at (0,0)[label={[label distance=0.2cm,anchor=base]180:$s_{1}$}] {};
	\node[state] (s2) at (0,1)[label={[label distance=0.2cm,anchor=base]180:$s_{2}$}] {};
	\draw (s) edge [->,out=315,in=45,looseness=28] node[above] {$e$} (s);
	\draw[->] (s) -- (s2);
\end{tikzpicture}

When rendering this to PDF, I noticed that the arrow pointing straight up (from s to s2) is displayed properly, while the self-loop from s to itself is displayed without arrow head.

Taking a closer look at the problem, I noticed that this is a rendering bug which depends on the actual zoom level. Zoom levels of 166% and smaller lead to the arrow head missing. Zoom levels of 167% and higher display the arrow head as expected.

Taking an even closer look at the problem, I realized that the angle also plays a role, which actually lead me to this bug already tracked. When I change my small example in a way that self-loop enters node s with an angle which is a full multiple of 90 degrees (0 degrees, 90, 180, 270), the arrow head is displayed correctly independently of the zoom level:
\begin{tikzpicture}[state/.style={circle,fill=black,draw,inner sep=0pt,minimum size=0.2cm}]
	\node[state] (s) at (0,0)[label={[label distance=0.2cm,anchor=base]180:$s_{1}$}] {};
	\node[state] (s2) at (0,1)[label={[label distance=0.2cm,anchor=base]180:$s_{2}$}] {};
	\draw (s) edge [->,out=315,in=0,looseness=28] node[above] {$e$} (s);
	\draw[->] (s) -- (s2);
\end{tikzpicture}

I have created a file small.tex with the two variants of the tikzpicture. I build a PDF from it using the following command:
latexmk -pdf small.tex

This results in small.pdf which allows to see the rendering problems I described.

I am using evince version 3.20.1-1 from the Arch Linux extra repository.

I will upload the files for further investigation of the problem.

If this additional information still supports the view that this is a poppler issue (which I cannot really judge), I'd be glad if Carlos could again update the corresponding entry in the poppler bugtracker in order to let the poppler guys know that we found out additional details.
Comment 4 Michael Jacobs 2016-06-29 11:02:58 UTC
Created attachment 330555 [details]
TEX file from which a PDF demonstrating the problem can be created
Comment 5 Michael Jacobs 2016-06-29 11:04:31 UTC
Created attachment 330557 [details]
PDF file demonstrating the problem and its dependence of angle AND zoom level