bugGNU Octave - Bugs: bug #43907, OpenGL render code called even...


bug #43907: OpenGL render code called even when gnuplot is graphics_toolkit

Submitter:  Rik <rik5>
Submitted:  Tue 30 Dec 2014 10:41:00 PM UTC
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * GNU/Linux
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Sat 19 Nov 2016 11:30:29 AM UTC, comment #29: 

This behavior seems to be still present in Octave 4.2.0.

Hartmut <hardy>
Fri 03 Jul 2015 11:02:50 PM UTC, comment #28: 

I've create a patch


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.

Dan Sebald <sebald>
Wed 01 Jul 2015 11:42:50 PM UTC, comment #27: 

There is a demo for gnuplot called 'enhanced_utf8.dem':


which seems to work for Qt and WXT (and the linked test page PNG must have worked correctly).  For x11 I'm seeing empty dotted squares where the symbols should be.  For PNG terminal I'm seeing ASCII encoding which look bad, but it is because the font can't be found:

gnuplot> set term 'png' enhanced
Terminal type set to 'png'
Could not find/open font when opening font "arial", using internal non-scalable font

But in some sense, that is an OK behavior, i.e., gnuplot issuing a warning as opposed to Octave.

If one looks at the demo page link, the characters are non-ascii symbols.  Are those UTF-8 encodings being handled by the web browser?  gvim shows the symbols as well.

I'm wondering if Octave handles these symbols internally using UTF-8, e.g., 2205, (does it?) rather than skip the symbol, maybe just put the unicode value in the character stream and instruct gnuplot to use enhanced utf-8 encoding.  Then, one gets what they get whether it is the Qt/FLTK/gnuplot toolkit.

Notice that the warning message, regardless of terminal, can standout when every character is acknowledged:

>> text (0.5,0.6, '\0 ABCDEFGabcdefg', 'fontname', 'Symbol')

warning: ft_render: skipping missing glyph for character '41'
warning: called from
    text at line 148 column 12
warning: ft_render: skipping missing glyph for character '42'
warning: ft_render: skipping missing glyph for character '43'
warning: ft_render: skipping missing glyph for character '44'
warning: ft_render: skipping missing glyph for character '66'
warning: ft_render: skipping missing glyph for character '67'

Dan Sebald <sebald>
Wed 01 Jul 2015 10:24:09 PM UTC, comment #26: 

@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.

Dan Sebald <sebald>
Wed 01 Jul 2015 10:17:44 PM UTC, comment #25: 

Rik:On my Fedora 22 system with gnuplot 5.0:

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

produces the correct graphic as in the last box in
Table 15.1 in the Manual.
I get:

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

Unknown or ambiguous terminal name 'qt'


Michael Godfrey <godfrey>
Project Member
Wed 01 Jul 2015 09:27:47 PM UTC, comment #24: 

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"?

John W. Eaton <jwe>
Project Administrator
Wed 01 Jul 2015 09:26:47 PM UTC, comment #23: 

On my system, "arial" ultimately becomes "Liberation Sans" so that's what the ft_render class sees as the font.

@rik: aren't we already iterating over the string one character at a time to find the glyphs?

Would something like the attached patch work OK?

In addition to trying a font substitution, we could also just use a space character if we are computing the bounding box and the font doesn't have the requested character.  It seems like that would be reasonable since it is probably OK in most cases if the bounding box is not perfect.

(file #34356)

John W. Eaton <jwe>
Project Administrator
Wed 01 Jul 2015 08:59:42 PM UTC, comment #22: 

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?

Rik <rik5>
Project Administrator
Wed 01 Jul 2015 07:56:19 PM UTC, comment #21: 

That doesn't sound like a good solution, especially the once per session restriction.

In some sense, the WXT terminal is the exception to the rule for FLTK and Qt toolkits and gnuplot terminals.  It works when the expectation is it shouldn't...or Qt/FLTK isn't working with the arial font when it is expected to.

"Skipping" the character in txt-eng-ft.cc suggests the routine doesn't know what to do, so it is going to pass the escape characters on down the line in hopes that something down stream knows how to interpret it.  And that is the case for the gnuplot WXT terminal.  Perhaps what this routine should do is simply absorb those characters--remove them from the character stream and then in all cases with the arial font, empty set will not be present.  That's easy to program, and it is consistent.

The consequence is that the user of gnuplot toolkit will have to pick a font for which that empty set symbol exists.  Otherwise, we'll have to figure out how to sooner avoid calling the  FreeType process_character() function in the case of gnuplot toolkit.

More worrisome is the fact that this fails:

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

in the gnuplot Qt terminal.  That seems like a bug.

Dan Sebald <sebald>
Wed 01 Jul 2015 06:54:12 PM UTC, comment #20: 

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'",

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.

Rik <rik5>
Project Administrator
Wed 01 Jul 2015 06:25:35 PM UTC, comment #19: 

Oh, WXT.  I should have thought of that.  I suppose that terminal understands FreeType fonts where x11 and Qt don't.  Is it adequate to just suppress the warning message if the Figure's toolkit is gnuplot?  Apparently the gnuplot toolkit is placing the desired text in the command.

With the warning message gone, we could rewrite gnuplot toolkit so that it uses a font that has the symbol characters whenever /Symbol is placed in the text.  That way the symbols always come out correct.

There is also the ability to place simple programming instructions in gnuplot:

 New syntax:
       if (<condition>) { <commands>;
       } else {
 Old syntax:
       if (<condition>) <command-line> [; else if (<condition>) ...; else ...]

which would allow instructing gnuplot to check whether the terminal is WXT.  If so, use the font, if not use a symbol font.

Dan Sebald <sebald>
Wed 01 Jul 2015 06:02:38 PM UTC, comment #18: 

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'

Rik <rik5>
Project Administrator
Wed 01 Jul 2015 05:50:30 PM UTC, comment #17: 

@Dan: The empty set does display for me, but I am using the 'wxt' terminal.

close all
setenv ('GNUTERM', 'wxt')
graphics_toolkit gnuplot
text (0.5, 0.5, 'Hello \0 World', 'fontname', 'Arial')

Rik <rik5>
Project Administrator
Wed 01 Jul 2015 05:45:31 PM UTC, comment #16: 

@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.

Rik <rik5>
Project Administrator
Wed 01 Jul 2015 05:38:05 PM UTC, comment #15: 

OK, I see what you are saying now, I guess.  "ft" of ft_render means Freetype.

I'm still not clear, however, about gnuplot's eventual use of a font because from the perspective of what I'm seeing the warning makes sense.  I don't see an empty set symbol in gnuplot.  Just a square box (qt terminal, or AE symbol if I use x11 terminal).  Here is the translated line as it appears in the gnuplot toolkit intermediate file:

set label "{/Symbol \\306}" at  5.000000000000000e-01,5.000000000000000e-01 left rotate by 0.000000 offset character -0.000000,0.000000 font "arial,10" enhanced front textcolor rgb "#000000";

The Octave script generating this is:

    ## special case for "\0"  and replace with empty set "{/Symbol \306}'
    if (strncmp (m{i}, '\0', 2))
      str = [str(1:s(i) - 1) '{/Symbol \306}' str(s(i) + 2:end)];

Because the '{/Symbol \306}' is in single quotes, it must add an extra backslash, i.e., set label "{/Symbol \\306}".  There is also this

  ## empty set, not circled slash division operator as in FLTK.
  sym.oslash = '{/Symbol \306}';

in the _setup_sym_table_ () function.

So, gnuplot is being instructed to use the "arial,10" font.  Whether it can determine that is Freetype font and where to look, I have no idea.  On your system you are seeing an empty set character?  If I switch to gnuplot 4.6.0, I see on the plot {/Symbol \306} with just the single backslash.

Dan Sebald <sebald>
Wed 01 Jul 2015 05:06:35 PM UTC, comment #14: 

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?

John W. Eaton <jwe>
Project Administrator
Wed 01 Jul 2015 04:18:46 PM UTC, comment #13: 

The issue is that Freetype is not used for rendering text with gnuplot, it is an OpenGL feature.  Ergo, Octave shouldn't be calling OpenGL code when the toolkit is gnuplot.  Certainly the programmer using gnuplot doesn't care one whit about warnings from ft_render because the empty set symbol is drawn just fine with gnuplot, despite the superfluous warning.  This is because Matlab and gnuplot use the Symbol font, rather than the specified font (like Arial), to render mathematical symbols.  And the Symbol font does have an empty set representation.

Tex is the default interpreter for text() objects.

I would file a different issue report for changing the way that graphics_toolkit() works.

Rik <rik5>
Project Administrator
Tue 30 Jun 2015 11:03:36 PM UTC, comment #12: 

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?

Dan Sebald <sebald>
Mon 29 Jun 2015 07:37:02 AM UTC, comment #11: 

What is the issue?  Is it the warning message?

warning: ft_render: skipping missing glyph for character '2205'

I was assuming that there is simply no glyph in whatever font set is chosen for character '\0', which I think means character 0.  Typically those low numbers are dodgy as far as glyphs, as ASCII alpha-numeric glyphs usually start much higher in the code book.  Why the code 2205 comes from '\0', I have no idea.

ft_render means font render, which is in txt-eng-ft.cc. 

ft_render::process_character (FT_ULong code, FT_UInt previous)
  FT_Face face = font.get_face ();
  FT_UInt glyph_index = 0;

  if (face)
      glyph_index = FT_Get_Char_Index (face, code);

      if (code != '\n'
          && (! glyph_index
              || FT_Load_Glyph (face, glyph_index, FT_LOAD_DEFAULT)))
          glyph_index = 0;
          gripe_missing_glyph (code);

Is that code related to OpenGL or just generic font rendering without reference to the destination of the font usage?  I don't see what the OpenGL issue is.  You'll have to explain further.

Dan Sebald <sebald>
Wed 24 Jun 2015 08:58:08 PM UTC, comment #10: 

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");

Rik <rik5>
Project Administrator
Wed 24 Jun 2015 06:17:48 AM UTC, comment #9: 

This example works on my system (enter commands one at a time):

graphics_toolkit ('gnuplot');


text (0.5, 0.5, 'HI', 'fontname', 'arial');

graphics_toolkit ([1], 'qt');

graphics_toolkit ()

Notice that the default doesn't change using the HNDL,NAME format.  I like this behavior.  I just wish there were some syntax for changing the default and all figures at the same time, which is the behavior it seems we were all expecting.

Here's another possibility.  Rather than empty set, would '0' make sense as a default?  Zero has special meaning, the root.  And right now there is no __graphics_toolkit__ property associated with the root:

>> get(5000, '__graphics_toolkit__')
error: get: invalid handle (= 5000)
>> get(1, '__graphics_toolkit__')
ans = qt
>> get(0, '__graphics_toolkit__')
error: get: unknown root property __graphics_toolkit__

We could slightly change the definition to be

graphics_toolkit(HNDL, NAME)  % Change just figures of HNDL
graphics_toolkit(0, NAME)     % Change the default
graphics_toolkit(NAME)        % Change the default and all figures

If a 0 happens to be in HNDL, then the default would change as well as the figures for whatever handles are in the array.  Shouldn't be a big change.  What do people think about the above behavior?

Dan Sebald <sebald>
Tue 23 Jun 2015 11:10:21 PM UTC, comment #8: 

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?

Michael Godfrey <godfrey>
Project Member
Tue 23 Jun 2015 10:49:03 PM UTC, comment #7: 

Right, since graphics_toolkit('qt') does not error in your
example there does not appear to be a bug of the kind
that you reported.
Whether there are other side effects of toolkit switching
while figures are open is still to be determined.

Until this is worked out, it would be safer to not allow
it. If a user wants to do comparisons it is pretty easy
to print the current figures  and then switch toolkits.
Cautious users would do this anyhow in order to make the
experiment reproducible.

Michael Godfrey <godfrey>
Project Member
Tue 23 Jun 2015 10:33:35 PM UTC, comment #6: 

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.

Dan Sebald <sebald>
Tue 23 Jun 2015 10:11:48 PM UTC, comment #5: 

I'm not sure about the yes/no question.  I tend to not like CLI commands to not pause so that they may be run in batch mode.

With a bit more investigation, I think this isn't as big an issue as first thought.  The figure seems to behave according to the setting of the __graphics_toolkit__ property.  Try, for example, from a fresh launch:

figure (1)
graphics_toolkit ('gnuplot')
text (0.5, 0.5, 'HI', 'fontname', 'arial')
set (1, '__graphics_toolkit__', 'qt')
set (1, '__graphics_toolkit__', 'gnuplot')

I'm seeing the figure window close and then reopen with the new toolkit with the "set()" commands.  I kind of like that, as it lets the user experiement a bit with different graphics toolkits.  I.e., have an example of both up at the same time.

In any case, with this behavior it is simply a matter of going through the list of figures and changing the property __graphics_toolkit__ to whatever the input of "graphics_toolkit(<input>)" is.  How about an option for graphics_toolkit()?

Currently the documentation indicates changing the NAME only changes the default.  If handles HLIST are input, then only the figures associated are changed but not the default.  It seems there should be a way to change all at once.  How about

graphics_toolkit ([], NAME)
graphics_toolkit (NAME, [])

Changes both the default toolkit and all open figures?

NOTE: There is a bug present in the code.  If "figure()" is not called initially after launch, a new toolkit name is not recognized:

>> graphics_toolkit ('gnuplot')
>> text (0.5, 0.5, 'HI', 'fontname', 'arial')
>> set (1, '__graphics_toolkit__', 'qt')
error: set___graphics_toolkit__: invalid graphics toolkit

Dan Sebald <sebald>
Tue 23 Jun 2015 09:30:15 AM UTC, comment #4: 

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.

Michael Godfrey <godfrey>
Project Member
Tue 23 Jun 2015 02:50:48 AM UTC, comment #3: 

I agree that a graphics toolkit change should close all the existing figure windows, but it would be nice to then re-plot the figures in the new toolkit.  Otherwise there will be some users caught be surprise and annoyed that their work has disappeared.

However, doesn't 'close all' end up discarding the figure contents?  Is it possible to reconstruct a plot from its property settings?  I think that may be the case in gnuplot, i.e., some kind of internal "drawnow" function.

It seems to me that every toolkit needs some type of "startup" method and some type of "shutdown" method that does the following:

startup) search for all existing figure descriptions with property settings, create associated windows and redraw

shutdown) go through the existing figure list and close the window but do not destroy the property/memory contents for the figure

Dan Sebald <sebald>
Mon 22 Jun 2015 10:40:55 PM UTC, comment #2: 

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.

Michael Godfrey <godfrey>
Project Member
Mon 22 Jun 2015 07:36:38 PM UTC, comment #1: 

I think the issue here has to do with an existing figure being present for the current figure number.  Continuing the example you have:

>> 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
>> graphics_toolkit qt
>> text (0.5, 0.5, 'HI', 'fontname', 'arial')

I see that the Qt plot is not created.  Instead, the gnuplot plot continues to be operated on.  However, create a new figure:

>> figure(2)
>> text (0.5, 0.5, 'HI', 'fontname', 'arial')

and a Qt window appears.

This (doesn't) works in the other direction as well.  That is, start out with Qt figure window, change to gnuplot graphics toolkit and the Qt figure is still active.

I think taht once a figure is created, the property for the render-er is still in the list.  The "graphics_toolkit" command probably needs to go through the list of existing windows and change the render

>> get(2,"__graphics_toolkit__")
ans = qt
>> get(1,"__graphics_toolkit__")
ans = gnuplot

That creates a conundrum, however.  Making that change would mean that two windows exist for Figure 1, for example.  So, in addition to changing the toolkit, perhaps it should delete the existing plot window and replot under the new toolkit?

Dan Sebald <sebald>
Tue 30 Dec 2014 10:41:00 PM UTC, original submission:  

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.

Rik <rik5>
Project Administrator


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

Attach Files:

Attached Files
file #34356:  diffs.txt added by jwe (1KiB - text/plain)


Depends on the following items: None found

   bug dependencies.


Carbon-Copy List
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by rik5 (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 project members can vote.





    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-07-01 jwe Attached File- Added diffs.txt, #34356
    2014-12-30 rik5 Dependencies- bugs #43651 is dependent

    Back to the top

    Powered by Savane 3.9