#2613 lua-tikz terminal with standalone does not compile

[Anonymous]

When using the "lua tikz" terminal with the "standalone" option, the resulting tex file does not compile. Running 'pdflatex' or 'lualatex' returns the error:

! Undefined control sequence.
<recently read> \SetUnicodeOption

This can be fixed by editing the file 'term/lua/gnuplot-tikz.lua' and adding the line

.."\\usepackage{ucs}\n"

in the 'docheader' section of 'gfx.format.latex' (see attached patch).

Version: 5.4.6, OS: Arch Linux

Steps to reproduce: Create a gnuplot file 'test.gnuplot' with

set term lua tikz standalone
plot x

and run

gnuplot test.gnuplot > test.tex
pdflatex test.tex

[Ethan Merritt]

What TeX distribution are you using?
In my experience there is no such problem when using pdflatex from texlive, and I know some of the other gnuplot developers are using pdflatex from MiKTeX without problem.

Now it is true that the "standalone" option of the gnuplot latex terminals is oriented toward pdflatex (rather than lualatex or xelatex), but I would have expected a different message from those. For instance, from both xelatex and luatex I get:

Package inputenc Warning: inputenc package ignored with utf8 based engines.

That warning by itself does not prevent it from working. The output pdf file is still produced correctly, with the caveat that at least on my system the default font used by luatex and xelatex has a very limited set of unicode glyphs. To make it work in general with xelatex or lualatex I need to add something like

\usepackage{fontspec}
\setmainfont{Liberation Serif}

But those options are not accepted by pdflatex, so it's kind of a losing battle.
Anyhow, I suppose it wouldn't hurt to add the \usepackage{ucs} in the pdflatex case, but I'd like to know what TeX setup or distro it is fixing.

[Tatsuro MATSUOKA]

other gnuplot developers are using pdflatex from MiKTeX without problem.

I have abandon to use MiKTeX for gnuplot document processing for some errors occurr (I forgot what kind of errors I met.) Now I am using TeXLive on the Cygwin and Msys2 for gnuplot documetation.

[Ian Jauslin]

I am using pdflatex on TexLive (I just tried it out with lualatex, just to see if it worked). My TeXLive version is 2023.66539. My version of inputenc is 2021/02/14 v1.3d and my version of ucs is 2022/08/07 v2.3.

If I create a test tex file with the code

\documentclass{article}

\usepackage[utf8x]{inputenc}
\SetUnicodeOption{mathletters}

\begin{document}
test
\end{document}

Pdflatex fails with the error message

! Undefined control sequence.
<recently read> \SetUnicodeOption

It succeeds if I use

\documentclass{article}

\usepackage[utf8x]{inputenc}
\usepackage{ucs}
\SetUnicodeOption{mathletters}

\begin{document}
test
\end{document}

This seems correct to me, as the '\SetUnicodeOption' is defined in 'ucs.sty', and I do not see a line in inputenc that imports ucs (or, in fact, even mentions the string 'ucs'). So I do not see how '\SetUnicodeOption' can be used without importing 'ucs'.

[Ethan Merritt]

Thanks.

It must be a change between TeXLive2022 and TeXLive2023 (which I don't have yet). I see in the current CTAN documentation for ucs.sty that there was a major revision in Aug 2022 to accommodate changes in other utf8x packages. I have not found any comprehensive summary of what this means in practice, but your report and patch is helpful.

Probably set term tikz standalone should have some provision, or at least some documentation, for use with xelatex and lualatex. Not my area of expertise!

[Ian Jauslin]

I suspect that you're right, it must be related to the upgrade to 2023. Thanks!

[Tatsuro MATSUOKA]

Is this related to the bug #2608 ? Upgradig TeXLive to 2023 induced failure in compling the gnuplot documents using pdflatex. Chage to use of the lualatex gives successful results.

[Ethan Merritt]

I'm reopening this one because it turns out the changes from replacing texlive2022 with texlive2023 open up a whole can of worms. I downloaded TeXLive 2023 last week for testing. Here's a summary of what I have found out so far.

---

problems with texlive 2023

Neither pdflatex or luatex/xetex works as-is to produce pdf documentation from the existing gnuplot.doc or with the gnupot latex terminals "standalone" option.

pdflatex

• for gnuplot.doc it used to be sufficent (texlive 2022) to have
  \usepackage[utf8x]{inputenc}
• tikz standalone output added
  \SetUnicodeOption{mathletters}
• The equivalent in texlive 2023 now requires (Bugs #2608 2613)
  \usepackage[utf8x]{inputenc}
  \usepackage{ucs}
  \SetUnicodeOption{mathletters}
  but that whole set of choices is now disrecommended because utf8 is now the default, and anyhow those commands are not sufficient to pick up all the unicode characters needed
• it sort of works to replace all of those lines with
  \usepackage{textalpha,alphabeta}
  but that also fails to pick up all the unicode characters needed
• The infinity character in particular can be hacked in by adding
  \makeatletter
  \@namedef{u8:\detokenize{∞}}{$\infty$}
  \makeatother
• That still fails to supply other characters that used to work.
  E.g. from gnuplor.doc in the section for "with labels"
  symbol(z) = "∙□+⊙♠♣♡♢"[int(z):int(z)]
  How/where did texlive 2022 find these?

luatex/xetex

• Does not work in the default setup
• As I understand it this is mostly just an issue that the default font for lualatex/xelatex doesn't cover much of unicode.
• replace all the lines mentioned above for pdflatex with
  \usepackage{fontspec}
  \setmainfont{Times New Roman}
  \setmonofont{Liberation Mono}[Scale = 0.8]
• Other fonts that at least provide all the characters used by gnuplot.doc: Liberation Serif, Quivira, Arial Unicode MS, Arno Pro, Asana Math
• This approach works for producing the user manual from gnuplot.doc, but t is not clear to me if any of those fonts are "standard" enough to have the gnuplot terminal output require it specifically in standalone mode.
• TeX Gyre Pagella is also a font option, and comes with texlive, though it was not installed on my system by default. Monospaced TeX Gyre Cursor is not good however.

---

[Ethan Merritt]

2nd Update

All working now as tested here with texlive2023, both pdflatex and luatex
The pdflatex fix was to change order of loaded packages

 \usepackage{hyperref} % must come before ucs/utf8x
 \usepackage{ucs}
 \SetUnicodeOption{mathletters}
 \usepackage[utf8x]{inputenc}  % must come after loading ucs

The problem with luatex is that the default fonts (cm or equivalent) do not provide all the unicode characters used by the documentation. Specifying fonts is easy enough, but I don't know which if any fonts are standard enough to assume they are available. For the documentation I went with

    % These commands are for use with lualatex
    % The default CM fonts are missing many unicode characters
    \usepackage{fontspec}
    \setmainfont{Free Serif}
    \setmonofont{Free Mono}
    \usepackage{unicode-math}

This may be overkill for set term tikz standalone but let's try it.