bugGNU Octave - Bugs: bug #43651, special character (diameter sign)...


bug #43651: special character (diameter sign) in plot produces warning or doesn't show up

Submitted by:  Hartmut <hardy>
Submitted on:  Thu 20 Nov 2014 10:00:23 PM UTC  
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Tue 03 Sep 2019 09:45:31 PM UTC, comment #34: 

Thank you for this hint, Pantxo.

Yes, I still had (for historic reasons) a "defaulttextname" of "Arial" set in my startup.m under Windows. But now that Octave ships with FreeSans, this is unnecessary and it corrupted my tests for this bug.

Using the code from comment #33 (with the default "*" font), I now get the proper diameter sign displayed.

So I am fully happy with closing this bug report (better: keeping it closed). It has really been fixed. Probably by including the FreeSans font into the mxe-octave distribution.

Hartmut <hardy>
Tue 20 Aug 2019 07:46:16 AM UTC, comment #33: 

I didn't do anything that could improve this situation: we don't have a fallback mechanism, so if the character is missing in the target font, then this bug will show up.
FreeSans, the default font that is shipped with Octave, does have the diameter character (U2298) and thus by default any Windows install of Octave 5.1 (or even 4.4) should display this symbol properly.

@Harmut: Are you sure you are not using a custom font setting? Can you force the use of the default font:

text (0.5, 0.5, '\0', 'fontname', '*');

Pantxo Diribarne <pantxo>
Project Member
Mon 22 Jul 2019 03:55:27 PM UTC, comment #32: 

The thanks go to Pantxo probably who improved the graphics and plotting backend quite significantly (although I cannot pinpoint a specific changeset).

Markus Mützel <mmuetzel>
Project Member
Sun 21 Jul 2019 09:23:48 PM UTC, comment #31: 

Alright, thanks for the fix, then!

I'll try to double check it, once there is an official mxe built for 6.1.

Hartmut <hardy>
Sun 21 Jul 2019 07:33:21 PM UTC, comment #30: 

I tested with a build of the default branch which will become Octave 6.1 by the end of this year.

Markus Mützel <mmuetzel>
Project Member
Sun 21 Jul 2019 07:28:06 PM UTC, comment #29: 

This behavior is still PRESENT in the latest Windows release of Octave 5.1.0. (I re-tested the code from comment #0, using graphics_tookit qt under Win7).

Markus, have you tested this with a more recent dev built of the Windows version to conclude that this issue is fixed?

Hartmut <hardy>
Sun 21 Jul 2019 10:58:40 AM UTC, comment #28: 

This seems to have been fixed with changes to the graphics and printing system on the default branch.

Closing as fixed.

Markus Mützel <mmuetzel>
Project Member
Mon 11 Mar 2019 03:29:10 PM UTC, comment #27: 

So, the t1_matlab.pdf is actually a postscript file; the t1_matlab_differentPlotCommand.pdf is a pdf, but it does not use
calibri fonts, but "Helvetica" which is also not embedded
and rendering will be different on different computers.

Also looking on screenshot it is obvious that matlab fakes
diameter symbol as letter Ø (the diameter should be a perfect circle not an ellipse). I guess octave can go the same route
and substitute \0 with Ø (I would argue that low-case would look better) which would display with large(-er) selection  of fonts.


Dmitri A. Sergatskov <dasergatskov>
Mon 11 Mar 2019 12:36:59 PM UTC, comment #26: 

Here is the Matlab output (recent version) for the code in comment #25:

  • a screenshot -> t1_Screenshot
  • the pdf output from the code in comment #25 -> t1_matlab
  • the pdf output from the code in comment #25 but with the last code line changes to "print -dpdf 'asdf.pdf'" -> t1_matlab_different

The Matlab screen output looks nice. Their pdf is not pretty either.

file #46495, file #46496)

Hartmut <hardy>
Sun 10 Mar 2019 04:56:49 PM UTC, comment #25: 

More specifically, attach the file produced by matlab
after executing the following script:

set(0, 'DefaultTextFontname', 'Calibri');
text(0.5, 0.5, 'Circle \010"')


Dmitri A. Sergatskov <dasergatskov>
Sun 10 Mar 2019 04:48:29 PM UTC, comment #24: 

Can you make this example file in matlab and attach it here?


Dmitri A. Sergatskov <dasergatskov>
Sun 10 Mar 2019 04:45:39 PM UTC, comment #23: 

Thank you for hints to work around this problem.

But my EXPECTATION would be that (all) special characters can be used in plots just straight away. (as for example in my comment #0). Without the need to specify any special font.

This also works fine in Matlab. (more precise: my expectation is that all special characters that simply work in Matlab, should also work in Octave.)

Hartmut <hardy>
Sat 09 Mar 2019 07:34:28 PM UTC, comment #22: 

Alternatively one can fake diameter symbol (U+2300) with (U+00F8)
ø letter that presents in some languages and as a result exists in wider variety of fonts. So the following works with e.g. Noto font
(which is the default on my computer):

text(0.5, 0.5, 'Circle ø10"')
print("t2.pdf", "-svgconvert")


(file #46479)

Dmitri A. Sergatskov <dasergatskov>
Sat 09 Mar 2019 07:14:55 PM UTC, comment #21: 

What are expectations?
For me the following works (with qt backend):

text(0.5, 0.5, 'Circle \0 10"', 'fontname', 'cambria')
print("t1.pdf", "-svgconvert")


Dmitri A. Sergatskov <dasergatskov>
Sat 09 Mar 2019 04:13:58 PM UTC, comment #20: 

I have re-tested this with the new Octave 5.1.0 release (official w64 installer) under Windows 7. Result:

  • The original behavior is still the very same. The code from comment #0 still does not produce any diameter sign on screen.

When reading through the comments it seems to me that there was the plan to change to a different default font for Windows Octave (or to maybe even include this font into the Windows installer), at least for the display of special characters. But I think no decision was made WHICH font this should be, nor was anything improved in the Octave code base in this respect. (Correct me if misunderstood this.)

So please let this bug report stay OPEN. And maybe we can improve this bit of Octave now?
@Pantxo, @Rik, @Dmitri: What would you suggest?

Hartmut <hardy>
Sun 03 Mar 2019 06:43:10 PM UTC, comment #19: 

The last comment on this report was 1.5 years ago.  Could somone try to reproduce this with the latest stable release which is 5.1.0.  The problem is likely to have been fixed.

Rik <rik5>
Project Administrator
Tue 17 Oct 2017 02:37:14 PM UTC, comment #18: 

I am actually advocating to avoid use of ghostscript.
Anyway on my system Symbol is google-croscore "SymbolNeu.ttf".

Inkscape uses cairo library for svg to pdf conversion, so converting symb.svg to pdf preserves the specified font (Symbola):

pdffonts symb.pdf
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
NDINOP+FreeSans                      TrueType          WinAnsi          yes yes yes      9  0
OGGIHN+FreeSerif                     CID TrueType      Identity-H       yes yes yes     10  0
BIENER+Symbola                       CID TrueType      Identity-H       yes yes yes     11  0
NSCGGO+FreeSerif                     TrueType          WinAnsi          yes yes yes     12  0
BMLRLM+Symbola                       TrueType          WinAnsi          yes yes yes     13  0

The file is attached.


(file #42181)

Dmitri A. Sergatskov <dasergatskov>
Tue 17 Oct 2017 11:09:34 AM UTC, comment #17: 

Ideally we should use the Symbol font so that printout and onscreen glyphs match. On my system, "fc-match -v Symbol" tels me the font files is a sym link to "/usr/share/fonts/type1/mathml/Symbol.pfb".

I used fontforge to inspect this file and I was not surprised to see that the glyphs we think are missing are actually present: that is why ghostscript is able to find them and put them in a png.

The problem is the mapping from a character to a glyph, and that is where I get lost. Let me take an example: "\alpha" is glyph #97 ("a") in a 1 byte Symbol character set (like the one used in postscript) and #945 in unicode.

There are additional information in font files to indicate which gliph correspond to what unicode or 1 byte character, but I still have to play with fontforge to understand this. At least what I already can say is that the unicode code for "Copyright" is not filled (it is -1 ataully) in my Symbol.pfb.

[1] http://www.alanwood.net/demos/symbol.html

Pantxo Diribarne <pantxo>
Project Member
Tue 17 Oct 2017 12:42:48 AM UTC, comment #16: 

Attached are the svg output as well as its conversion to png
(inkscape symb.svg --export-png symb.png)


file #42178)

Dmitri A. Sergatskov <dasergatskov>
Tue 17 Oct 2017 12:35:18 AM UTC, comment #15: 

I do not have any problem with svg (which uses Symbola)
but printing to eps ignore font settings and uses "Helvetica"
(or whatever it resolved to on the machine).


Dmitri A. Sergatskov <dasergatskov>
Tue 17 Oct 2017 12:32:13 AM UTC, comment #14: 

On my machine, FreeSerif complains about 4 symbols during printing so it too does not appear to be fully complete.

warning: print: unhandled symbol 977
warning: print: unhandled symbol 247
warning: print: unhandled symbol 8711
warning: print: unhandled symbol 982

Symbola performs equally well as FreeSerif, that is, there are no complaints for onscreen rendering but 4 symbols have problems during printing.

On the other hand, Symbol is by far the worst as it complains about 11 glyphs when rendering onscreen.

warning: text_renderer: skipping missing glyph for character '2218'
warning: text_renderer: skipping missing glyph for character '2219'
warning: text_renderer: skipping missing glyph for character '2223'
warning: text_renderer: skipping missing glyph for character '2298'
warning: text_renderer: skipping missing glyph for character '2308'
warning: text_renderer: skipping missing glyph for character '2309'
warning: text_renderer: skipping missing glyph for character '230a'
warning: text_renderer: skipping missing glyph for character '230b'
warning: text_renderer: skipping missing glyph for character '27e8'
warning: text_renderer: skipping missing glyph for character '27e9'
warning: text_renderer: skipping missing glyph for character 'a9'

If I use OpenSymbol I only get one glyph that is unhandled for both onscreen rendering and for printing.

Out of all that, its pretty hard to decide which is best.  I don't mind switching to an alternative for Symbol, but which should it be?

Rik <rik5>
Project Administrator
Mon 16 Oct 2017 05:31:39 PM UTC, comment #13: 

@Rik: indeed the script I attached was wrong and should have been like in omment #11. The reason I wanted to use FreeSerif instead of Symbol font is that on my system the Symbol font lacks some glyphs, at least the version fontonfig finds ("/usr/share/fonts/X11/Type1/Symbol.pfb"). The attached modified script plots all the TeX symbols in an svg file: 11 glyphs are missing in the symbol font in Octave and in Inkscape.

On the other hand ghostscript does have access to a full featured Symbol font so in theory it should be somewhere to be found.

(file #42165)

Pantxo Diribarne <pantxo>
Project Member
Sun 15 Oct 2017 11:30:57 PM UTC, comment #12: 

There are Symbola fonts:


On Fedora they are in gdourious-symbola-fonts:


In case it matters -- the original Symbol fonts
are Serif fonts.


Dmitri A. Sergatskov <dasergatskov>
Sun 15 Oct 2017 11:09:16 PM UTC, comment #11: 

I changed the last bit of the script to

print symb.svg
print symb.eps
open symb.svg
open symb.eps

Since Matlab and gnuplot both switch to the Symbol font when rendering TeX, what is the advantage of switching to FreeSerif?  Why shouldn't Octave just switch to Symbol font as well?  Is there an OpenSymbol font that we could ship?

Rik <rik5>
Project Administrator
Sun 15 Oct 2017 10:53:46 PM UTC, comment #10: 

Any reason why the bottom of the script prints the output twice?

print /tmp/symb.svg
open /tmp/symb.eps
print /tmp/symb.svg
open /tmp/symb.eps

Rik <rik5>
Project Administrator
Sun 15 Oct 2017 10:02:59 PM UTC, comment #9: 

We now have the default ("*") sans serif font shipped with Octave. The chosen font is "FreeSans" which happens to contain the same characters as Ghostscript's replacement for Helvetica (urw base fonts) so that printout now look approximately like on-screen.

I would now advocate for using "FreeSerif" for TeX symbols:

  • All TeX symbols are defined
  • The symbols in this font (see svg output) look much like the Symbol font we have to use for eps output.
  • Again, mapping math characters to a single font is a common practice (libreoffice, matlab, latex, ...) and, this is a personal opinion, make labels more legible.

Please find attached a script in which I compiled all TeX symbols documented by Matlab, and plotted them to svg and eps.

(file #42162)

Pantxo Diribarne <pantxo>
Project Member
Wed 26 Oct 2016 11:08:30 AM UTC, comment #8: 

Most rich text editors (latex, libreoffice ...) use different fonts for (inline or not) math symbols. 
I'd vote doing the same in Octave by choosing using a full featured font (ASANA?[1] Computer Modern? ...) that we would ship with Octave so that we are sure all symbols can be shown whatever the main text font is chosen by the user.
The example below leads to 2 different characters for the mu greek letter in Matlab (see screen shot attached), one for the utf8 character input and one for the tex input:

axes ()
text (.5, .5, 'µ\mu', 'fontsize', 18)

[1] https://en.wikipedia.org/wiki/Asana-Math

Pantxo Diribarne <pantxo>
Project Member
Mon 29 Dec 2014 08:21:15 PM UTC, comment #7: 

More debugging shows that for gnuplot the font name is always set to Symbol for any extended glyphs.  This is consistent with the previous debugging that shows that Matlab and gnuplot do not use the text font for glyphs rendered through the TeX interpreter.

Rik <rik5>
Project Administrator
Mon 15 Dec 2014 05:31:08 AM UTC, comment #6: 

Thanks for doing such careful debugging.  I think you've discovered the root issue which is that FLTK adheres strictly to the user's stated font, while gnuplot and Matlab substitute a font specifically for symbols.  They may also be running some sort of substitution for glyphs not found as well.  I can tell because Octave is requesting the circle division slash glyph, and gnuplot is responding with the emptyset glyph which is a different.

Since gnuplot is going to ignore Octave anyways I don't see any point in checking on Octave's side whether the given font has the correct glyph.  I believe you're right that the glyph warning can be eliminated when the toolkit is gnuplot.

On the broader issue of whether FLTK should follow gnuplot/Matlab and use a different font entirely for special symbols, I'm not certain how to proceed.  One choice would be to try and use the default font, '*', for all symbols in the hope that the default has the largest number of glyphs of the available fonts.  Otherwise, I'm not sure how to find the best font to use for symbols on a given platform.

Rik <rik5>
Project Administrator
Tue 09 Dec 2014 07:42:54 PM UTC, comment #5: 
  • Concerning the (unnecessary) warning from gnuplot I do not like to argue. The resulting plot is fine nevertheless.

If we keep this aside, I do still see a big misbehavior of FLTK on this Win7 machine:

  • For the vast majority of the installed fonts (including the default font) NO special characters are displayed on screen. I took "\alpha" in the example below. So this misbehavior is not restricted to the rather exotic special character "\0".
  • On the very SAME Win7 machine (and therefore with the very same fonts installed) I do get properly displayed special characters with Matlab, as well as with the gnuplot engine of the same Octave installation.
  • note: This is even true on my Linux machine: gnuplot displays the "\alpha" and the "\0" with many many more different font names set, as the fltk frontend does.

Other observations, that might or might not be giving us a hint to the root cause here:

  • FLTK seems to take the special characters directly from the choosen font name. With Matlab and with the gnuplot engine of Octave this is NOT the case (see the attached screenshots). They seem to take the SPECIAL characters always from the same font, regardless of the specified font name. The specified font name is only taken for the letters and similar "normal" characters. (This is also the case under Linux: gnuplot gives me always the same "\alpha" on the screen, where as fltk gives my differently looking "\alpha"s, depending on the chosen font name. And for some fonts fltk does not give me any "\alpha" on screen, where gnuplot still does.)
  • Matlab as well as the Gnuplot engine probably take the font "Microsoft Sans Serif" as default font "*" on this Win7 machine. This font is set as default font "MS Shell Dlg" via the Windows registry "HKLM/HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes". In contrast, fltk seems to use a different font as default font "*". Maybe Arial. Have a look at the screenshots yourself.

I will attach 3 screenshots from the resulting plots in (1) Matlab, (2) Octave with gnuplot and (3) Octave with fltk respectively. They are all the result of the very same script, quoted below. I think you can follow my conclusions on the fltk misbehavior on the basis of those screenshots.

close all;
%graphics_toolkit gnuplot;
graphics_toolkit fltk;


text(0,0.99,'Franz \alpha \0 Roman','fontname','Roman','fontsize',fs)
text(0,0.9,'Franz \alpha \0 Lucida','fontname','Lucida','fontsize',fs)
text(0,0.8,'Franz \alpha \0 Garamond','fontname','Garamond','fontsize',fs)
text(0,0.7,'Franz \alpha \0 Times','fontname','Times','fontsize',fs)
text(0,0.6,'Franz \alpha \0 Tahoma','fontname','Tahoma','fontsize',fs)
text(0,0.5,'Franz \alpha \0 *','fontname','*','fontsize',fs)
text(0,0.4,'Franz \alpha \0 MS SansSerif','fontname','Microsoft Sans Serif','fontsize',fs)
text(0,0.3,'Franz \alpha \0 Arial','fontname','Arial Standard','fontsize',fs)
text(0,0.2,'Franz \alpha \0 Calibri','fontname','Calibri','fontsize',fs)
text(0,0.1,'Franz \alpha \0 Verdana','fontname','Verdana','fontsize',fs)
text(0,0.01,'Franz \alpha \0 Cambria','fontname','Cambria','fontsize',fs)

text(0.5,0.99,'Franz \alpha \0 Modern','fontname','Modern','fontsize',fs)
text(0.5,0.9,'Franz \alpha \0 MS Reference','fontname','MS Reference Sans Serif Standard','fontsize',fs)
text(0.5,0.8,'Franz \alpha \0 Trebuchet','fontname','Trebuchet','fontsize',fs)
text(0.5,0.7,'Franz \alpha \0 Mathcad UniMath','fontname','Mathcad UniMath','fontsize',fs)

axis off;

A last comment: This problematic Win7 PC is not some exotic Windows machine. It' a clean and fresh install of a standard PC in a big engineering company. The next couple of thousand PCs will look identical in this company...

Hartmut <hardy>
Tue 02 Dec 2014 06:26:07 PM UTC, comment #4: 

I checked the actual fontfiles using fontforge that I have installed on my computer and, indeed, the version of Arial and Cambria I have do not have an entry for 0x2298.

I set a breakpoint in the render code and checked the fontname just before it attempts to map the Unicode number to a glyph index.  When it works, the font name is '*' which is the default font.

To find the default font I used


on a shell command line.  I don't know if there is something similar for Windows or not, but that's the only way I could figure out what the default font was.

So far I think Octave is behaving correctly.  The glyph doesn't exist so it issues a warning about it.  Even when using gnuplot, the glyph doesn't exist but gnuplot seems to be substituting a character on its own.

Rik <rik5>
Project Administrator
Tue 02 Dec 2014 03:56:51 AM UTC, comment #3: 

Using the default font '*' leaves it up to the operating system, and I don't know how to determine which font gets selected.

Within Octave, you can set a default on the root figure that will be respected later.

set (0, 'defaulttextfontname', 'arial')

That is something you could put in your .octaverc if you find a font that you like and which generates the glyph for you.

When I try to use the Cambria font I still get a warning message and no printing of the correct glyph, but this is on a Linux install with the Microsoft TrueType fonts added--not a native Windows environment.

Rik <rik5>
Project Administrator
Thu 27 Nov 2014 08:33:06 PM UTC, comment #2: 

I've tried a couple of things as suggested, and here is my current conclusion (more details below) for this one problematic Windows installation of Octave:

  • With FLTK as graphics toolkit, the default font does not contain several special characters, so there are not printed on screen (and a useful warning message is issued).
  • With FLTK and GNUPLOT as graphics toolkit, a (in this case useless) warning message is issued when printing those special characters, even when the on screen printing acutually DOES work properly.

Here are some details you wanted to know:

  • The GNUPLOT VERSION is "Version 4.4 patchlevel 3, last modified March 2011, System: MS-Windwos 32 bit". This seems to be included in the MXE Windows installation from mxeoctave.osuv.de.
  • I didn't find any way to find out the actual name of the DEFAULT FONT used by Octave, gnuplot or fltk. Can you give me a hint how I can get this information?
  • With GNUPLOT I tried some different font names like this:

    graphics_toolkit gnuplot
    text (0.5,0.5, 'A \0 B', 'fontname', '*')
    text (0.5,0.5, 'A \0 B', 'fontname', 'arial')
    text (0.5,0.5, 'A \0 B', 'fontname', 'times')

The result was: The diamater sign always IS printed properly. The only problem with gnuplot is, that an unnecessary warning message is issued.

  • With FLTK I also tried some font names:

    graphics_toolkit fltk
    text (0.5,0.5, 'A \0 B', 'fontname', '*')
    text (0.5,0.5, 'A \0 B', 'fontname', 'arial')
    text (0.5,0.5, 'A \0 B', 'fontname', 'times')

The result was: The diameter sign is NOT printed with many font names I have tried. A (some times different number of) warning messages are issued, which is appropriate in this case.

  • With FLTK I did find one font name that does work:

graphics_toolkit fltk
text (0.5,0.5, 'A \0 B', 'fontname', 'cambria')
With this font (maybe there are other ones that do work, but I did try a couple of them) the diameter sign IS properly displayed on screen. But still the unecessary warning message is issued (like with Gnuplot).

As said at the beginning, I suspect this whole issue is "only" about a change in the default font name, that Octave tries to use. Can this happen? How do I find out which font name Octave is using as default font?

Hartmut <hardy>
Fri 21 Nov 2014 12:05:52 AM UTC, comment #1: 

The FLTK toolkit has a TeX interpreter which only works for the onscreen display of special characters.  There is a separate issue report filed about the wish to extend the TeX interpreter to printed characters.

As for gnuplot, it does work just fine for me on a Linux PC and for you on a different installation.

I would suggest starting by finding out which gnuplot version is being used.  Another key is the font that is being used.  You might try setting it to something you know exists on your computer and has the correct glyph (Unicode 2298 Circled Division Slash).

For example, I don't get an error if I use the default font for gnuplot.  But, I do if I use a named font.

octave:1> graphics_toolkit gnuplot
octave:2> text (0.5,0.5, 'A \0 B', 'fontname', '*')
octave:3> text (0.5,0.5, 'A \0 B', 'fontname', 'arial')
warning: ft_render: skipping missing glyph for character '2298'
warning: ft_render: skipping missing glyph for character '2298'

Rik <rik5>
Project Administrator
Thu 20 Nov 2014 10:00:23 PM UTC, original submission:  

Here is a small script to show the behavior:

graphics_toolkit gnuplot
% graphics_toolkit fltk
close all;

I get the behavior with the current Octave MXE compilation 3.8.2-3 for Windows (source: mxeoctave.osuv.de). I have one PC that throws this warning/error, another Windows installation of the very same Octave MXE version does not throw this warning/error. Under Linux (yet another different PC) I do not get the warning message either.

Here is what happens on my Windows machine that throws an error:

  • If I print the diameter sign in gnuplot, I get a warning message "warning: ft_render: skipping missing glyph for character '2298'". But the diameter sign is properly displayed in the plot window.
  • If I run the script, but change to fltk, then I get the very same warning message in my terminal window as with gnuplot. But additionally the diameter sign will NOT be printed in the plot window. (This is why I use the word "error" here.)

Because in general fltk is able to produce this latex symbol (diameter sign) in Octave 3.8.2 under Linux as well as under Windows, I report this as a bug. I also concluded, that it's not (only) a gnuplot problem

I suspect, that the wrong behavior is due to some specific setting of my Windows PC, let me know what information you need on this.

Hartmut <hardy>


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

Attach Files:

Attached Files
file #46494:  t1_Screenshot-Matlab.jpg added by hardy (51KiB - image/jpeg)
file #46495:  t1_matlab.pdf added by hardy (17KiB - application/pdf)
file #46479:  t2.pdf added by dasergatskov (10KiB - application/pdf)
file #42181:  symb.pdf added by dasergatskov (39KiB - application/pdf)
file #42177:  symb.png added by dasergatskov (30KiB - image/png)
file #42178:  symb.svg added by dasergatskov (51KiB - image/svg+xml)
file #42165:  symboltest.m added by pantxo (2KiB - text/x-objcsrc)
file #42162:  symboltest.m added by pantxo (2KiB - text/x-objcsrc)
file #38816:  mu.png added by pantxo (7KiB - image/png)
file #32627:  plot_matlab.jpg added by hardy (195KiB - image/jpeg)
file #32628:  plot_gnuplot.jpg added by hardy (189KiB - image/jpeg)
file #32629:  plot_fltk.jpg added by hardy (71KiB - image/jpeg)


   bug dependencies.

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by pantxo (Updated the item)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by hardy (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 19 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-07-21 mmuetzel StatusConfirmed => Fixed
        Open/ClosedOpen => Closed
    2019-03-11 hardy Attached File- => Added t1_Screenshot-Matlab.jpg, #46494
        Attached File- => Added t1_matlab.pdf, #46495
        Attached File- => Added t1_matlab_(differentPlotCommand).pdf, #46496
    2019-03-09 dasergatskov Attached File- => Added t2.pdf, #46479
    2019-03-03 mtmiller Carbon-CopyRemoved 80942 => -
    2018-05-01 mtmiller Release3.8.2 => dev
    2017-10-17 dasergatskov Attached File- => Added symb.pdf, #42181
    2017-10-17 dasergatskov Attached File- => Added symb.png, #42177
        Attached File- => Added symb.svg, #42178
    2017-10-16 pantxo Attached File- => Added symboltest.m, #42165
    2017-10-15 pantxo Attached File- => Added symboltest.m, #42162
    2016-10-26 pantxo Attached File- => Added mu.png, #38816
    2014-12-30 rik5 Dependencies- => Depends on bugs #43907
    2014-12-29 rik5 StatusNone => Confirmed
    2014-12-09 hardy Attached File- => Added plot_matlab.jpg, #32627
        Attached File- => Added plot_gnuplot.jpg, #32628
        Attached File- => Added plot_fltk.jpg, #32629

    Back to the top

    Powered by Savane 3.5