Re: PDFLATEXSTANDALONE output is not available

[Ben Abbott]

> On Jul 14, 2015, at 4:12 AM, Daniel J Sebald <address@hidden> wrote:
> 
> On 07/13/2015 06:40 PM, Ben Abbott wrote:
>> 
>>> On Jul 13, 2015, at 11:09 AM, Rik <address@hidden
>>> <mailto:address@hidden>> wrote:
>>> 
>>> >> On Jul 13, 2015, at 12:42 AM, Daniel J Sebald
>>> <address@hidden> wrote:
>>> >>
>>> >> On 07/12/2015 07:38 PM, Ben Abbott wrote:
>>> >>>> On Jul 12, 2015, at 5:59 PM, John W. Eaton<address@hidden> wrote:
>>> >>>>
>>> >>>> After recent changes, I'm seeing this error:
>>> >>>>
>>> >>>> error: print.m: PDFLATEXSTANDALONE output is not available for the
>>> Gnuplot graphics toolkit
>>> >>>> error: called from
>>> >>>> __gnuplot_print__ at line 147 column 7
>>> >>>> print at line 429 column 14
>>> >>>> plotimages at line 104 column 7
>>> >>>>
>>> >>>> Is it just me? Am I missing something? I have gnuplot version 4.6
>>> patchlevel 6 on a Debian system.
>>> >>>>
>>> >>>> jwe
>>> >>> For gnuplot 4.6 the terminals which support “standalone” are ...
>>> >>>
>>> >>> cairolatex
>>> >>> context
>>> >>> epslatex
>>> >>> pslatex
>>> >>>
>>> >>> The standalone option for opengl toolkits support is based upon the
>>> function latex_standalone() in print.m. I recall that I had intended
>>> to use this for -dpdflatexstandalone when using gnuplot. Perhaps I
>>> overlooked implementing the functionality or perhaps it was
>>> inadvertently changed? (easy to miss that the pdfstandalone is not
>>> supported by gnuplot).
>>> >> Because gnuplot has such a wide variety of terminals to use, I guess
>>> I would prefer to use the gnuplot terminals to match as closely as
>>> possible the various Octave outputs, and if there is one missing then
>>> not try to substitute. Just let the user figure out how to handle the
>>> output format, e.g., epslatex instead. Nonetheless, I think
>>> pdflatexstandalone can be achieved in some way with the cairolatex
>>> terminal:
>>> >>
>>> >> cairolatex
>>> >>
>>> >> The cairolatex terminal device generates encapsulated PostScript
>>> (*.eps) or PDF output using the cairo and pango support libraries and
>>> uses LaTeX for text output using the same routines as the epslatex
>>> terminal.
>>> >>
>>> >> Syntax:
>>> >>
>>> >> set terminal cairolatex
>>> >> {eps | pdf}
>>> >> {standalone | input}
>>> >> {blacktext | colortext | colourtext}
>>> >> {header <header> | noheader}
>>> >> {mono|color}
>>> >> {{no}transparent} {{no}crop} {background <rgbcolor>}
>>> >> {font <font>} {fontscale <scale>}
>>> >> {linewidth <lw>} {rounded|butt|square} {dashlength <dl>}
>>> >> {size <XX>{unit},<YY>{unit}}
>>> >>
>>> >> I've never tried it, but I'm guessing that the pdflatexstandalone
>>> implies the destination is the pdflatex program and not common latex.
>>> If it doesn't create exactly what is needed, then I can go to the
>>> gnuplot discussion list and see if it makes sense to add a pdflatex
>>> terminal.
>>> >>
>>> >> Dan >From gnuplot, the following commands produced a tex-file with
>>> the expected filename.tex and filename-inc.pdf files. > > set terminal
>>> cairolatex pdf standalone > set output “filename.tex” > plot sin(x) >
>>> >Then running “pdflatex fiilename.tex” (bash shell) produced the
>>> expected filename.pdf file. > >Ben
>>> 
>>> That seems like a surprisingly simple fix. Could you or someone else
>>> make a changeset to implement that in __gnuplot_print__.m? It seems
>>> like one just needs to add a case statement for 'pdflatexstandalone'
>>> which does what you have done.
>>> 
>>> —Rik
>> 
>> I’m unable to build Octave due to incompabilities between Apple’s
>> Yosemite clang compiler and some of Octave’s code. Perhaps someone else
>> can take this on. It looks to me like it can be added to the case below.
>> 
>> - case {"epslatex", "pslatex", "pstex", "epslatexstandalone"}
>> + case {"epslatex", "pslatex", "pstex", "epslatexstandalone",
>> "pdflatex", "pdflatexstandalone"}
>> 
>> This case will need to include …
>> 
>> if (strfind (opts.devopt, "pdflatex"))
>> opts.devopt = strrep (opts.devopt, "pdflatex", "cairolatex pdf");
>> endif
>> 
>> … and maybe some additional changes I haven’t anticipated.
>> 
>> Ben
> 
> I was going to add this to the changeset attached here:
> 
> https://savannah.gnu.org/bugs/?44187
> 
> but I then noticed that I had already added an implementation of pdflatex and 
> pdflatexstandalone, but maybe in a slightly different way.  The output 
> compiles under pdflatex.  There is a demo ("demo print;") which should speed 
> testing, but list dialogs no longer seem to work. (Also, I'm seeing 
> segmentation faults when the documentation build is attempted.)
> 
> Dan

Dan,

I’d encourage the obvious. And suggest that the patch be split into smaller 
patches.

Is my observation correct that the changes to each m-file can be applied 
independently?

Ben

p.s. I’ll also respond on the tracker.