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.
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:
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
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)
> \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 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.
@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?
@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).
I’ll see about using a newer ROOT version on the server where I have to actually make these plots. I don’t control the machine but I’m sure I can figure something out.
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.
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).
