I've create a patch

https://savannah.gnu.org/patch/index.php?8696

that uses utf-8 encoding for all but the PostScript class of gnuplot terminals.  This fixes Qt behavior for me.  If it breaks some of the other terminals, I'll investigate what the problem might be in gnuplot for those terminals.

@Rik I'm seeing the same type of behavior as far as fonts.  The gnuplot documentation mentions that fonts vary according to terminal, but the 'encoding' command exists to provide the best consistency.  I will look this evening at trying to use utf8 encoding 2205 rather than "{/Symbol \\306}" to make all the gnuplot terminals recognize empty set, at least for default or common fonts.

Oh, also, I don't know whether what I did there is the right way to temporarily select the symbol font.  Is it really called "Symbol"?

The once-per-session call is an advantage in my mind.  The code is called just once, rather than every time there is a missing glyph.

I don't know why the qt terminal appears to underperform.  I used

graphics_toolkit qt
text (0.5,0.6, '\0', 'fontname', 'Symbol')

and the symbol appears correctly.  But when I do

setenv ('GNUTERM', 'qt')
graphics_toolkit gnuplot
text (0.5,0.6, '\0', 'fontname', 'Symbol')

the symbol appears as a box.  The 'qt' terminal for gnuplot has been under heavy development.  Maybe this has gotten fixed in gnuplot 5.0?

It's annoying, but I'm not sure its worth the programmer time.  The warning is issued from deep within the C++ code and finding out at that point whether gnuplot is the active toolkit by querying the figure's _graphic_toolkit_ property seems like a pain.

On the other hand, maybe you could cheat a little.  The code in txt-eng-ft.cc for emitting the warning is

static void
gripe_missing_glyph (FT_ULong c)
{
  warning_with_id ("Octave:missing-glyph",
                   "ft_render: skipping missing glyph for character '%x'",
                   c);
}

Maybe when the toolkit is switched to gnuplot, the warning ID Octave:missing-glyph is turned off.  This would be on a global, not a per-figure, basis but it could be done quickly in an m-file and would only be called once per session.

Since gnuplot is on its way out as a toolkit, I don't think we need to devote a lot of resources to this.  If no one can see an easy fix then I am fine to mark this as "Won't Fix".

For the OpenGL side, it might be nice to figure out a way to quiet the warning stream.  Right now the error is doubly reported: 1) when text extents are caluclated, and 2) when the text is actually rendered and drawn on screen.  See below.

close all
graphics_toolkit fltk
text (0.5, 0.5, 'Hello \0 World', 'fontname', 'arial')
warning: ft_render: skipping missing glyph for character '2205'
warning: called from
    text at line 148 column 12
warning: ft_render: skipping missing glyph for character '2205'

@jwe: Your example doesn't specify a font so it uses '*' or whatever the default is on your system.  On my system the default happens to have the U+2205 glyph so no warning is produced.  That's why I had to specifically switch to a font like Arial which lacks the empty set symbol.

text (0.5, 0.5, 'Hello \0 World', 'fontname', 'Arial')
warning: ft_render: skipping missing glyph for character '2205'
warning: called from
    text at line 148 column 12
warning: ft_render: skipping missing glyph for character '2205'

I think there is another bug report open somewhere about the difference between Matlab and Octave with respect to symbolic characters.  Matlab uses the Symbol font whenever it encounters one of the Tex sequences.  This has its pros and cons.  On the pro side, the Symbol font includes the most commonly used mathematical symbols and Adobe's Symbol font is one of those base fonts that is almost always present; Printed output through Postscript will therefore almost always work.  On the other hand, many fonts have a lot of the symbols already.  For example, the Greek letters are always present.  It is visually desirable to stay within a font family because the use of serifs will match, the inter-character spacing will match, etc.  From our side, it is also easier to code.  Otherwise, the calculation of text extents becomes a long exercise where we would have to cycle over each fragment of the text and calculate the extent given the particular font in place and then sum everything at the end.  Right now we just set the font and the text and pass it to FreeType to calculate the extent in one go.

As I recall freetype was used to compute the extent of the text object even when gnuplot is used.  Is there some other way that this job can be done?  Or a better way to use freetype to compute the extent when symbols appear in the text but the font is selected to be something other than the symbol font?  Should we just be telling freetype to use the symbol font when processing symbol characters if a specific font is selected?  I see that

graphics_toolkit gnuplot
text (0.5, 0.5, '\0')

doesn't produce the warning.  It also doesn't show the empty set symbol for me, though it does work correctly with fltk or qt.

If we want to avoid freetype entirely when using gnuplot, then is there some way to ask gnuplot for the extent of a text object that it displays?

This isn't a bug.  That warning appears regardless of toolkit.  That motivated me to find the source of the 2205, so I changed the interpreter of the text from 'tex' to 'none' and then got the expected text \0 on the plot:

>> h = text (0.5, 0.5, '\0', 'fontname', 'arial')
warning: ft_render: skipping missing glyph for character '2205'
warning: called from
    text at line 148 column 12
h = -6.3267
>> set(h, 'interpreter', 'none')
>> set(h, 'interpreter', 'tex')
warning: ft_render: skipping missing glyph for character '2205'
>>

For Tex, \0 means empty set.  (Consult with this guy: https://savannah.gnu.org/bugs/?39828.)  So that is where the 2205 is coming from.  That's the empty set character and it doesn't exist in the arial font.

Is Tex supposed to be the default text interpreter?

The other part of this discussion was the behavior of switching between graphics tool kits and/or some way of changing all open figures at once.  Do we want to pursue that (and retitle bug report), or is it fine as is?

This report has gone off in a very different direction since the original submission.  The original bug I reported remains and doesn't appear to be related to switching toolkits.  See below where all figures are emphatically closed and the gnuplot toolkit is properly initialized.

octave:19> close all force
octave:20> graphics_toolkit gnuplot
octave:21> text (0.5, 0.5, '\0', 'fontname', 'arial')
warning: ft_render: skipping missing glyph for character '2205'
warning: called from
    text at line 148 column 12

The toolkit in use is recorded on a per figure basis in the _graphics_toolkit_ property.  graphics_toolkit.m is used to switch the default toolkit for all newly created figures, or to switch selected figures from one toolkit to another.  This works well for the common use cases.  If you want to switch over all figures, just use findobj() to get the list, and pass it to graphics_toolkit()

hf = findobj ("type", "figure");
graphics_toolkit (hf, "new_toolkit");

It pays to take a look at the documentation and code.
The first observation is this from the end of the help doc:

  When called with a single input NAME set the default graphics
  toolkit to NAME.  If the toolkit is not already loaded, it is
  initialized by calling the function '__init_NAME__'.  If the first
  input is a list of figure handles, HLIST, then the graphics toolkit
  is set to NAME for these figures only.


So, it appears that the author thought that switching toolkits
for open figures should work.

Does anyone have real evidence that it does?

I guess I was thinking

graphics_toolkit ([], NAME)

should change just the default while

graphics_toolkit (NAME)

changes the toolkit for all figures and the default.  That has its problems too.

Also, maybe I shouldn't have called that a bug because the __graphics_toolkit__ property is technically hidden.  The way to make the toolkit change would be:

graphics_toolkit ('gnuplot')
text (0.5, 0.5, 'HI', 'fontname', 'arial')
graphics_toolkit ([1], 'qt')

and that does in fact work.  Still, it seems

set(1, '__graphics_toolkit__', 'qt')

shouldn't error out.

Of course, the closing of all open figures in graphics_toolkit
could be preceded by a y/n question to to allow users to
decide not to continue with the toolkit change if that is
what they prefer. Or, if people prefer it, graphics_toolkit
could just output a message saying "toolkits may not be
changed while figures are open" and then exit. Actually, it
seems to me that this later choice is best. Simpler and cleaner.

This definitely needs some thought.

Simplest would be to close all current figures when
(before) the toolkit is changed. The alternatives of
either switching the active figures or allowing more
than one toolkit to be running at the same time seem
both hard to implement and confusing.

There may be other requirements that people may think
could be useful.

But, in the short run it might be best to
simply put code near the
beginning of graphics_toolkit.m which closes all
figures. It appears that close("all force") may be
right, but the documentation suggests delete() as
an alternative which avoids possible delay or hang.
But, it is not explained how to do the equivalent of
"close all" or "close force" if using delete().
Doing this will tend to avoid more bug reports about
weird things happening when the graphics_toolkit
is changed while figures are open.

Since Matlab does not provide graphics_toolkit() or its
equivalent there should be no compatibility issue.

The render code for OpenGL is being called, despite the fact that a different toolkit is set up.  This produces an annoying message and is certainly a performance hit if we execute both sets of code and then keep only one.

Sample code:

graphics_toolkit gnuplot
text (0.5, 0.5, '\0', 'fontname', 'arial')
warning: ft_render: skipping missing glyph for character '2205'
warning: called from
    text at line 148 column 12

I ran Octave under gdb and set a breakpoint before it got to print the warning message.  What you can see is that the text.m file calls _go_text_ which then starts to initialize a graphics object by setting various properties.  When the fontname is set the render code gets processed, instead of just setting the field to the desired value.

#0  ft_render::process_character (this=0x10f9fd8, code=8709, previous=0)
    at corefcn/txt-eng-ft.cc:515
#1  0x00007ffff7727ade in ft_render::visit (this=0x10f9fd8, e=...) at corefcn/txt-eng-ft.cc:810
#2  0x00007ffff74410ee in text_element_symbol::accept (this=0x159ee50, p=...)
    at corefcn/txt-eng.h:359
#3  0x00007ffff77295c3 in text_processor::visit (this=0x10f9fd8, e=...)
    at corefcn/txt-eng.h:325
#4  0x00007ffff7726d4b in ft_render::visit (this=0x10f9fd8, e=...) at corefcn/txt-eng-ft.cc:682
#5  0x00007ffff744111e in text_element_list::accept (this=0x158cd50, p=...)
    at corefcn/txt-eng.h:360
#6  0x00007ffff7727e22 in ft_render::render (this=0x10f9fd8, elt=0x158cd50, box=...,
    rotation=0) at corefcn/txt-eng-ft.cc:855
#7  0x00007ffff7728c52 in ft_render::text_to_pixels (this=0x10f9fd8, txt=..., pixels_=...,
    box=..., _halign=0, valign=1, rotation=0, interpreter=...) at corefcn/txt-eng-ft.cc:986
#8  0x00007ffff7546740 in text::properties::update_text_extent (this=0x10f81c0)
    at corefcn/graphics.cc:7909
#9  0x00007ffff757abfa in text::properties::update_fontname (this=0x10f81c0)
    at corefcn/graphics.h:8327
#10 0x00007ffff75796ea in text::properties::set_fontname (this=0x10f81c0, val=...)
    at corefcn/graphics.h:7974
#11 0x00007ffff74bc934 in text::properties::set (this=0x10f81c0, pname_arg=..., val=...)
    at corefcn/graphics-props.cc:3259
#12 0x00007ffff7566bd1 in base_graphics_object::set (this=0x10f81b0, pname=..., pval=...)
    at corefcn/graphics.h:2976
#13 0x00007ffff745a5c2 in graphics_object::set_value_or_default (this=0x7fffffffa850,
    name=..., val=...) at corefcn/graphics.cc:2316
#14 0x00007ffff7459f35 in graphics_object::set (this=0x7fffffffa850, args=...)
    at corefcn/graphics.cc:2083
#15 0x00007ffff745aeba in xset (h=..., args=...) at corefcn/graphics.cc:2486
#16 0x00007ffff7554102 in make_graphics_object (go_name=..., integer_figure_handle=false,
#17 0x00007ffff7555495 in F__go_text__ (args=...) at corefcn/graphics.cc:10319
#18 0x00007ffff718d0b3 in octave_builtin::do_multi_index_op (this=0x6e4ca0, nargout=1,
    args=..., lvalue_list=0x0) at octave-value/ov-builtin.cc:132
#19 0x00007ffff718cd8c in octave_builtin::subsref (this=0x6e4ca0, type=..., idx=...,
    nargout=1, lvalue_list=0x0) at octave-value/ov-builtin.cc:65
#20 0x00007ffff718cc7a in octave_builtin::subsref (this=0x6e4ca0, type=..., idx=..., nargout=1)
    at octave-value/ov-builtin.cc:47
#21 0x00007ffff718dbd9 in octave_builtin::subsref (this=0x6e4ca0, type=..., idx=...)
    at octave-value/ov-builtin.h:62
#22 0x00007ffff726fffb in octave_value::subsref (this=0x7fffffffb1b0, type=..., idx=...,
    nargout=1) at octave-value/ov.cc:1301
#23 0x00007ffff72700f6 in octave_value::subsref (this=0x7fffffffb1b0, type=..., idx=...,
    nargout=1, lvalue_list=0x0) at octave-value/ov.cc:1314
#24 0x00007ffff72df02e in tree_index_expression::rvalue (this=0xcf33e0, nargout=1,
    lvalue_list=0x0) at parse-tree/pt-idx.cc:437
#25 0x00007ffff72de5d3 in tree_index_expression::rvalue (this=0xcf33e0, nargout=1)
    at parse-tree/pt-idx.cc:284
#26 0x00007ffff72df458 in tree_index_expression::rvalue1 (this=0xcf33e0, nargout=1)
    at parse-tree/pt-idx.cc:466
#27 0x00007ffff72c98d0 in tree_simple_assignment::rvalue1 (this=0xcf36f0)
    at parse-tree/pt-assign.cc:85
#28 0x00007ffff72d7df8 in tree_evaluator::visit_statement (this=0x7ffff7dd4478, stmt=...)
    at parse-tree/pt-eval.cc:744
#29 0x00007ffff72f8fbc in tree_statement::accept (this=0xcf3730, tw=...)
    at parse-tree/pt-stmt.cc:178
#30 0x00007ffff72d8064 in tree_evaluator::visit_statement_list (this=0x7ffff7dd4478, lst=...)
    at parse-tree/pt-eval.cc:794
#31 0x00007ffff72f95dc in tree_statement_list::accept (this=0xcf1460, tw=...)
    at parse-tree/pt-stmt.cc:291

The backtrace continues on but it is uninteresting.  The good stuff starts at #17.