bugGNU Octave - Bugs: bug #48484, gnuplot: printing figure into file...

 
 

bug #48484: gnuplot: printing figure into file results in mostly black image (Windows)

Submitter:  Hartmut <hardy>
Submitted:  Tue 12 Jul 2016 06:07:38 PM UTC
   
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Invalid / Not an Octave Bug Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.0.3 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 15 Jul 2016 05:53:15 PM UTC, comment #13: 

Yes, I agree: If bug #47527 would be solved, than this issue would also be prevented.

But as conclusion please increase the priority of bug #47527. Now, it is not only about a cosmetic change of an icon appearance in the task bar, any more. But it is about Octave using wrong binaries of gnuplot (and other binaries) if people go and work around this appearance bug. And anyone seriouly using Octave under Windwos will eventually try to integrate the Octave launcher into his normal workflow and use Octave like any other installed Windows software. That's not only a corner case, but this is the expected user behavior, which is dangerously close to making Octave behave wrong.

Hartmut <hardy>
Fri 15 Jul 2016 03:39:57 PM UTC, comment #12: 

See Bug #47527

I believe running the script is probally ok - its registering the shortcut with an AppId, which will require another tool or plugin as nsis doesn't support AppId registration on its own.

John Donoghue <lostbard>
Group Member
Fri 15 Jul 2016 03:36:01 PM UTC, comment #11: 

I think Hartmut's point is that with the launcher running the .vbs script, it doesn't integrate well into the Windows toolbar of running apps, pinned apps, etc (Gnome has something similar). Is there already a bug report about something to allow Octave to be pinned and the icon to show correctly on Windows? I can't remember.

On Gnome we fixed that problem by giving it a hint that launching the program "octave --force-gui" will run something called "octave-gui", so the launcher knows that those are the same thing. I have no idea if Windows has a way to say "I launched this thing, but this other thing running is really the same one" so they look nice on the toolbar.

Anyway, that is a separate issue, looks like this is solved, and maybe a good question to keep in mind to ask other users who have problems with programs that Octave launches. I remember problems coming up before with gnuplot, with g++, maybe others.

Hartmut, I think the consensus has been before that Octave will not change its own PATH variable, a wrapper script or batch file to set up the environment and call Octave is the official way to do that. By calling octave-gui.exe directly, you are taking responsibility for making sure that the system PATH is configured correctly already.

Mike Miller <mtmiller>
Group Member
Fri 15 Jul 2016 02:56:12 PM UTC, comment #10: 

For those using the installer, shortcuts point to octave.vbs, which does the setup of the path to ensure that octave path is first.

John Donoghue <lostbard>
Group Member
Fri 15 Jul 2016 12:05:53 PM UTC, comment #9: 

another idea to solve this:

  • make Octave PRE-pend its own bin directory to the windows PATH variable, always (i.e. not only via the vbs script or a pre-installed shortcut).
Hartmut <hardy>
Fri 15 Jul 2016 12:02:50 PM UTC, comment #8: 

I have done some testing on the PATH environment variable under Windows 7, and what Octave 4.0.3 does to it. (This was done with the Win7 machine where I originally observed this undesired behavior.):

  • There is no user defined variable with the name Path.


  • There is a system wide defined varialbe with the name "Path". It has very many entries, one of them is a path to a different gnuplot binary (from a Python installation), it also has a permanent entry from some older Octave installation bin directory. I will call the content of this variable "STUFF" for now.


  • When I start Octave 4.0.3 by executing octave-gui.exe (that is my normal way to start it, I have a shortcut link in my taskbar.) then the result of getenv("PATH") is the following:



STUFF;
C:\Octave\Octave-4.0.3\bin;
C:\Octave\Octave-4.0.3\notepad++;
C:\Octave\Octave-4.0.3\libexec\octave\4.0.3\site\exec\i686-w64-mingw32;
C:\Octave\Octave-4.0.3\libexec\octave\api-v50+\site\exec\i686-w64-mingw32;
C:\Octave\Octave-4.0.3\libexec\octave\site\exec\i686-w64-mingw32;
C:\Octave\Octave-4.0.3\libexec\octave\4.0.3\exec\i686-w64-mingw32;
C:\Octave\Octave-4.0.3\bin


  • When I start Octave 4.0.3 via the generated desktop links, or via the generated vbs script, then the result of getenv("PATH") is this:



C:\Octave\Octave-4.0.3\bin;
STUFF;
C:\Octave\Octave-4.0.3\bin;
C:\Octave\Octave-4.0.3\notepad++;
C:\Octave\Octave-4.0.3\libexec\octave\4.0.3\site\exec\i686-w64-mingw32;
C:\Octave\Octave-4.0.3\libexec\octave\api-v50+\site\exec\i686-w64-mingw32;
C:\Octave\Octave-4.0.3\libexec\octave\site\exec\i686-w64-mingw32;
C:\Octave\Octave-4.0.3\libexec\octave\4.0.3\exec\i686-w64-mingw32;
C:\Octave\Octave-4.0.3\bin


The integrated gnuplot version of Octave 4.0.3 sits in "C:\Octave\Octave-4.0.3\bin"

Conclusion: Only in my special case of starting Octave via a direct link to the Octave binary, the problem occurs. In all other cases the Octave bin patch (where the Octave version of gnuplot sits) is pre-pended to the path variable, and thus this gnuplot version should be properly used. Everything should be fine if someone uses the generated desktop links or the generated vbs-files. (I can only verify this in a couple of days.)

But: Why do I start Octave the way I do? The two integrated ways of starting Octave canNOT be integrated into the Windows taskbar. All other software programs I start, are started via this task bar, so I needed to find a way to do this for Octave as well.

My ideas to prevent other users to have the same trouble:

  • Generate a vbs-script that also shows the Octave icon during the time it is not running. The current vbs-script will instead show some vbs-icon normally, that only changes to be the Octave icon after clicking on it.
  • Generate some other method (like all other windows programs do) to stick the Octave "start button" to the taskbar or to the start menue, via a right-click menu with the mouse over its entry in the full start menu.


Hartmut <hardy>
Thu 14 Jul 2016 06:49:50 PM UTC, comment #7: 

Thanks. So the only thing not working is that another gnuplot program in the global system PATH has shadowed the one that is delivered with the Octave installer.

Can you tell why or how that is?

My understanding is that Octave on Windows is supposed to prepend its own bin directory to the PATH so that all external programs and utilities that Octave calls out to are found there first. We have had other bug reports from people about other versions of programs being found instead of the ones that the installer provides. If that's the case, I would want to know why that's not working on certain systems and what we can do to make sure it does work. Can you help figure out why it's not working?

How do you run Octave on this machine, in a console window, from a shortcut that you created, from a shortcut that the installer created? Is the shortcut using either of the octave.bat or octave.vbs scripts to launch Octave? What does getenv("PATH") show inside of Octave?

Mike Miller <mtmiller>
Group Member
Thu 14 Jul 2016 06:00:07 PM UTC, comment #6: 

I have done the test proposed by Mike. The results are

  • I have added the generated gp file as attachment. In the second line it says "set terminal postscript enhanced ...", the word "color" is missing here.
  • running the code for testing the gnuplot version results in "4.4.3". This is NOT the gnuplot version (5.0.3) that is shipped with the Octave 4.0.3 release.


Searching for the reason for this I found:

  • On this PC there are several other gnuplot versions installed. One gnuplot version is installed by a Python distribution in the path "C:\Python27\gnuplot\binary\"
  • This "Python-Gnuplot" path is included in the Windows search PATH variable!


Conclusion:
It seems to me that the mxe-octave on Windows does NOT use its own gnuplot installation in the case that a different gnuplot version is installed somewhere else on the same PC, when this other gnuplot installation can be found via the Windows PATH variable.

If this conclusion is correct, we should probably change the way our mxe-octave picks the correct gnuplot binary.

(file #37875)

Hartmut <hardy>
Wed 13 Jul 2016 04:10:02 PM UTC, comment #5: 

Again, I am no gnuplot expert, but the differences between the two eps files you provided look almost exactly like the differences between eps files I see on Debian with Octave 3.8.2 (before the logic was added in http://hg.savannah.gnu.org/hgweb/octave/rev/8990b8c4f00a).

So it's almost like the version detection logic is not working for you and it's not using the right feature for your version of gnuplot. But only on this one machine.

There is a way to dump the intermediate gnuplot commands, I think it was mentioned on the other bug report about text color. You could do this on the machine that shows this error


drawnow ("postscript", "junk.ps", 0, "foo.gp");


and check whether the "set terminal" string near the top of the resulting file contains "set terminal postscript color enhanced" or just "set terminal postscript enhanced". The latter is incorrect for gnuplot 5 and explains why you have the plot area filled with a black rectangle.

If that's the case, then someone needs to help debug why the scripts are not detecting the version of gnuplot correctly. Does this work for you on Windows and give a gnuplot version string?


>> addpath (fullfile (octave_config_info ("fcnfiledir"), "plot", "util", "private"));
>> __gnuplot_version__
ans = 5.0.3


Mike Miller <mtmiller>
Group Member
Wed 13 Jul 2016 11:53:26 AM UTC, comment #4: 

I have re-done this on the Windows 7 machine where I originally observed this bug.

Test script 1 (uses Octave 4.0.3 with built-in gnuplot)

clear, close all
graphics_toolkit gnuplot
plot(1:10)
print('test_gnuplot_win_octave403.png')
print('test_gnuplot_win_octave403.eps')


The resulting two image files have both a huge black box instead of the plotted line. I will attach the files to this comment, the filenames have "_gnuplot_" in them.

Test script 2 (uses Octave 4.0.3 with seperate installation of gnuplot 4.6.7 for 32bit Windows from gnuplot.info website)


gnuplot_binary('C:\Program Files (x86)\gnuplot\bin\gnuplot.exe')
clear, close all;
graphics_toolkit gnuplot
plot(1:10)
print('test_gnuplot467_win_octave403.png')
print('test_gnuplot467_win_octave403.eps')


The resulting two image files look fine. I will also attach those two files. They have "_gnuplot467_" in their file name.

Conclusions:

  • This bug seems to also be connected to the gnuplot version used in the current mxe-octave.
  • This bug only happens on special Windows 7 machines. (2 Win PCs worked fine, 1 showed this bug, so far) The difference is unclear to me.


Does anyone have hints or ideas what to test to further nail down where the problem comes from and how to remove it?


file #37848, file #37850)

Hartmut <hardy>
Wed 13 Jul 2016 04:18:40 AM UTC, comment #3: 

I also could not reproduce this om my Win7 machine.

Avinoam Kalma <avinoam>
Group Member
Tue 12 Jul 2016 07:30:59 PM UTC, comment #2: 

To my own surise I am unable to reproduce this on my Win7 machine at home. But I have observed this on a different Win7 machine.

The Win7 machine where this bug occured does have a special graphics card, maybe this is the difference.

I will try to do the suggested tests on the "bad" Win7 machine during the following days.

Hartmut <hardy>
Tue 12 Jul 2016 06:49:33 PM UTC, comment #1: 

I am unable to reproduce this on Debian with gnuplot 5.0.3 and Octave's stable branch. There was definitely a related problem (see bug #42838) with Octave 4.0.0 and gnuplot 5, but that was fixed in Octave 4.0.1 and later versions.

As I asked in bug #48474, do the same exact commands in 4.0.3 with gnuplot 4.6 (on Windows) produce the right output?

Can you attach a test.eps file showing the black background area (use print test.eps instead of test.png).

Mike Miller <mtmiller>
Group Member
Tue 12 Jul 2016 06:07:38 PM UTC, original submission:  

This happens under Windows with the current Octave 4.0.3 release, installed via the official installer.

Here is a little script to show the behavior:

clear, close all
graphics_toolkit gnuplot

plot(1:10)
print('test.png')


I will attach the resulting png file. Doing this with Octave 4.0.3 results in a mostly black image with the correct axis labels. Doing this with Octave 4.0.1 produces a correct image file. So this is a regression. It might be due to the version change of gnuplot that is delivered together with the Octave Windows installer (see bug #48474).

Printing a qt figure into a file works fine.

Printing into a jpg file also results in the same black image. But printing into an emf image file works fine. (I haven't tested more image file formats.)

Doing this with Octave 4.0.3 under Ubuntu linux works fine. (But my linux PC has gnuplot 4.6.4 installed.)

Hartmut <hardy>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #37875:  test_gnuplot_win_octave403.gp added by hardy (3KiB - application/x-gnuplot)
file #37825:  test_gnuplot_401_Win.png added by hardy (14KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by hardy (Submitted the item)
  •  

    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 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-07-15 mtmiller StatusNeed Info Invalid / Not an Octave Bug
        Open/ClosedOpen Closed
    2016-07-14 hardy Attached File- Added test_gnuplot_win_octave403.gp, #37875
    2016-07-13 hardy Attached File- Added test_gnuplot_win_octave403.png, #37847
        Attached File- Added test_gnuplot_win_octave403.eps, #37848
        Attached File- Added test_gnuplot467_win_octave403.png, #37849
        Attached File- Added test_gnuplot467_win_octave403.eps, #37850
    2016-07-12 mtmiller StatusNone Need Info
    2016-07-12 hardy Attached File- Added test_gnuplot_401_Win.png, #37825
        Attached File- Added test_gnuplot_403_Win.png, #37826

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code