bugGNU Octave - Bugs: bug #53861, print -dtikzstandalone is not a...

 
 

bug #53861: print -dtikzstandalone is not a recognized print device

Submitter:  Tatsuro MATSUOKA <tmacchant>
Submitted:  Mon 07 May 2018 11:20:55 PM UTC
   
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Confirmed Assigned to:  None
Originator Name:  Tatsuro MATSUOKA Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 09 May 2018 02:21:46 AM UTC, comment #11: 

I missed the file again.  (Because I hit Preview first.)

(file #44129)

Dan Sebald <sebald>
Wed 09 May 2018 02:20:55 AM UTC, comment #10: 

I forget the diff file (attached).  Here's what Octave prints with the diff file:


>> graphics_toolkit qt
>> plot(1:50)
>> print -dtikzstandalone test5
ans = tikzstandalone
ans = test5.tikz
error: print.m: error opening file 'test5.tex'
error: called from
    print>latex_standalone at line 815 column 5
    __opengl_print__ at line 166 column 5
    print at line 561 column 14
>>


See how the extra annotation displays the "tikzstandalone" and "test5.tikz".  So the function pointed to by opts.latex_standalone should be attempt to open "test5.tikz", not "test5.tex"--whether it is done by case statements or a separate routine.

Dan Sebald <sebald>
Wed 09 May 2018 02:17:02 AM UTC, comment #9: 

Ben, I don't think this should be too difficult.  I'm attaching a diff file which is pretty much the same as the first changeset file but I added a couple lines that will print out the name and device options inside the

function latex_standalone (opts)

of print.m.  So, without any changes other than the few in the first changeset file, it looks as though the information one needs is already present in the latex_standalone routine.  (BTW, GL2PS uses a "pgf" file while gnuplot uses a "tikz" file, so obviously there is going to be some difference in the included package files.  Hopefully Tatsuro can tell us what the difference should be...and should this be a .pgf file rather than a .tikz file?)

Anyway, strategically this seems a simple matter of either adding some case statements to latex_standalone() to address when opts.devopt is "tikzstandalone" as opposed to the other three similar names.  OR, another approach would be to recognize in the print.m routine that tikz is the desired output format and do something like


  opts.pstoedit_cmd = @pstoedit;
  opts.fig2dev_cmd = @fig2dev;
  if (TIKZISOUTPUTFORMAT)
    opts.latex_standalone = @pgf_standalone;
  else
    opts.latex_standalone = @latex_standalone;
  endif
  opts.lpr_cmd = @lpr;
  opts.epstool_cmd = @epstool;


The question is, Is tikz standalone format close to the extra commands of latex standalone format?  Or are they different enough that it makes more sense to have a separate pgf_standalone()?  (That's "pgf_standalone", not "pdf_standalone".)  We don't want the latex_standalone() routine to get too cluttered.

Dan Sebald <sebald>
Wed 09 May 2018 12:27:31 AM UTC, comment #8: 

Dan, did you experiment with OpenGL to see if the tex-file wrapper for the tikzstandalone would work with current GL2PS PGF output? I tried 5-6 yrs back and it did not, but the problem may now be fixed.

Ben Abbott <bpabbott>
Group Member
Tue 08 May 2018 11:17:47 PM UTC, comment #7: 

Actually, that's not what the issue is.  The error is happening prior to that in the _print_parse_opts_.m file.  Attached is a simple patch that appears to allow tikzstandalone for gnuplot toolkit while creating a mile error for qt and FLTK (i.e., "GL2PS output").  We must have only tested "tikz" and not "tikzstandalone".  The difference between the two is more TeX-specific info at the top of the file and a last line that ends the TeX commands.

(file #44128)

Dan Sebald <sebald>
Tue 08 May 2018 09:52:29 PM UTC, comment #6: 

I'm not sure what happened.  I do remember a lot of work around this and I thought we put almost all gnuplot output formats in somehow (noting those for which gnuplot was the only support).  I suspect what had happened is the original changeset was something more broad:

https://savannah.gnu.org/bugs/download.php?file_id=34455

and what made it into the dev branch was a subset of that patch.  It could be that Tatsuro and I indicated the changeset works for us but we didn't try the one that actually made it into the source code.

In fact, I can sort of see what the issue is.  Here's what made it into the source code (20968 (123da81b9176) Add support for the standalone option for the gnuplot tikz terminal.):


@@ -99,9 +99,12 @@ function opts = __gnuplot_print__ (opts)
       endif
       local_drawnow ([term " " gp_opts],
                      [name "." suffix], opts);
-    case "tikz"
+    case {"tikz", "tikzstandalone"}
+      if (strfind (opts.devopt, "standalone"))
+        gp_opts = sprintf ("standalone %s", gp_opts);
+      endif
       if (__gnuplot_has_terminal__ ("tikz"))
-        local_drawnow (["lua tikz " gp_opts], opts.name, opts);
+        local_drawnow (["tikz " gp_opts], opts.name, opts);
       else
         error (sprintf ("print:no%soutput", opts.devopt),
                "print.m: '%s' output is not available for gnuplot-%s",


which uses ["tikz" gp_opts].  There no "standalone" in there.  Whereas, what I placed in the original candidate was


-    case "tikz"
+    case {"lua", "tikz", "tikzstandalone"}
+      if (strcmp (opts.devopt, "lua"))
+        ## Replace "lua tikz" with just "tikz"
+        term = "tikz";
+        gp_opts = strrep (gp_opts, "tikz", "");
+      else
+        term = opts.devopt;
+      endif
       if (__gnuplot_has_terminal__ ("tikz"))
-        local_drawnow (["lua tikz " gp_opts], opts.name, opts);
+        local_drawnow ([strrep(term,'standalone',' standalone') ' ' gp_opts], opts.name, opts);
       else
         error (sprintf ("print:no%soutput", opts.devopt),
                "print.m: '%s' output is not available for gnuplot-%s",


i.e., [strrep(term,'standalone',' standalone') ' ' gp_opts], which retains the "standalone" but puts a space in there so that "tikzstandalone" becomes "tikz standalone" (which gnuplot understands).

I actually thought the "demo print" within the original changeset candidate was something useful.  Not only was it a good way of testing the output for all the various formats, regardless of toolkit, it was also a nice way of explaining to the user how to use the output outside of Octave.  I.e., "Octave produced this output file, now how do I process it?"...just look at the demo code.

Dan Sebald <sebald>
Tue 08 May 2018 06:35:57 PM UTC, comment #5: 

I can't find a version of Octave where the tikzstandalone option has ever worked, despite the documentation for it being added in version 4.2:

https://hg.savannah.gnu.org/hgweb/octave/rev/123da81b9176

That change mentions bug #44187, which is marked as closed, but is a very wide ranging thread, so maybe something was missed.

In bug #49003, it looks like you and Dan were able to test tikzstandalone somehow, but it doesn't look to me like it was a recognized option in the 4.2 release.

This option should be restored or completed for Octave 5 or the docs updated if it won't be supported.

Mike Miller <mtmiller>
Group Member
Tue 08 May 2018 10:44:17 AM UTC, comment #4: 

I have execute the same test on dev. branch
(5.0.0 HG-ID 8cac064e6623) .

The same error appears if I try to use tikzstandalone print device.

I have forgotten to copy and paste Ben's comment in the Octave-ML.

*********************************************
I expect I wrote the original support for tikzstandalone. The approach was to produce both a tex-file and a tikz-file. The tikz-file came from gnuplot. Gl2ps was able to generate a pgf-file, but that never worked for me. Since then there has been changes to the standalone output and the gnuplot backend. During those changes, the tikzstandalone must have been broken/disabled.

There is a function print.m:latex_standalone() whos handle is passed into _opengl_print_.m and _gnuplot_print_.m as part of the “opts” structure. The approach that was intended to be used for tkzstandalone with gnuplot is essentially equivelent to what is implemented for opengl (I haven’t tested tikzstandalone with opengl, but I expect it works).
*********************************************

Tatsuro MATSUOKA <tmacchant>
Tue 08 May 2018 10:38:57 AM UTC, comment #3: 

This topic is discussed in octave-maintainers ML.
http://octave.1599824.n4.nabble.com/unknown-device-tikzstandalone-td4687923.html

(unknown device tikzstandalone)

On octave 4.4.0 windows


>> gnuplot_binary C:\Programs\gp523-64\bin\gnuplot
>> graphics_toolkit gnuplot
>> fplot ("[cos(x), sin(x)]", [0, 2*pi])
>> print("test.tikz", "-dtikzstandalone")
error: print: unknown device tikzstandalone
error: called from
    __print_parse_opts__ at line 259 column 5
    print at line 322 column 8

>> print("test.tikz", "-dtikz")
## works for tikz but not tikzstandalone


The same behavior appears 4.4.0 on Ubuntu 16.04 (bbuild myself).

I have not tested on dev. branch.
I will do to today afternoon in Japan.

tikzstandalone print device is described in the manual

https://octave.org/doc/interpreter/Printing-and-Saving-Plots.html#Printing-and-Saving-Plots

In the maintainers ML, Ben made a reply that told us what was done in the
past. tikzstandalone print device has not been implemented although it has
been described in the manual.

I request that next release of octave implements this feature.

Tatsuro MATSUOKA <tmacchant>
Tue 08 May 2018 10:37:35 AM UTC, comment #2: 

In the previous post, I have made a mistake  so I repost.


>> gnuplot_binary C:\Programs\gp523-64\bin\gnuplot
>> graphics_toolkit gnuplot
>> fplot ("[cos(x), sin(x)]", [0, 2*pi])
>> print("test.tikz", "-dtikzstandalone")
error: print: unknown device tikzstandalone
error: called from
    __print_parse_opts__ at line 259 column 5
    print at line 322 column 8

>> print("test.tikz", "-dtikz")
## works for tikz but not tikzstandalone
-verbatim

The same behavior appears 4.4.0 on Ubuntu 16.04 (bbuild myself).

I have not tested on dev. branch.
I will do to today afternoon in Japan.

tikzstandalone print device is described in the manual

https://octave.org/doc/interpreter/Printing-and-Saving-Plots.html#Printing-and-Saving-Plots

In the maintainers ML, Ben made a reply that told us what was done in the
past. tikzstandalone print device has not been implemented although it has
been described in the manual.

I request that next release of octave implements this feature.

Tatsuro MATSUOKA <tmacchant>
Tue 08 May 2018 10:36:53 AM UTC, comment #1: 

In the previous post, I have made a mistake  so I repost.


>> gnuplot_binary C:\Programs\gp523-64\bin\gnuplot
>> graphics_toolkit gnuplot
>> fplot ("[cos(x), sin(x)]", [0, 2*pi])
>> print("test.tikz", "-dtikzstandalone")
error: print: unknown device tikzstandalone
error: called from
    __print_parse_opts__ at line 259 column 5
    print at line 322 column 8

>> print("test.tikz", "-dtikz")
## works for tikz but not tikzstandalone
-verbatim

The same behavior appears 4.4.0 on Ubuntu 16.04 (bbuild myself).

I have not tested on dev. branch.
I will do to today afternoon in Japan.

tikzstandalone print device is described in the manual

https://octave.org/doc/interpreter/Printing-and-Saving-Plots.html#Printing-and-Saving-Plots

In the maintainers ML, Ben made a reply that told us what was done in the
past. tikzstandalone print device has not been implemented although it has
been described in the manual.

I request that next release of octave implements this feature.

Tatsuro MATSUOKA <tmacchant>
Mon 07 May 2018 11:20:55 PM UTC, original submission:  

This topic is discussed in octave-maintainers ML.
http://octave.1599824.n4.nabble.com/unknown-device-tikzstandalone-td4687923.html

(unknown device tikzstandalone)

On octave 4.4.0 windows


>> gnuplot_binary C:\Programs\gp523-64\bin\gnuplot
>> graphics_toolkit gnuplot
>> fplot ("[cos(x), sin(x)]", [0, 2*pi])
>> print("test.tikz", "-dtikzstandalone")
error: print: unknown device tikzstandalone
error: called from
    __print_parse_opts__ at line 259 column 5
    print at line 322 column 8

>> print("test.tikz", "-dtikz")
## works for tikz but not tikzstandalone
-verbatim

The same behavior appears 4.4.0 on Ubuntu 16.04 (bbuild myself).

I have not tested on dev. branch.
I will do to today afternoon in Japan.

tikzstandalone print device is described in the manual

https://octave.org/doc/interpreter/Printing-and-Saving-Plots.html#Printing-and-Saving-Plots

In the maintainers ML, Ben made a reply that told us what was done in the past. tikzstandalone print device has not been implemented although it has been described in the manual.

I request that next release of octave implements this feature.

Tatsuro MATSUOKA <tmacchant>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by tmacchant (Submitted the item)
  • -email is unavailable- added by tmacchant
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-05-09 sebald Attached File- Added octave-gnuplot_tikzstandalone-djs2018may08-ANNOTATION.diff, #44129
    2018-05-08 sebald Attached File- Added octave-gnuplot_tikzstandalone-djs2018may08.patch, #44128
    2018-05-08 mtmiller CategoryPlotting Plotting with gnuplot
        StatusNone Confirmed
        Releaseother dev
        SummaryFeature Request of implementation tikzstandalone print device print -dtikzstandalone is not a recognized print device
    2018-05-07 tmacchant Carbon-Copy- Added ben <bpabbott@mac.com>

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code