bugGNU Octave - Bugs: bug #48474, [mxe-octave] enable better...

 
 

bug #48474: [mxe-octave] enable better supported gnuplot terminals

Submitter:  Hartmut <hardy>
Submitted:  Mon 11 Jul 2016 06:30:48 PM UTC
   
 
Category:  Configuration and Build System Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  lostbard
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 05 Mar 2019 12:56:43 AM UTC, comment #103: 

I also confirmed that the current mxe build, we can use tikz device on gnuplot graphics toolkit.

Thanks to all who have been worked on this issue.

Tatsuro MATSUOKA <tmacchant>
Sun 03 Mar 2019 03:06:43 PM UTC, comment #102: 

Thanks for pushing the patch.

The following produces a tikz file for me on Windows with a recent build:

graphics_toolkit gnuplot
plot([0 1]);
print test -dtikz


Closing again as fixed.

Markus Mützel <mmuetzel>
Group administrator
Sat 02 Mar 2019 01:03:41 PM UTC, comment #101: 
John Donoghue <lostbard>
Group Member
Sat 02 Mar 2019 12:55:09 PM UTC, comment #100: 

It applies cleanly and also builds cleanly for me.

Markus Mützel <mmuetzel>
Group administrator
Sat 02 Mar 2019 12:44:43 PM UTC, comment #99: 

Does the patch still apply cleaning on the current mxe repo ?

John Donoghue <lostbard>
Group Member
Sat 02 Mar 2019 11:53:57 AM UTC, comment #98: 

With bug #55648 solved and Octave 5.1 out now, can file #46227 be considered to be pushed to MXE Octave?

Markus Mützel <mmuetzel>
Group administrator
Mon 11 Feb 2019 07:43:37 AM UTC, comment #97: 

The error with the release candidate is probably bug #55648.
That should probably better be solved before we do any further changes to gnuplot.

In the meantime, I'm taking over this bug and repurposing it for adding the tikz terminal. I hope no one minds.

Markus Mützel <mmuetzel>
Group administrator
Mon 11 Feb 2019 05:58:29 AM UTC, comment #96: 


>> gnuplot_binary C:\Programs\gp526-64\bin\gnuplot
>> plot ([0 1])
>> graphics_toolkit gnuplot
>> plot ([0 1])
>> print test -dtikz


woks 4.4.1.

Thus error you met may be regression of octave 5.0.9x for windows for gnuplot graphics toolkit.

Tatsuro MATSUOKA <tmacchant>
Mon 11 Feb 2019 05:52:04 AM UTC, comment #95: 


>> print test -dtikz

error: _gnuplot_drawnow_: the gnuplot terminal, "tikz", is not available
error: called from
    _gnuplot_drawnow_ at line 50 column 9
    _gnuplot_print_>local_drawnow at line 232 column 5
    _gnuplot_print_ at line 114 column 9
    print at line 692 column 14

Perhaps regression of octave-5.0.9x.

Tatsuro MATSUOKA <tmacchant>
Mon 11 Feb 2019 05:22:08 AM UTC, comment #94: 


error: __gnuplot_drawnow__: the gnuplot terminal, "tikz", is not available
error: called from
    __gnuplot_drawnow__ at line 50 column 9
    __gnuplot_print__>local_drawnow at line 232 column 5
    __gnuplot_print__ at line 114 column 9
    print at line 692 column 14
+verbatim+
113:      if (__gnuplot_has_terminal__ ("tikz"))
114:       local_drawnow (["tikz " gp_opts], opts.name, opts);

Here is passed:

_gnuplot_has_terminal_ recognize "tikz"


228: function local_drawnow (term, file, opts)
229:
230:   set (0, "currentfigure", opts.figure);
231:   if (isempty (opts.debug_file) || ! opts.debug)
232:     drawnow (term, file);
233:   else
234:     drawnow (term, file, opts.debug_file);
235:   endif
236:   if (opts.debug)
237:     fprintf ("Expanded gnuplot terminal = '%s'\n", term);
238:   endif
239:
240: endfunction



232:     drawnow (term, file);


Here is the place, error happened.
I wlll dig further.

Tatsuro MATSUOKA <tmacchant>
Mon 11 Feb 2019 01:19:47 AM UTC, comment #93: 

Markus

Thanks.

I reproduced the below.

>> graphics_toolkit gnuplot
>> plot([0 1])
>> print test -dtikz


works on ubuntu and cygwin.

Tatsuro MATSUOKA <tmacchant>
Sun 10 Feb 2019 05:05:27 PM UTC, comment #92: 

@Tatsuro: I managed to cross-compile gnuplot with support for the tikz terminal. Please see the attached changeset.

Unfortunately, it doesn't work as smooth as I hoped for:

>> graphics_toolkit gnuplot
>> plot([0 1])
>> print test -dtikz
error: __gnuplot_drawnow__: the gnuplot terminal, "tikz", is not available
error: called from
    __gnuplot_drawnow__ at line 50 column 9
    __gnuplot_print__>local_drawnow at line 232 column 5
    __gnuplot_print__ at line 114 column 9
    print at line 692 column 14


However, if I set a stop point in line 40 of _gnuplot_drawnow_ and wait for the additional window to appear before I continue, it seems to work:

>> dbstop in __gnuplot_drawnow__ at 40
ans =  40
>> print test -dtikz
>>


Tested on the default branch.

I also try to attach the files that you should be able to drop in the mingw64 folder of an existing installation.

(file #46227, file #46228, file #46229)

Markus Mützel <mmuetzel>
Group administrator
Sun 10 Feb 2019 06:12:57 AM UTC, comment #91: 

Oh this is closed.
If it is better to re-post this as a new bug, please let me know.

Tatsuro MATSUOKA <tmacchant>
Sun 10 Feb 2019 05:07:31 AM UTC, comment #90: 

The gnuplot for windows from official distribution supports lua/tikz terminal. However, using official gnuplot causes bug #48696.

The gnuplot bundled with octave for windows is complied with
-DDISABLE_SPACE_RAISES_CONSOLE flag to fix the bug #48696.

So it is desirable to support lua/tikz terminal gnuplot bundled with octave for windows.

Tatsuro MATSUOKA <tmacchant>
Sun 10 Feb 2019 02:33:53 AM UTC, comment #89: 

Document of 5.0.91 says for print device tikz
 

tikz
tikzstandalone*
Generate a LATEX file using PGF/TikZ format. The OpenGLbased
toolkits create a PGF file while Gnuplot creates a TikZ
file. The ‘tikzstandalone’ device produces a LATEX document
which includes the TikZ file.


To support tikz for gnuplot graphics_toolkit on windows,
gnuplot should be build with lua/tikz.

In cross-compile this requires Linux lua or build lua on linux in mxe.
However, please consider the support.

Tatsuro MATSUOKA <tmacchant>
Thu 21 Sep 2017 11:51:30 AM UTC, comment #88: 
John Donoghue <lostbard>
Group Member
Wed 20 Sep 2017 03:09:16 PM UTC, comment #87: 

Updated patch, still builds qt terminal, but sets emv var to wxt.


(file #41843)

John Donoghue <lostbard>
Group Member
Tue 12 Sep 2017 01:09:43 AM UTC, comment #86: 

For octave 4.2.1 for windows, GNUTERM environmental variable is set to windows in octave.vbs and octave.bat and then windows terminal is default. Note that original distribution of 4.2.1, gnuplot is built with wxt terminals. If value of GNUTERM is set to wxt.


For gnuolot 5.0.x source, if gnuplot is built with qt, qt terminal is set to be default.  Package manager (I) use -DDEFAULTTERM=\"wxt\" to CFLAGS in Makefile. For 5.2 source, there is no need to use  -DDEFAULTTERM=\"wxt\".

Tatsuro MATSUOKA <tmacchant>
Mon 11 Sep 2017 04:40:05 PM UTC, comment #85: 

Tatsuro - thanks for the pointer. That's unfortunate, but if that's the status of the project then we should not use the Qt terminal by default if it's not considered stable enough.

I think it's still worth building it in to the gnuplot that we ship with Octave so users have the choice, since we are building Qt 5 anyway.

Does someone want to look into testing the "wxt" terminal, and arranging for it to be the default in the Windows install? Should we add that logic to Octave's plot routines?

Mike Miller <mtmiller>
Group Member
Mon 11 Sep 2017 04:51:40 AM UTC, comment #84: 

As stated in the below in thread of gnuplot-beta ML, gnuplot for windows, default terminal is wxt but not qt unlike other platforms because of buggy status in the qt terminal on windows.

See
http://gnuplot.10905.n7.nabble.com/default-terminal-for-version-5-2-on-Windows-td20671.html

Tatsuro MATSUOKA <tmacchant>
Sun 10 Sep 2017 11:44:20 PM UTC, comment #83: 

Dan - gnuplot_qt is the same on Windows or on GNU/Linux, it's an auxiliary program used by gnuplot for the Qt terminal. It's what is built and installed by gnuplot when you build it with Qt support.

Mike Miller <mtmiller>
Group Member
Sun 10 Sep 2017 11:21:22 PM UTC, comment #82: 


>> Two of the GUI buttons do not do anything,


I just ran gnuplot to test those buttons in the Qt terminal.  Placing the mouse over the button brings up the tool tip which says "Previous zoom" and "Next zoom".  That would suggest these buttons are a way of navigating some kind of zoom history.  The "+" and "-" would suggest zoom-in and zoom-out but that isn't what they do.  Since you probably have not done zoom, selecting those buttons is already at the front (and end) of the list of zooms.  To zoom, use the right mouse button to click on the plot window and release to select a box which will be the new zoom.  After that, the "+" and "-" buttons should do something.  I find it slightly confusing and will take up the issue with gnuplot discussion list.  BTW, the "1" means go back to the "unzoomed" plot, i.e., the first plot (again, a misleading plot)... oh, and maybe you have discovered some odd behavior with the "+"/"-" in the sense that the zoom history is kept around even though a new plot is done, which may be in a completely different range than the first plot, hence it zooms to a region were there is nothing but empty space.  I'll raise that issue with the discussion list as well.

Regarding these slow plots (presumably with not too much data), I would guess the pipe connection is being lost.

Could someone describe what gnuplot_qt is in Windows?  Is it a special compilation with code from somewhere other than the main gnuplot development site?  Regular "gnuplot" can have a Qt terminal; it's just a matter of having the proper Qt packages installed so that "./configure" can find them.

Dan Sebald <sebald>
Sun 10 Sep 2017 05:50:17 PM UTC, comment #81: 

I've compiled and tested Octave 4.2.1 with the patch from comment #80 (mxe-octave with stable-octave) on an older laptop with Win7. After doing only a "graphics_toolkit gnuplot", I've observed the following:

  • The figure windows do look different. This seems to be the proper qt display of gnuplot.
  • The content of the figure windows looks fine. 2D plots as well as 3D plots.
  • Two of the GUI buttons do not do anything, the one with the "+" sign and the one with the "-" sign. Instead I only hear a beep sound when clicking them.
  • Sometimes it takes very long for the figure content to appear on screen. (Not only for the first figure window to open.)
  • Sometimes the figure content does NOT appear at all, it only becomes visible after hitting the figure button with the "1" on it (it seems to mean: reset figure settings)
  • During the waiting time for the figure content to appear  (sometimes longer than I could wait), I have seen different error messages on the Octave console sometimes:
    • Could not connect to existing gnuplot_qt. Starting a new one.
    • line 0: undefined variable: lmargin [newline] multiplot > n; [newline] line 0: invalid command
    • line 0: undefined variable: sizein [newline] multiplot > noratio 1,1; [newline] line 0: invalid command


This doesn't appear to me as if the qt terminal of gnuplot was runnign very stable at the moment. But I am also not 100% sure if I did everything right during the generation of my mxe-octave zip-file.

Hartmut <hardy>
Fri 08 Sep 2017 05:41:19 PM UTC, comment #80: 

Updated patch here.
The qt plot window appears to have issues on my machine sometimes (doesnt always updated the plot window correctly, without resizing it for force a update)

However, I am having some opengl issues releated to Bug #44338 at the moment, which maybe are effecting things for me?

Anyone else can trying the updated patch as well?

(file #41764)

John Donoghue <lostbard>
Group Member
Thu 07 Sep 2017 05:52:35 PM UTC, comment #79: 

Ok, thanks for taking this on. I figured there might be another executable but didn't look into it and didn't notice how the TARGETs were listed.

Mike Miller <mtmiller>
Group Member
Thu 07 Sep 2017 05:46:56 PM UTC, comment #78: 

Patch doesn't work in its current state - it has to build the gnuplot_qt.exe target


trying to build the qt target then fails with the wrong rcc, moc etc being used - should be easy enough to fix so I will take a look and expand on your patch.

John Donoghue <lostbard>
Group Member
Thu 07 Sep 2017 02:05:13 PM UTC, comment #77: 

It uncomments out the 3 lines

I'll compile it if noone else beats me to it

I cant remeber why I commented it out to start with. Maybe I hadnt gotten around to testing it.

John Donoghue <lostbard>
Group Member
Thu 07 Sep 2017 01:45:43 PM UTC, comment #76: 

What does this patch do?


-#ifeq ($(ENABLE_QT5),yes)
-#  $(PKG)_DEPS     += qt5
-#  $(PKG)_EXTRAFLAGS += QT=1 QT_DIR=$(HOST_PREFIX)/qt5
-#endif
+ifeq ($(ENABLE_QT5),yes)
+  $(PKG)_DEPS     += qt5
+  $(PKG)_EXTRAFLAGS += QT=1 QT_DIR=$(HOST_PREFIX)/qt5
+endif


It seems to delete and restore the same lines.

Anonymous
Wed 06 Sep 2017 11:25:18 PM UTC, comment #75: 

Can someone build with the attached change and test gnuplot's qt terminal on Windows? Octave should automatically determine that gnuplot was built with Qt and use the "qt" terminal for on-screen rendering. It should look different than the old "windows" on-screen gnuplot window.

John - did you have a reason for adding these to the makefile but leaving it commented out?

IMHO if we include support for the qt terminal, we can consider this closed.

(file #41748)

Mike Miller <mtmiller>
Group Member
Mon 30 Jan 2017 07:56:41 AM UTC, comment #74: 

I am not a LaTeX user so that I do not know how "tikzstandalone" print device is important.

Manual says that

The ‘tikzstandalone’ device produces a LaTeX document which
includes the TikZ file (‘tikzstandalone’ is only available for the Gnuplot graphics toolkit).


My patch file #38546 included patches for lua/tikz terminal.

I myself do not have strong opinion for lua/tikz support gnuplot for windows on mxe-octave.


Tatsuro MATSUOKA <tmacchant>
Sat 28 Jan 2017 11:08:37 PM UTC, comment #73: 

Can this now be considered fixed?

John Donoghue <lostbard>
Group Member
Wed 11 Jan 2017 12:05:10 AM UTC, comment #72: 

I have confirmed the fix. Thanks!

Tatsuro MATSUOKA <tmacchant>
Tue 10 Jan 2017 03:34:39 PM UTC, comment #71: 
John Donoghue <lostbard>
Group Member
Tue 10 Jan 2017 09:47:19 AM UTC, comment #70: 

There found typo in gnuplot.mk


$(PKG)_EXTRAFLAGS += CAIRTERMS=1 CAIROLIBS=1


should be

$(PKG)_EXTRAFLAGS += CAIROTERMS=1 CAIROLIBS=1


Tatsuro MATSUOKA <tmacchant>
Tue 10 Jan 2017 09:23:30 AM UTC, comment #69: 

I have built mxe-octave and seen whether wxt and cairo based terminal works or not.

The wxt terminal works but other cairo based terminal (e.g. pngcairo) does not work.

On gnuplot prompt, I execute 'set term' to see the supported terminals.


gnuplot> set term

Available terminal types:
           canvas  HTML Canvas object
              cgm  Computer Graphics Metafile
          context  ConTeXt with MetaFun (for PDF documents)
            corel  EPS format for CorelDRAW
             dumb  ascii art for anything that prints text
              dxf  dxf-file for AutoCad (default size 120x80)
            eepic  EEPIC -- extended LaTeX picture environment
              emf  Enhanced Metafile format
            emtex  LaTeX picture environment with emTeX specials
         epslatex  LaTeX picture environment using graphicx package
              fig  FIG graphics language for XFIG graphics editor
             hpgl  HP7475 and relatives [number of pens] [eject]
            latex  LaTeX picture environment
               mf  Metafont plotting standard
               mp  MetaPost plotting standard
             pcl5  HP Designjet 750C, HP Laserjet III/IV, etc. (many options)
       postscript  PostScript graphics, including EPSF embedded files (*.eps)
          pslatex  LaTeX picture environment with PostScript \specials
            pstex  plain TeX with PostScript \specials
         pstricks  LaTeX picture environment with PSTricks macros
              qms  QMS/QUIC Laser printer (also Talaris 1200 and others)
              svg  W3C Scalable Vector Graphics
          texdraw  LaTeX texdraw environment
             tgif  TGIF X11 [mode] [x,y] [dashed] ["font" [fontsize]]
         tkcanvas  Tk canvas widget
             tpic  TPIC -- LaTeX picture environment with tpic \specials
          unknown  Unknown terminal type - not a plotting device
          windows  Microsoft Windows
              wxt  wxWidgets cross-platform windowed terminal


Tatsuro MATSUOKA <tmacchant>
Fri 30 Dec 2016 12:45:50 AM UTC, comment #68: 

I've pushed most of the changes so far, so that cairo, wxwidgets works, along with other changes to copy dlls where they should go etc.


John Donoghue <lostbard>
Group Member
Mon 19 Sep 2016 07:43:56 AM UTC, comment #67: 

The changeset I submit works but has a lot of ugly points due to my lack of knowledge of makefile rules.

Tatsuro MATSUOKA <tmacchant>
Mon 19 Sep 2016 07:35:25 AM UTC, comment #66: 
Tatsuro MATSUOKA <tmacchant>
Mon 19 Sep 2016 07:30:39 AM UTC, comment #65: 

I have prepared the chnageset for gnuplot for cairo based, wxt (windows), qt (linux), and tikz support.


(file #38546)

Tatsuro MATSUOKA <tmacchant>
Wed 07 Sep 2016 11:04:47 AM UTC, comment #64: 

Sorry the previous patch has a fault in lua of native build.
I have updated the changeset.


(file #38439)

Tatsuro MATSUOKA <tmacchant>
Wed 07 Sep 2016 10:17:06 AM UTC, comment #63: 

I have update cairo based and lua/tikz terminals support for gnuplot built by mxe-octave.

1. Treatment of lua terminals is improved.
2. Native (for linux) is been supported.

In the document of 4.1.0+ for print, there described cario based and tikzstandalone print device are described.

I think that gnuplot built by mxe-octave hopefully support those.

Please take this patch into consideration.

(file #38438)

Tatsuro MATSUOKA <tmacchant>
Wed 10 Aug 2016 11:48:05 PM UTC, comment #62: 

I have made a testing changeset for cairo based and lua/tikz terminals supports for gnuplot on windows. (gpcairoluawin.patch)

Additional libraries are :
pixman, libffi, glib, cairo, pango, and lua

I personally have built wxwidgets and wxt terminal.
But weird Pango warnings appear on octave 4.0.x but not 4.1. (they can be ignored but are annoying.)
Therefore I at the moment do not implement the wxt terminal.

For linux native build, cairo and lua supports are ignored.
(I have troubles at building the pango library on mxe-octave for linux.)

Note that the patch on https://savannah.gnu.org/bugs/?48696 is not included.

(file #38171)

Tatsuro MATSUOKA <tmacchant>
Fri 29 Jul 2016 11:17:25 AM UTC, comment #61: 

Sorry for the confusion - replace thepackagelib with the name of the package to build.

For examle make cairo


Later on when everything is working you will want to add them to PKS_DEPS in gnuplot.mk


John Donoghue <lostbard>
Group Member
Fri 29 Jul 2016 03:26:20 AM UTC, comment #60: 

Thank you for your information.
But I have met ...

$ LANG=C make thepackagelib
make: *** No rule to make target `thepackagelib'.  Stop.


Tatsuro MATSUOKA <tmacchant>
Thu 28 Jul 2016 04:31:27 PM UTC, comment #59: 

Building the libraries that already exist in the system is easy - for testing purposes, just do:

make thepackagelib


Getting it to then be used by gnuplot is a different matter - currently gnuplot is patched (see src/gnuplot-1-fixes.patch in mxe-octave) in order to enable/display/set paths correctly. SO will have to be modified to get working.

If you are lucky, it might be relatively easy, otherwise ....


For some of the packages, it may also pay to look see whether there are updated versions available, as they may be easier to compile than the mxe-versions.


John Donoghue <lostbard>
Group Member
Thu 28 Jul 2016 09:22:13 AM UTC, comment #58: 

Dan

If someone tell me how to add to build libraries listed in comment #56 in mxe-octave system, I will try to implement cairo based terminals including wxt terminal.
Windows terminal is not bad but I like wxt terminal than windows terminals which is now default in gnuplot 5 for windows distribution.

Tatsuro MATSUOKA <tmacchant>
Wed 27 Jul 2016 08:54:57 AM UTC, comment #57: 

Is the Windows terminal of gnuplot 5.0.4 adequate for the upcoming Octave release?  Can the support for better/more advanced terminals be put off until after that?  A summer-of-love-coding project?

Dan Sebald <sebald>
Wed 27 Jul 2016 08:30:35 AM UTC, comment #56: 

In comment #23,

There described

I would consider
qt (interactive)
pngcairo (raster, hardcopy)
pdfcairo (vector, hardcopy)
are absolute minimum. Those are self-consistent (same fonts, linetypes, colors) and cross-platform.

For qt
qt5 is required

For
pngcairo (raster, hardcopy)
pdfcairo (vector, hardcopy)

cairo , glib, libffi, pango, and pixman libraries are required.

The mk files for those libraries already exist in src directory.
But I do not know how to add mxe-octave system builds those.

In my opnion, wxt terminal (with wxwidges libraries) and lua terminal is better to be added.



Tatsuro MATSUOKA <tmacchant>
Tue 26 Jul 2016 03:29:07 PM UTC, comment #55: 

Just a note, assuming the update to 5.0.4 works for everyone, which I am unable to test myself, can we leave this bug open for the longer term better fix of building gnuplot against Qt 5 to enable the qt terminal?

Mike Miller <mtmiller>
Group Member
Tue 26 Jul 2016 03:18:55 PM UTC, comment #54: 
John Donoghue <lostbard>
Group Member
Fri 22 Jul 2016 09:07:11 PM UTC, comment #53: 

Right "fortunate" that can't reproduce, "unfortunate" that it could be an obscure bug.  Probably some plot or demo you ran before trying the patch demo.  It will probably show up somewhere else eventually.

Dan Sebald <sebald>
Fri 22 Jul 2016 08:31:35 PM UTC, comment #52: 

(Un)fortunately I could not reproduce this problem.

Avinoam Kalma <avinoam>
Group Member
Fri 22 Jul 2016 03:53:46 PM UTC, comment #51: 

Please try narrowing down the issue.  For example, try

demo("patch", 1)
demo("patch", 2)
demo("patch", 3)

etc. until the warning message appears.

But it is an odd warning message.  It's coming from gnuplot, not Octave.  None of those patch demos use a time-formatted string.  Do you recall running any code before running the demo?

Dan Sebald <sebald>
Fri 22 Jul 2016 10:06:56 AM UTC, comment #50: 

Using the correct installer, gnuplot 5.0.4 was installed, and it  fixed the current problem.

However, when running "demo patch" I got:

 line 54: warning: time value out of range

If I roll back to 5.0.3, I do not get this warning.
Should I open I new bug report?

Avinoam Kalma <avinoam>
Group Member
Fri 22 Jul 2016 09:50:37 AM UTC, comment #49: 

Sorry for the noise. I have installed the wrong file...

Avinoam Kalma <avinoam>
Group Member
Fri 22 Jul 2016 09:47:11 AM UTC, comment #48: 

I have tried the new patch. It download gnuplot 5.0.4, and compiled it, but when I checked the installer in Windows,
I found in the bin directory gnuplot 5.0.3. What did I miss in
the building process?

Avinoam Kalma <avinoam>
Group Member
Thu 21 Jul 2016 05:55:27 PM UTC, comment #47: 

Updated patch for mxe-octave

(file #37977)

John Donoghue <lostbard>
Group Member
Thu 21 Jul 2016 05:11:02 PM UTC, comment #46: 

gnuplot 5.0.4 was released
http://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.4/gnuplot-5.0.4.tar.gz

Can we used it in MXE-Octave to replace 5.0.3, using Tatsuro's patch?

Avinoam Kalma <avinoam>
Group Member
Sat 16 Jul 2016 01:26:01 AM UTC, comment #45: 

Reply to comment #44

I have confirmed that gnuplot-5.0.4 is built with your patch and fixes the original bug report.

BTW the below part of the patch

+--- gnuplot-5.0.4.orig/src/syscfg.h        2016-07-15 09:55:04.796270278 -0400
++++ gnuplot-5.0.4/src/syscfg.h        2016-07-15 10:02:39.396605714 -0400
 @@ -341,11 +341,19 @@
  #endif

  #ifndef GP_EXCEPTION_NAME
 -# define GP_EXCEPTION_NAME exception
 +# if __MINGW32__
-+#  define GP_EXCEPTION_NAME exception
++#   define GP_EXCEPTION_NAME exception
 +#else
-+#  define GP_EXCEPTION_NAME exception
++#   define GP_EXCEPTION_NAME exception
 +#endif
  #endif


In # if __MINGW32 and #else, GP_EXCEPTION_NAME is defined to the same value. I think that this is not required for current mingw-gcc (4.9.3).

Tatsuro MATSUOKA <tmacchant>
Fri 15 Jul 2016 02:48:45 PM UTC, comment #44: 

Patch for mxe to test gnuplot504 built in mxe octave.



(file #37898)

John Donoghue <lostbard>
Group Member
Fri 15 Jul 2016 10:48:05 AM UTC, comment #43: 

Release candidate of gnuplot 5.0.4 is uploaded ant I have built windows binaries of it.

https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/

The bug of windows terminal is fixed mentioned in this report.

Tatsuro MATSUOKA <tmacchant>
Fri 15 Jul 2016 04:48:33 AM UTC, comment #42: 

Perhaps it is another argument to make octave QT5 compatible...

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 15 Jul 2016 04:13:42 AM UTC, comment #41: 
Tatsuro MATSUOKA <tmacchant>
Fri 15 Jul 2016 04:09:39 AM UTC, comment #40: 

Yes I know because I am 64 bit windows binary packager on the site.

I have already mentioned what you said in comment #26.


> Could we include SF gnuplot package with octave install?


From distribution discussion for mac binaries in maintainers ML (I cannot remember title of the thread), the reason windows binary can be uploaded because binary is build with entirely free tools and on free OS (linux).

The gnuplot binaries provided on the source forge are built only using free GNU tools. But they were built on non-free OS (windows).

Mac binary is now built with free tools but on non-free OS (macOS).
It is at the moment distributed on octave-forge site but not octave official site.

Tatsuro MATSUOKA <tmacchant>
Fri 15 Jul 2016 03:23:41 AM UTC, comment #39: 

There are nice windows packages for gnuplot in

https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.3/

Do we need to provide one with octave?
Could we just tell people to download one from there?

Could we include SF gnuplot package with octave install?

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Fri 15 Jul 2016 03:15:17 AM UTC, comment #38: 

I have executed the dirty hack to  gnuplot-1-fixes.patch and gnuplot.mk and built gnuplot for windows qt4.

gnuplot-1-fixes.patch
config/mingw/Makefile
change QT_DIR value
change linking libraries to those of the qt4
change MOC, UIC, RCC, and LRELEASE values to use temporally  linux corresponding ones.

gnuplot.mk
add target gnuplot_qt.exe

However, as expected. mousing does not work (incredibly slow).
The Makefile of current gnuplot for windows is only prepared for qt5.

************************************************
If we want build gnuplot for windows with qt, we have also build qt5. 
************************************************



Tatsuro MATSUOKA <tmacchant>
Fri 15 Jul 2016 01:28:18 AM UTC, comment #37: 

there is no QtWidgets etc in Qt4

John Donoghue <lostbard>
Group Member
Fri 15 Jul 2016 12:58:59 AM UTC, comment #36: 

For moc, uic, rcc, and lrelease, I temporally use those on linux.
I have made a tried to build

At link of gnuplot.exe


/home/tatsuro/work/octave/mxe-octave/mxe-octave-w64/usr/bin/x86_64-w64-mingw32-ld: cannot find -lQtWidgets4
/home/tatsuro/work/octave/mxe-octave/mxe-octave-w64/usr/bin/x86_64-w64-mingw32-ld: cannot find -lQtPrintSupport4


I could not find libQtWidgets4.a and libQtPrintSupport4.a in lib directory.
Perhaps they are not built in qt-4 build for octave.
For gnuplot qt support, libQtWidgets4.a and libQtPrintSupport4.a should be built in building qt-4.

Tatsuro MATSUOKA <tmacchant>
Fri 15 Jul 2016 12:39:23 AM UTC, comment #35: 


> With some monor changes to include files, gnuplot will compile with Qt4.


Although performance issue of qt4 to gnuplot for windows, I tried to build it.
However, I could not figure out where
moc, uic, rcc, and lrelease exist in the  mxe-octave build tree.

May they have to be linux native because this is cross-build?

>Currently, to add other terminals in mxe, you need to add/modify the gnuplot-1-fixes.patch for the gbuplot/config/mingw/Makefile to set which terminals are built.


As I told, may we have to add additional dependency
for cairo support?

cairo
glib
libffi
pango
pixman

I have struggled with mxe-octave folder I cannot find how to add them to build.

Tatsuro MATSUOKA <tmacchant>
Thu 14 Jul 2016 05:30:24 PM UTC, comment #34: 

@Dan : For your curiosity I have run the following script with Octave 4.0.3 under Windows:


clear, close all;
graphics_toolkit gnuplot

figure
plot(1:10)
text(1,8, 'red text line', 'Color','r');                    % -> red
text(1,6, 'red text line with subscript a_b', 'Color','r'); % -> black

figure
plot(1:10)
text(1,8, 'red text line', 'Color','r');                                           % -> red
text(1,6, 'red text line with subscript a_b', 'Color','r', 'Interpreter', 'None'); % -> red

figure
plot(1:10)
text(1,8, 'red text line', 'Color','r');                         % -> red
ht = text(1,6, 'red text line with subscript a_b', 'Color','r'); % -> black
set(ht, 'interpreter', 'none');                                  % -> red


After the last command line, the black text turns red, after the redraw on this command.

Hartmut <hardy>
Thu 14 Jul 2016 01:37:01 PM UTC, comment #33: 

With some monor changes to include files, gnuplot will compile with Qt4.

I haven't had a chance to run it yet though.

Currently, to add other terminals in mxe, you need to add/modify the gnuplot-1-fixes.patch for the gbuplot/config/mingw/Makefile to set which terminals are built.

John Donoghue <lostbard>
Group Member
Thu 14 Jul 2016 09:10:25 AM UTC, comment #32: 

Dmitri wrote:

*******************************
I would consider
qt (interactive)
pngcairo (raster, hardcopy)
pdfcairo (vector, hardcopy)
are absolute minimum.
*******************************

For qt, it is not easy. We may have to also built qt5 in addition to qt4. (see comment #27)

For,
pngcairo
pdfcairo

additional libraries we have to add,

cairo
glib
libffi
pango
pixman

The mk files of the above already exists in src directory in
the mxe-octave.

I do not know how to activate to them.

If the above is included it is not difficult to implement wxt terminal if we add wxwidgets on windows.
(For linux, GTK is also required.)



Tatsuro MATSUOKA <tmacchant>
Thu 14 Jul 2016 08:26:23 AM UTC, comment #31: 

https://savannah.gnu.org/bugs/?48474#comment30

I post screenshot as an attachment file.


Tatsuro MATSUOKA <tmacchant>
Wed 13 Jul 2016 10:38:07 PM UTC, comment #30: 

Waiting on a bug fix from gnuplot maintainers.  There may be a new version coming out shortly.  Out of curiosity, what happens when turning off the latex interpreter?  Is the color red then?


clear, close all;
graphics_toolkit gnuplot

plot(1:10)
text(1,8, 'red text line', 'Color','r');
ht = text(1,6, 'red text line with subscript a_b', 'Color','r');
set(ht, 'interpreter', 'none');


Dan Sebald <sebald>
Wed 13 Jul 2016 02:26:22 AM UTC, comment #29: 

I add John Donoghue to the CC list because he works hard on mxe-octave. And gnuplot version up this time was done by discussion between him and me.

Tatsuro MATSUOKA <tmacchant>
Wed 13 Jul 2016 12:47:00 AM UTC, comment #28: 

https://savannah.gnu.org/bugs/?48474#comment5

I have confirmed the bug on windows on the recent developments  version (change log 2016-07-08).
As Dan said, SourceForge is now offline so I will wait the SourceForge will come back and Dan will post it to the gnuplot bug tickets.

Tatsuro MATSUOKA <tmacchant>
Wed 13 Jul 2016 12:37:15 AM UTC, comment #27: 

For build gnuplot on mxe-octave for windows. One have to consider qt version issue.

On windows binary on the official site, and my local distributions for development version built with the qt5 but not qt4 because zoom and pan by mouse of plot qt terminal with the qt4 is very very slow.
(The qt terminal on linux, gnuplot with qt4 does not have such slowness.)

Octave uses qt4 and only build qt4 in mxe octave.
To support qt terminal, we have to build qt 5 in addition to qt4.

Tatsuro MATSUOKA <tmacchant>
Wed 13 Jul 2016 12:27:13 AM UTC, comment #26: 


>Ethan Merritt repeatedly said that the cairo-based are preferred terminals; "x11", "windows" are legacy. So I do not think it is a

good idea to have a work-around in octave to work with those terminals.


As a windows binary builder of gnuplot, I can say that windows terminal is not Obsolete and well maintained by Bastein who works extensively on gnuplot on windows.
(I found that it is already mentioned by Dan Sebald)

I have posted a similar discussion on maintainers list
http://octave.1599824.n4.nabble.com/mxe-octave-cairo-based-and-lua-tikz-terminals-supports-of-gnuplot-build-in-mxe-octave-td4677264.html

but no reply has been returned.

This is a chance to discuss again.

So I add the description to use full feature gnuplot on the wiki.

http://wiki.octave.org/Octave_for_Microsoft_Windows#gnuoplot

Tatsuro MATSUOKA <tmacchant>
Tue 12 Jul 2016 10:50:39 PM UTC, comment #25: 

Sourceforge ticket tracker appears to be offline at the moment.  When it is running again I will post a bug report there to have someone try the test file on the latest Windows terminal and identify what version the fix is available.

Dan Sebald <sebald>
Tue 12 Jul 2016 10:44:06 PM UTC, comment #24: 

https://savannah.gnu.org/bugs/?48474#comment21

That's Ethan's opinion.  But gnuplot is used by so many people in so many different ways.  For example, up until a recent OS upgrade 'qt' terminal was very slow for me and x11 was a fallback.  There is still activity in the Changelog for the Windows terminal.  My thinking is it is easier short term to upgrade to, say, gnuplot 5.1 if it is released before the next major Octave release than it is to move to Qt terminal inclusion in Windows version.  Although the Qt terminal seems the way to go because it will match in appearance the Octave GUI, the risk is major breakage in the course of a couple months.

Dan Sebald <sebald>
Tue 12 Jul 2016 10:37:13 PM UTC, comment #23: 

I would consider
qt (interactive)
pngcairo (raster, hardcopy)
pdfcairo (vector, hardcopy)

are absolute minimum. Those are self-consistent (same fonts, linetypes, colors) and cross-platform.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 12 Jul 2016 10:24:43 PM UTC, comment #22: 

Dmitri - that's good enough for me. I don't care to argue about whether something is a bug or not. If you say upstream says to avoid the windows terminal, then we should do that. I'm retitling this to be about fixing mxe-octave to build one or more well-supported gnuplot terminals for the official installer.

If someone cares enough to try to help fix the windows terminal, please take that to the gnuplot project, that is off-topic for this bug report now.

If someone can provide a list of what terminals should be compiled for Windows, I'm sure that would help the people working on mxe-octave move forward with this. Even better if someone familiar with gnuplot can clone mxe-octave and try to cross-build gnuplot and help get it building with the right options and dependencies.

Mike Miller <mtmiller>
Group Member
Tue 12 Jul 2016 10:01:05 PM UTC, comment #21: 

This is not a "gnuplot bug" this is bug with the gnuplot binary distributed with the official octave -- it just does not have any cairo based terminals. You can get the laterst 5.1 but if you do not compile those terminals in they would not work either.

Ethan Merritt repeatedly said that the cairo-based are  preferred terminals; "x11", "windows" are legacy. So I do not think it is a
good idea to have a work-around in octave to work with those terminals.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Tue 12 Jul 2016 09:40:32 PM UTC, comment #20: 

OK, it's a gnuplot bug then, and do we know if it appears to have been fixed in some more recent version, e.g., the 5.1 development version?  I'm looking through gnuplot's changelog and can't see any pertinent change regarding only win.trm.  There are a lot of encodings issue for the Windows terminal in the past couple years, otherwise it might be a more general problem that just happens to be more problematic in Windows.

If there hasn't been a fix in gnuplot, my guess is this wouldn't be too difficult to fix.  Let me know, and I'll post the gnuplot-command file to the gnuplot bug list.

The other terminal that I think Windows users can use is wxt.

Dan Sebald <sebald>
Tue 12 Jul 2016 09:26:31 PM UTC, comment #19: 

And Hartmut, thanks for the gnuplot command listing. It's easy to see the two "set label" commands in the file you provided. The only difference between them are the contents of the strings and the position. That just demonstrates again, as Avinoam showed earlier, that the gnuplot commands are correct, the problem is in the windows terminal.

Mike Miller <mtmiller>
Group Member
Tue 12 Jul 2016 09:22:38 PM UTC, comment #18: 

Yes, agree with Hartmut and Avinoam, let's stay focused here.

Dan: we've already shown what commands Octave is feeding gnuplot and that it is correct. The problem is solely with on-screen rendering using the "windows" terminal with gnuplot 5.0.3. Is it worth fixing or should a different terminal be used instead?

Dmitri: yes, this this is not about how to get a working gnuplot after the fact but about making sure the default in the official binary installer (which includes gnuplot 5.0.3 now) is correct and useful for everyone.

Hartmut: thank you for showing the list of supported terminals.

Any mxe-octave testers paying attention, could we try adding "qt" to the list of dependencies in the src/gnuplot.mk file and see if that's enough to get it to build the qt terminal?

Mike Miller <mtmiller>
Group Member
Tue 12 Jul 2016 09:12:26 PM UTC, comment #17: 

I have already used the drawnow command to point out the gnuplot bug (comment #5)

Avinoam Kalma <avinoam>
Group Member
Tue 12 Jul 2016 09:07:15 PM UTC, comment #16: 

@Dmitiri: Thanks you for this hint. But this issue is not about some self compiled gnuplot binary. It is about the gnuplot binary, that is part of the official Octave Windows installer. I personally have enough workarounds to deal with this issue for myself, but I would like to see this fixed for all other Windows users. Because I assume this bug will otherwise also be present in the upcoming 4.2 release of mxe-octave.

When I create the plot from the script in my original post, and afterwards run

drawnow("windows", "scrap.jnk", false, "plot_with_wrong_textcolors.gp");

then I get as a result a gp-file, that I will attach to this post.

Can anyone tell from this file what's going on?


(file #37832)

Hartmut <hardy>
Tue 12 Jul 2016 08:31:38 PM UTC, comment #15: 

Yes, compiling gnuplot is easy, but you must have all the necessary development versions of libraries.

Something else you can do is print out the gnuplot code that your Windows version of Octave is generating.  Then someone else could examine that gnuplot code on their system.  Maybe that would lead somewhere:

Older version (linux):


  [create your plot;]
  drawnow ("x11", "/dev/null", false, "foo.gp");


Newer version (linux):


  [create your plot;]
  drawnow ("x11", "/dev/null", "foo.gp");


and if /dev/null doesn't work, try some file name like, 'scrap.jnk'.

Dan Sebald <sebald>
Tue 12 Jul 2016 08:24:22 PM UTC, comment #14: 

It appears that you gnuplot either corrupted or miscompiled.
You can download and install a standalone gnuplot binary
from

https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.3/

You should be able to tell octave to use a different gnuplot program via gnuplot_binary() function.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 12 Jul 2016 08:01:01 PM UTC, comment #13: 

In the gnuplot version (5.0.3) installed inside the Octave 4.0.3 Windows installer, there are the following "terminals" available:

canvas, cgm, context, corel, dumb, dxf, eepic, emf, emtex, epslatex, fig, hpgl, latex, mf, mp, pcl5, postscript, pslatex, pstex, pstricks, qms, texdraw, tgif, tkcanvas, tpic, unknown, windows.

(I cannot judge if any of those terminals would be good to use as a default terminal in Windows machines. Neither do I know if there are more gnuplot terminal that could somehow be enables when compiling gnuplot in mxe-octave.)

Hartmut <hardy>
Tue 12 Jul 2016 07:44:33 PM UTC, comment #12: 

I can think of a couple paths to pursue this. It's already been shown that Octave is doing the correct thing, and gnuplot 5 on its own has the same incorrect on-screen output.

1. Someone could report this to gnuplot. As far as I know Dan Sebald and Tatsuro MATSUOKA are active with the gnuplot project, adding them in cc now. Is it worth trying to improve on-screen rendering with gnuplot's windows terminal or is it a dead-end?

2. Someone could verify what terminals are being built and made available in gnuplot with the mxe-octave build process (simply run "set term" in gnuplot), see whether another terminal is available or can be made available, and make that terminal be the default choice in Octave. May need changes to both mxe-octave and octave, or maybe it's not possible to cross-build the qt terminal for example.

Bug reports about more than one problem are problematic to keep track of, so let's just collect information about these two possibilities for now.

And as to severity, someone is welcome to overrule me, I'm no authority (and as with all bug reports, people willing to work on it are more important than what the severity level says). It seems to me that in general people are more concerned with the "print" output of figures than the on-screen display, some users open the resulting files in an image or svg editor for example and make fixes to work around various shortcomings.

Mike Miller <mtmiller>
Group Member
Tue 12 Jul 2016 07:19:25 PM UTC, comment #11: 

As said in comment #8 the gnuplot terminal 'qt' is not available with the current Octave 4.0.3 release Windows installer. When I try your suggested command, then I only get "unknown or ambiguous terminal name 'qt'" as result. Are there any other gnuplot terminals enabled in the Windows binaries at all?

How do we proceed?

  • Is there someone with connection to the gnuplot project, who could file a bug report there?
  • If the gnuplot "windows" terminal is unsupported by the gnuplot team (see comment #7), but still used in mxe-octave, can we switch to a different (still supported) gnuplot terminal as default terminal on Windows machines, and have this terminal enable in the mxe-octave build?
  • other suggestions?


PS: It's fine to not spend too much effort on a gnuplot bug, since we have other graphics toolkits available in Octave. But why does it lower the severity, if a plotting problem occurs only on-screen and not in print-outs? I personally only ever use on-screen plots.

Hartmut <hardy>
Tue 12 Jul 2016 06:05:23 PM UTC, comment #10: 

Hartmut: no, the engine that gnuplot uses to display the figure on the screen is what is showing the error for you. This is the "windows" terminal in your case. Gnuplot uses the term "terminal" to mean the engine that renders the plot, either on screen or to a file.

As said in comment #8, other on-screen display terminals such as "qt" or "wxt" should work correctly. These may not be built correctly for the gnuplot included with the Octave installer. You can select the gnuplot terminal to use with


>> setenv GNUTERM qt


in Octave.

I seem to recall there have been other bugs reported that are simply on-screen display problems with the gnuplot windows terminal. These are low-priority since the printed file renders correctly (using the postscript or other terminal).

Lowering the severity of this since it only affects on-screen display with the windows terminal.

Mike Miller <mtmiller>
Group Member
Tue 12 Jul 2016 05:55:36 PM UTC, comment #9: 

I can confirm Avinoams observations from my tests with Octave 4.0.3 under Windows 7:

  • printing a figure (with a red and an incorrectly black text) into a emf image file works fine. Both texts are correctly printed in red color then.
  • printing a gnuplot figure to different file formats ends up in a totally corrupted image file. But this is independent of the figure content, I will open a seperate bug report for this.


Some reasoning: If this bug is due to a Gnuplot bug in version 5.0.3, then it should also pop up under a Linux system, as soon as the Linux has gnuplot 5.0.3 installed. (Is this true? I haven't tested this, can someone confirm this?) In this case we should correct the bug title and "OS flag" accordingly.

Hartmut <hardy>
Tue 12 Jul 2016 12:06:44 PM UTC, comment #8: 

In "qt" term and in "wxt" term the colors are correct,
but those terminals are not recognized in gnuplot version bundled with Octave in windows.

Avinoam Kalma <avinoam>
Group Member
Tue 12 Jul 2016 11:48:49 AM UTC, comment #7: 

What if you set term to "qt"?
"windows" terminal is deprecated...

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 12 Jul 2016 10:21:50 AM UTC, comment #6: 

If you print to file it's correct


set term postscript solid color
set out "a.ps"

set label "a_b" at  0.5,0.5 textcolor rgb "#ff0000";
set label "ab" at  0.25,0.25 textcolor rgb "#ff0000";
plot sin(x)


In a.ps both labels are red, using gnuplot 5.0.3

Avinoam Kalma <avinoam>
Group Member
Tue 12 Jul 2016 10:09:15 AM UTC, comment #5: 

It's seems like a gnuplot 5.0.3 bug.
test the script:


set term windows

set label "a_b" at  0.5,0.5 textcolor rgb "#ff0000";
set label "ab" at  0.25,0.25 textcolor rgb "#ff0000";
plot sin(x)


In gnuplot: In ver 5.0.3 the first label is black, and the second is red.
In ver 4.6.7 both are red.

Avinoam Kalma <avinoam>
Group Member
Mon 11 Jul 2016 10:42:51 PM UTC, comment #4: 

I would guess that the first thing worth doing would be to test the default branch of Octave. There have been many fixes made to improve things when working with gnuplot 5.

If this bug is still present on the default branch, then maybe someone with more knowledge of gnuplot can help figure out what's wrong, or a small test case can be produced that shows that this is an error in gnuplot and a bug reported to the gnuplot project.

As it is now, with Octave 4.0.3, you have a workaround using the 4.6 version of gnuplot.

Can someone test the original example on Windows using a build from the default branch?

One thing I wasn't clear about from the original message, is the wrong color shown on-screen, or when the figure is printed to a file, or both?

Mike Miller <mtmiller>
Group Member
Mon 11 Jul 2016 10:38:47 PM UTC, comment #3: 

The rest of your message was truncated on the web here, reposting:

  • type gnuplot_binary('C:\Program Files (x86)\gnuplot\gnuplot.exe')
  • then run the Octave script from my original bug report
  • Both text lines are properly colored in red!


How can we proceed to make this behavior disappear?

Mike Miller <mtmiller>
Group Member
Mon 11 Jul 2016 09:03:06 PM UTC, comment #2: 

You are right: This regression is due to the version update of Gnuplot in the Windows Octave release.

When I do this on my Win7 machine:

  • Install Gnuplot 4.6.7, win32 version, from gnuplot.info
  • start Octave 4.0.3 Windows release
  • type +verbatim+ gnuplot_binary('C:\Program Files (x86)\gnuplot\gnuplot.exe') -verbatim-
  • then run the Octave script from my original bug report

-> Both text lines are properly colored in red!

How can we proceed to make this behavior disappear?

Hartmut <hardy>
Mon 11 Jul 2016 06:46:11 PM UTC, comment #1: 

Can you test whether this is due to a change in the windows terminal of gnuplot? The gnuplot built for Windows was updated from version 4.6.7 to 5.0.3 between the 4.0.2 and 4.0.3 builds.

I think the easiest way to test this would be to download gnuplot 4.6 from http://gnuplot.info, install it, and tell Octave where it is (using the gnuplot_binary function).

Mike Miller <mtmiller>
Group Member
Mon 11 Jul 2016 06:30:48 PM UTC, original submission:  

This is a regression of the official Windows release, concerning the gnuplot graphics_toolkit.

The following code works fine in the Octave 4.0.2 Windows release, but it works wrong in the current 4.0.3 Windows release:


clear, close all;
graphics_toolkit gnuplot

plot(1:10)
text(1,8, 'red text line', 'Color','r');
text(1,6, 'red text line with subscript a_b', 'Color','r');


My observation: With the Octave 4.0.3 Windows release, the second line is plotted in black, and not in red. (Observed on two different Win7 machines. Using the official Windows installer from the Octave website.)

If you skip the subscript part in the second text line, then this line also turns properly red in Octave 4.0.3 Windows. Any other "latex interpeter" command is also sufficient to trigger this bug.

This bug does not show up on my (self compiled) Octave 4.0.3 release on Ubuntu linux.

Hartmut <hardy>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #46227:  bug48474_gnuplot_tikz.patch added by mmuetzel (3KiB - application/octet-stream)
file #46228:  test.tikz added by mmuetzel (4KiB - application/octet-stream)
file #46229:  tikz.7z added by mmuetzel (1MiB - application/octet-stream)
file #41843:  gnuplot_wxt.patch added by lostbard (5KiB - application/octet-stream)
file #41764:  updatedgnuplot.patch added by lostbard (4KiB - application/octet-stream)
file #41748:  gnuplot-qt5.patch added by mtmiller (916B - text/x-patch)
file #38546:  gnuplot_cairo_tikz_wxt_qt_v0.patch added by tmacchant (55KiB - application/octet-stream)
file #38438:  gnuplot_cairo_lua.patch added by tmacchant (48KiB - text/x-patch)
file #38171:  gpcairoluawin.patch added by tmacchant (44KiB - text/x-patch)
file #37977:  gnuplot2.patch added by lostbard (6KiB - application/octet-stream)
file #37898:  gnuplot504.patch added by lostbard (7KiB - application/octet-stream)
file #37869:  bug48474_01.png added by tmacchant (11KiB - image/png)
file #37832:  plot_with_wrong_textcolors.gp added by hardy (4KiB - application/x-gnuplot)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by tmacchant (Add to CC list because JohnD is maintaining mxe-octave )
  • -email is unavailable- added by tmacchant (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by mtmiller
  • -email is unavailable- added by mtmiller
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by avinoam (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 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-03 mmuetzel StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2019-03-02 mmuetzel StatusIn Progress Patch Submitted
    2019-02-11 mmuetzel StatusFixed In Progress
        Open/ClosedClosed Open
    2019-02-11 mtmiller Carbon-CopyRemoved 80942 -
    2019-02-10 mmuetzel Attached File- Added bug48474_gnuplot_tikz.patch, #46227
        Attached File- Added test.tikz, #46228
        Attached File- Added tikz.7z, #46229
    2019-02-10 rik5 Carbon-CopyRemoved 72865 -
    2018-07-12 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2017-09-21 lostbard StatusPostponed Ready For Test
    2017-09-20 lostbard Attached File- Added gnuplot_wxt.patch, #41843
    2017-09-08 lostbard Attached File- Added updatedgnuplot.patch, #41764
    2017-09-06 mtmiller Attached File- Added gnuplot-qt5.patch, #41748
        Summarymxe-octave: enable better supported gnuplot terminals [mxe-octave] enable better supported gnuplot terminals
    2016-11-24 mtmiller Item GroupRegression Feature Request
        StatusReady For Test Postponed
        Release4.0.3 dev
    2016-09-19 tmacchant Attached File- Added gnuplot_cairo_tikz_wxt_qt_v0.patch, #38546
    2016-09-07 tmacchant Attached File- Added gnuplot_cairo_lua_v3.patch, #38439
    2016-09-07 tmacchant Attached File- Added gnuplot_cairo_lua.patch, #38438
    2016-08-10 tmacchant Attached File- Added gpcairoluawin.patch, #38171
    2016-07-26 lostbard StatusPatch Submitted Ready For Test

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code