Unwanted borders around fill areas when canvas is printed as a .tex

Hi ROOTers,

While making some PDFs of ROOT plots that I printed to .tex files (see here), I’m finding that filled areas, such as TGraph error bands with draw options >= 2, have borders around them that don’t appear in other formats. When the area has a solid fill, the border is the same color as the fill so it doesn’t look terrible, but the line thickness changes the size of the filled region. When I fill the area with a pattern, the box is always black. The following Python script demonstrates the problem when run on an SLC6 system with ROOT 6.06 and the appropriate LaTeX packages installed.

from ROOT import TGraphAsymmErrors, TCanvas
from os import system

c = TCanvas("c","c",1000,1000)
g = TGraphAsymmErrors(3)
for i in range(3):
g.SetPoint(i,i+1.,i+1.)
g.SetPointError(i,0.25,0.25,0.25,0.25)
g.SetFillColorAlpha(628,0.5)
g.SetFillStyle(3013)
g.SetLineColor(600)
g.Draw("a2")
c.Print("imageAsPDF.pdf")
c.Print("c.tex","tex")

latexFrame = '''
\\documentclass[tikz]{standalone}
\\usepackage{standalone}
\\usetikzlibrary{patterns}
\\usetikzlibrary{plotmarks}
\\usepackage{amsmath}
\\begin{document}
\\input{c.tex}
\\end{document}
'''

with open("imageAsTeX.tex","w") as f:
f.write(latexFrame)

system("pdflatex imageAsTeX.tex")


I can make the border disappear by editing c.tex by hand or with a regex to replace \draw with \path when it defines the relevant objects.

Cheers,
Nate

1 Like

Hi Nate,

I do not see a such border on Mac. I have taken your example (converted into C++), ran it,
made a .tex file to include it (same way as you did), generated the pdf file using pdflatex, and preview the resulting pdf file on screen using preview. I get the following output on screen:

I am using ROOT master on Mac.

Cheers,
Olivier

Hi Olivier,

Interesting! I made mine on SLC6 and the boxes appear in several PDF viewers on SLC6 and Ubuntu (the PDF viewer in Firefox on Ubuntu replaces the hatching with hundreds of tiny arrows for some reason, but this is a separate issue). Here’s what it looks like in Evince on Ubuntu

Here’s the PDF (zipped to allow upload) if you want to see what it looks like for you in Preview.
imageAsTeX.zip (7.1 KB)

Cheers,
Nate

Yes your file has the borders with preview also. Attached the files I used:
tex.tar (14.5 KB)

Ok, now I’m totally confused. When I compile your version unedited with pdflatex on Ubuntu, the boxes don’t show up at all. I did a diff of yours and mine, which found (among lots of small numerical differences)

151,153c151,153 < \draw [pattern=crosshatch, draw opacity=0, pattern color=c, fill opacity=0.5] (3.33333,3.25651) rectangle (6,5.86172); < \draw [pattern=crosshatch, draw opacity=0, pattern color=c, fill opacity=0.5] (8.66667,8.46693) rectangle (11.3333,11.0721); < \draw [pattern=crosshatch, draw opacity=0, pattern color=c, fill opacity=0.5] (14,13.6774) rectangle (16.6667,16.2826);

> \draw [pattern=crosshatch, pattern color=c, fill opacity=0.5] (3.33333,3.25301) rectangle (6,5.85542);
> \draw [pattern=crosshatch, pattern color=c, fill opacity=0.5] (8.66667,8.45783) rectangle (11.3333,11.0602);
> \draw [pattern=crosshatch, pattern color=c, fill opacity=0.5] (14,13.6627) rectangle (16.6667,16.2651);

(yours are the first three lines). When I set your draw opacity nonzero, the points show up – with the black boxes around them.

This is really bizarre. Our ROOT code looks the same to my eye, so I don’t understand why the draw opacity is different, and I also don’t understand why my version of pdflatex interprets that to mean the boxes should be invisible while yours draws them fully opaque anyway.

Here are the versions of my various tools:
ROOT 6.06/01
pdflatex version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian)
standalone v1.2
pgf v3.0.1a (rcs-revision 1.15)
tikz v3.0.1a (rcs-revision 1.151)

I am using:

ROOT 6.09/03
pdfTeX 3.1415926-2.4-1.40.13 (TeX Live 2012)

I compiled yours again on the SLC6 machine, which is using pdflatex version 3.141592-1.40.3 (Web2C 7.5.6), which is older than yours. It behaved the same as on Ubuntu, so I guess that’s not the difference.

I tried once again with the file sent you. I am doing:

$root latexframe.C root [0] Processing latexframe.C... Info in <TCanvas::Print>: pdf file imageAsPDF.pdf has been created Info in <TCanvas::Print>: TeX file c.tex has been created root [1] .q$ ls -lrt
total 104
-rw-r--r--@ 1 couet  staff    347 May  3 13:29 latexframe.C
-rw-r--r--@ 1 couet  staff    178 May  3 13:34 textdumpc.tex
-rw-r--r--  1 couet  staff  14848 May  3 14:28 tex.tar
-rw-r--r--  1 couet  staff  13465 May  3 15:43 imageAsPDF.pdf
-rw-r--r--  1 couet  staff   8970 May  3 15:43 c.tex
$pdflatex textdumpc.tex This is pdfTeX, Version 3.1415926-2.4-1.40.13 (TeX Live 2012) [...]$ open textdumpc.pdf


I just tried the script you sent me two more ways: with ROOT 6.08/06 on the Ubuntu machine and with ROOT 6.06/01 on the SLC6 machine.

The newer version of ROOT produced exactly the .tex you gave me except for numerical differences, and the result when I compiled it was the same: the boxes were fully transparent because their draw opacity was again set to 0. When I changed the draw opacity by hand, the boxes appeared with borders as before. The older version of ROOT produced the same result as my python script: visible boxes with borders with no editing.

So I guess something changed between those ROOT versions that made it start adding draw opacity=0 to the filled objects?

The mystery of why the boxes with draw opacity=0 are in fact transparent for me but not you remains.

You may have different versions of pgf?

A latex document that outputs the pgf version.

\documentclass{minimal}
\usepackage{tikz}
\listfiles
\begin{document}

My pgf version is: \pgfversion

\end{document}


The history of changes in TeX output is here:

I night be that one of the latest explain why it works for me and not for you.

This is the commit where draw opacity=0 was added: https://github.com/root-project/root/commit/6d12fc431d7e66a6062c35b3bfc8b675fd2ad77b. Which is a result of the bug report: https://sft.its.cern.ch/jira/browse/ROOT-8206

@ksmith beat me to it but, I see the draw opacity change here, and indeed the comment says the point was to get rid of an unwanted line on the pattern fill area border! No idea why that affects the whole shape for me but just the border for you. What versions of pgf and tikz are you using?

Be aware that there are multiple opacity flags:

• opacity - Sets both the draw and fill opacity below.
• draw opacity - Sets the opacity of paths.
• fill opacity - Set the opacity for fills as well as text.
• text opacity - Sets the opacity for text overriding the fill opacity.

I believe that the correct option instead of draw opacity=0 should have been draw=none.

@nwoods the question is : Do you have the root version containing the fixes. It seems I fixed the border and transparency issue in the post @ksmith pointed. (sorry to not have looked closely myself I am in something else needing all my brain).

Looks like @nwoods was using 6.08.06 and the “fix” was in 6.08.00:

What I still don’t understand is why draw opacity=0 seems to make the fills transparent for me too. It seems likely that when I try on a newer ROOT, they will still be gone unless I edit the .tex file and I won’t have gained anything. It’s entirely possible this isn’t a ROOT issue at all; I’m not sufficiently fluent in pgf/tikz to debug much further.
Did you try draw=none instead of draw opacity=0?
Yes, and it works. So does my current solution, which is to change \draw to \path. Either way I have to tinker with the .tex file ROOT gives me, but that’s not so bad. Python regex is easy, and it only has to work for a few months until I graduate ;). Someone who knows these packages better than I do will have to comment on a more robust solution (or if one is even needed – it’s totally possible that the disappearing fills are due to a quirk unique to my setup).
I would propose that TTexDump be modified to use draw=none then. It appears to be more robust.