[Octave-bug-tracker] [bug #58374] print function creates path not readable by latex

[Rik]

Follow-up Comment #10, bug #58374 (project octave):

For such a small issue, this turns out to be incredibly involved.  The
beginnings are in print.m where a filename is created.  This is then passed to
drawnow() in graphics.cc written in C++.  There are a whole bunch of
intermediate function calls, but for OpenGL toolkits this eventually ends up
in gl2ps-print.cc where the filename is stripped out of the larger pipeline
command.  This is then passed to the external library gl2ps which further
modifies the name by always stripping one exension ('.' + characters).

There isn't actually a path that seems clear to me.  If we use jwe's
suggestion to strip directory portion from the filename and just use the
basename then we get the following benefits:

1) No need to translate '\' to '/' because no path separators are present
2) Works with directories that contain spaces ("My Documents") because, again,
there is no path present.

Cons

1) The pdflatex command has to be run from the directory where the .tex and
-inc file are located.

On the other hand, if we include the path then

Pros

1) Can call binary located anywhere on files located anywhere.  For example
("C:\Program Files\pdflatex\pdflatex.exe C:/My Documents/my_file")

Cons

1) Need to replace '\' with '/' in filenames.
2) Need to wrap entire name in double or single quotes in case there are
spaces in the path.

I guess I have a mild leaning towards the first solution.  Since a program
like pdflatex is outside of Octave, push the responsibility on to the user to
go to the directory where they decided to place the file and then run their
conversion there.

Any thoughts?

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58374>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/