#522 Lua/TikZ enhancements and bug fixes
Attached is a patch for the Lua/TikZ-terminal, that includes some enhancements as well as bug fixes.
Here is a brief list of changes to the gnuplot CVS version:
* support for ConTeXt and plain TeX
* removed dependencies for LaTeX packages other than TikZ
* needs TikZ Version >= 2.0
* better support for saving terminal options with gnuplot 'save' command
* fixed "overflow" on negative coordinates that are outside of the crop box
* merged all recent patches from murphy-md and Ethan
In addition I updated part of the documentation in the /term/lua/ directory and would like to suggest
to remove the obsolete INSTALL file and maybe also the outdated Changelog file.
After patching the new style and help files have to be generated. To generate the style files and wrapper
for the various TeX flavors just enter
lua gnuplot-tikz.lua style
on the command line. The files generated should be
t-gnuplot-lua-tikz.tex (Context wrapper)
gnuplot-lua-tikz.tex (plain TeX wrapper)
gnuplot-lua-tikz.sty (LaTeX wrapper)
gnuplot-lua-tikz-common.tex (common definitions)
and can be copied to the appropriate places.
lua gnuplot-tikz.lua help
prints the terminal help on stdout and
lua gnuplot-tikz.lua termhelp > gnuplot-tikz.help
generates the version to be included in gnuplot.
One known issue is an incompatibility/bug of the preview package and TikZ that leads to erroneous files
on dvi and postscript output using the terminal's standalone mode. PDF output works flawlessly.
I did not do extensive tests with plain TeX and ConTeXt but at least Mojca told me that for her using ConTeXt everything works fine so far...
-Peter
OK, thanks (and thanks in particular for the instructions on how to regenerate style/doc files).
Question:
When I run
set term tikz standalone
set output "transparent.tex"
load "transparent.dem"
and then process the output with
pdflatex transparent
it chokes on the σ (sigma) characters:
Preview: Fontsize 10pt
Preview: PDFoutput 1
(/usr/share/texmf-texlive/tex/latex/ucs/data/uni-3.def)
! Undefined control sequence.
\u-default-963 #1->\textsigma
l.58 ... node left] at (2.112,7.183) {μ = 0.5 σ
= 0.5};
? q
But it handles μ (mu) correctly. Any idea what's up with that?
Where is \textsigma supposed to be defined, and why is that a different place than \textmu?
Sorry no idea. Although \textsigma is defined in ucsencs.def the error still occurs even if it is loaded by the ucs package (part of the unicode support).
Regarding \textmu, this one and \textohm are the only Greek letters that are available by default via the textcomp package (see e.g. encguide.pdf).
Anyhow, a quick workaround is to define \textsigma in the preamble e.g. via
set term tikz standalone preamble '\usepackage{upgreek}\ProvideTextCommandDefault{\textsigma}{\ensuremath\upsigma}'
Another option is to use xetex or luatex and an opentype font that comes with the Greek alphabet.
I guess all terminals that let TeX do the font rendering encounter this problem.
After full installation (previous tests were run with old latex style files) I run into a problem when running output through pdflatex:
(/usr/share/texmf-texlive/tex/generic/pgf/libraries/pgflibraryplotmarks.code.tex)) (/usr/local/share/texmf/tex/latex/gnuplot/gnuplot-lua-tikz-common.tex
! Undefined control sequence.
l.150 \tikzset
{rgb color/.code={\pgfutil@definecolor{.}{rgb}{#1}\tikzset{col...
Although that particular error message refers to a color operation, the *.log file shows many more errors involving tikzset. I think it is not being found at all.
Reverting to the old gnuplot-lua-tikz.sty makes everything work again.
Where is tikzset supposed to be defined or found?
Hmm. It took me a while to figure out how to find a version number for tikz.
Now I see that I have v1.18, whle your summary says "needs TikZ Version >= 2.0".
So that may explain the problem.
I know little about TeX installation other than to select it as an optional package from my linux distro. Can you provide simple instructions for how/what would need to be updated? If current linux distros (I have Mandriva 2010.2) do not have recent enough tikz, that seems to me a problem. I would rather have a tikz terminal that is backwards compatible, or at least doesn't require bleeding-edge TeX packages.
Ethan - if you have TeX Live 2010, all you need to do is to say
sudo tlmgr update --self
sudo tlmgr update pgf (or --all)
But I don't know what version of TeX distribution you are using (it might be unlikely that it's the latest one).
Here are simple istructions to install the latest TeX Live 2010:
export TL=~/tex/texlive
mkdir -p $TL
# tex live
cd $TL
wget http://mirror.ctan.org/systems/texlive/tlnet/install-tl-unx.tar.gz
tar xvzf install-tl-unx.tar.gz
cd install-tl-<let_it_autocomplete>
./install-tl
D
1 (to change texdir to some local folder instead of installing it system-wide)
~/tex/texlive
(optionally you may change 5-7 if you want)
R (return to main menu)
S (installation scheme)
(up to you, if you want it fast, select some "lightwheight" scheme with latex;
you can alway install pgf later with "tlmgr install pgf")
R (return to main menu)
(you may remove everything under O if you want to spare space)
I (start installation to hard disk)
# when you want to use it (assuming you are using 64-bit linux)
export PATH=$TL/bin/x86_64-linux:$PATH
Peter - which exactly are the features of pgf >= 2.0 that are needed? (I only need to warn you that ConTeXt support is broken in 2.1, but that's something that is being worked on since the last year, but I hope that I will convince the developer to fix it and I don't consider it a problem.)
One thing that you need to keep in mind is that by the time gnuplot 2.6 will be released TeX Live 2011 might be out already, so linux distributions might adapt TeX Live 2010 before they adapt gnuplot 2.6 and you don't want to ship gnuplot that might possibly break with the latest version of pgf and you want it to support some "bleeding edge features" of gnuplot as well.
Alternative is to fetch
http://mirror.ctan.org/systems/texlive/tlnet/archive/pgf.tar.xz
and unpack it to $TEXMFHOME or for example /usr/local/texlive/texmf-local (if you would have tex live 2009 installed under standard location).
Thanks, Mojca
I downloaded the pgf package from CTAN and used it to replace the equivalent directory trees in my current TeX installation. That gets me a little bit further. Now the failure mode is:
! Undefined control sequence.
<argument> \gprgb
{133}{545}{133}
l.60 ...106)--(1.928,7.260)--(1.564,7.260)--cycle;
The control sequence at the end of the top line
of your error message was never \def'ed. If you have
misspelled it (e.g., `\hobx'), type `I' and the correct
spelling (e.g., `I\hbox'). Otherwise just continue,
and I'll forget about whatever was undefined.
! Package xcolor Error: Undefined color `{133}{545}{133}'.
See the xcolor package documentation for explanation.
The CTAN page lists version number requirements for other TeX packages, including xcolor, but so far as I can tell I am more current than required. Where else should I look?
I don't seem to have any tool name tlmgr.
As to linux distributions adopting Texlive 2010 before we are ready with gnuplot 2.6 - I wouldn't count on it :-/ Current Mandriva is still packaging texlive-2007, and Suse seems to have texlive-2008.
Are you sure that you don't have any leftovers somewhere? Did you put the latest version of gnuplot-tikz.lua to the required place? The latest version of terminal has no trace of \gprgb command anywhere (or at least I don't see it).
Out of pure curiosity - what versions of gnuplot do these linux distributions contain? (Fink on Mac OS X doesn't even provide TeX Live, they are still on tetex.)
There is one more thing that you have to keep in mind. If you fetched a non-TDS compliant version of pgf (I don't know that) or if you have put the package into main tree instead of the local tree, it might happen that you have two versions of the file under the same name in your TeX tree and then kpsewhich takes the one that comes alphabetically first (or whatever other semi-random criteria it uses). So unless you uninstall the old package, you cannot be 100% sure that kpathsea doesn't use some files from the old package. You need to check the log.
I still think that the problem is most probably an old version of lua file somewhere, but the problem mentioned above is not impossible to happen.
pgf/TikZ 2.0 is out for almost 2 years now, and I am quite sure it was already part of TeXLive 2008. Sad that Mandriva did not keep up with the development.
In addition you can find all pgf/TikZ releases in TDS format also at http://sourceforge.net/projects/pgf/files/pgf/ .
Installation is the same as Mojca described before.
Regarding the backward compatibility, I cannot give you an exact answer now why I decided to use TikZ 2.0 features (I did this too long ago),
but I think the flexibility of parameterized styles made it way more easy to adapt the terminal to work with all common TeX flavors.
Anyhow, the backwards compatibility of the output and the style file is also sacrificed to support the different TeX flavors.
But I am open for new ideas, since I did not regard myself being a TeX wizard ;)
I would like to suggest to keep this TikZ dependence for now and use the patch only for the upcoming gnuplot release or pending for discussion at the moment.
I will prepare a separate bug fix patch for the current 4.4 version then, that addresses the "overflow" error only.
For the ones that are willing to test: I already found a bug myself. After colored pattern fills the text color is not set properly.
And another known "bug" is that pattern fills are not supported by XeTeX.
@Ethan: You can just leave all generated style files and gnuplot-tikz.lua in the same directory where you generate and compile the document.
@Nobody: I have pgf/tikz installations from texlive 2010 and the CVS version in texmf-local without any interferences. I never had any problems.
> I still think that the problem is most probably an old version of lua file
> somewhere, but the problem mentioned above is not impossible to happen.
You win the prize. It was indeed picking up an old version of the lua script.
My fault entirely.
I am still seeing a problem with terminal initialization, but it's clearly a code problem rather than a configuration problem.
gnuplot> set term tikz standalone
Terminal type set to 'tikz'
/usr/local/share/gnuplot/4.5/lua/gnuplot-tikz.lua:1503: attempt to perform arithmetic on field '?' (a nil value)
stack t
If I delete line 1503 and replace the following line with term.flags = 0
rather than term.flags = term_default_flags + term.TERM_CAN_CLIP
it runs with no error. Is that variable name a typo?
There are now additional constants defined in lua.trm (TERM_ALPHA_CHANNEL, TERM_MONOCHROME, ...).
So my guess is that your gnuplot binary is not patched. For a quick test you can have a look into the TeX output file, there should be the comment "... terminal rev. 99 ...".
> my guess is that your gnuplot binary is not patched
Thanks for putting up with my disorderly state of versioning. My normal work-flow has been thrown off by SourceForge being offline, as I can't easily revert to the CVS version without keeping additional local copies, which I seem to have messed up.
Anyhow, it's all working now and looking good.
Note that lua.trm still needs the fix I made before, which you have commented out as:
/* FIXME: added by Ethan, but i think "c_token = num_tokens;" below does virtually the same
while (!END_OF_COMMAND) c_token++;
*/
This iteration is required in order for gnuplot to handle multiple commands on a single input line. E.g.
set term tikz; set output 'plot.tex'; replot; print "done!"
Setting c_token = num_tokens will jump to the end of the current input line and lose all commands after the first 'set term'.
I still think it's unfortunate that it requires a version of pgf that many people do not have yet as part of their standard linux distro. It is true that upgrading directly from CTAN was not hard (once I sorted out my own versioning mess :-) but still it's an extra hurdle for normal users. Well, I guess we can put off worrying about that until we are ready to put the revised terminal in an official release. Perhaps the linux distros will have caught up by then.
I have been testing this slightly modified version of your patch.
If you think it's ready, I will add it to version 4.5 CVS.
slightly modified version proposed for application to 4.5
I uploaded a new patch "lua-tikz-terminal-20110220.diff" that applies against the current 4.5 CVS version.
Compared to the former patch this one should fix the wrong color setting after filled patterns and introduces a few new features suggested by Mojca and Ethan:
* transparent bitmap images are now supported by externalizing the image to a PNG file (depends on pngcairo)
* all bitmap images can be externalized (see option 'externalimages')
* bounding and crop boxes are set to the given canvas size (see also 'clip' option)
* background color can be set via option 'background' (there is a minor issue, see TODO file)
* all texts can now be scaled by a factor (option 'textscale' or 'fontscale')
* reasonable error message on wrong TikZ version
-Peter
new patch replacing lua-tikz-terminal.diff
Added to CVS.
I modified the Makefiles so that all the *.sty and *.tex files are built by "make", but only if lua was found by ./configure. So they are no longer in the cvs repository.
The same should be done for the help file but I couldn't figure out the right dependencies.