bugGNU Octave - Bugs: bug #53091, [MXE-Octave] new warning from...

 
 

bug #53091: [MXE-Octave] new warning from gnuplot

Submitter:  Avinoam Kalma <avinoam>
Submitted:  Wed 07 Feb 2018 04:55:28 PM UTC
   
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Avinoam 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

Wed 20 Feb 2019 08:11:31 PM UTC, comment #22: 

Thanks for pushing that change. Works for me.
Closing as fixed.

Markus Mützel <mmuetzel>
Group administrator
Wed 20 Feb 2019 03:29:13 PM UTC, comment #21: 

I pushed the change here

http://hg.savannah.gnu.org/hgweb/octave/rev/2a0004e7c574

Marking ready for test.

Pantxo Diribarne <pantxo>
Group Member
Tue 19 Feb 2019 10:44:24 PM UTC, comment #20: 

Thanks Markus.

Pantxo Diribarne <pantxo>
Group Member
Tue 19 Feb 2019 09:09:59 PM UTC, comment #19: 

In the Matlab Live Editor, I see the following:

>> axes()
>> ht = text (0, .5, '<cs;hfjnvrnq vklnroirg!:k,ncv lj', 'fontsize', 30);
>> ext1 = get (ht, 'extent')
ext1 =
   0    0.4438    1.2080    0.1124
>> set (ht, 'fontname', '*'); % Is this still allowed?
>> ext2 = get (ht, 'extent')
ext2 =
   0    0.4438    1.2080    0.1124
>> all (ext1 == ext2) % Same size? same aspect?
ans =
   1
get (ht, 'fontname') %'*' or 'Helvetica'
ans = '*'


No warnings, and the text displays fine (although clipped at the right edge of the figure).

Markus Mützel <mmuetzel>
Group administrator
Tue 19 Feb 2019 06:54:43 PM UTC, comment #18: 

Out of curiosity, has Matlab completely removed the use of the "*" placeholder or can it still be used to name The default font (that) depends on your operating system and locale [1]?
For example


ht = text (0, .5, '<cs;hfjnvrnq vklnroirg!:k,ncv lj',
           'fontsize', 30)
ext1 = get (ht, 'extent');
set (ht, 'fontname', '*');        % Is this still allowed?
all (ext1 == get (ht, 'extent'))  % Same size? same aspect?
get (ht, 'fontname')              %'*' or 'Helvetica'


[1] https://www.mathworks.com/help/matlab/ref/matlab.graphics.primitive.text-properties.html#budt_bq-1_sep_shared-FontName

Pantxo Diribarne <pantxo>
Group Member
Tue 19 Feb 2019 06:30:10 PM UTC, comment #17: 

In the Matlab Live Editor both return 'Helvetica'.

Replacing "Helvetica" by "*" in annotation.m like Pantxo suggested avoids the warnings for me. That looks like a reasonable change for the stable branch.

Markus Mützel <mmuetzel>
Group administrator
Tue 19 Feb 2019 06:13:46 PM UTC, comment #16: 

I think we should use the default "*" font for annotation objects. Hardcoding the font name was a bad design and we should not try to find a "better" one. There will always be systems where this or that font is not installed.

Now whether we want to follow Matlab and let "get (h, 'fontname')" return the name of the actual font that is used by default, is another question.

What does Matlab return here:

get (groot, 'defaulttextfontname') % This should be '*'
ht = text (.5, .5, 'TEXT');
get (ht, 'fontname')


Pantxo Diribarne <pantxo>
Group Member
Mon 18 Feb 2019 07:58:17 AM UTC, comment #15: 

Same results on Windows with Matlab R2018b:

>> hax = axes;
han = annotation('textbox', 'String', 'Test');
get(han, 'FontName')

ans =

    'Helvetica'


Markus Mützel <mmuetzel>
Group administrator
Mon 18 Feb 2019 01:05:37 AM UTC, comment #14: 

The annotation object has several subtypes.  See https://www.mathworks.com/help/matlab/ref/annotation.html.  The only ones that appear to have a "FontName" property are TextArrow and TextBox objects.  Testing with Matlab R2018b showed "Helvetica" was the default font, and that setting the "DefaultTextFontName" property affected the font used by TextArrow, TextBox objects.

Rik <rik5>
Group administrator
Sun 17 Feb 2019 10:42:50 PM UTC, comment #13: 

Can this be fixed with the fontconfig configuration that is shipped with Octave? Helvetica is a sensible default font since it is the default in the PostScript file format.

Is there a way in Matlab to configure the default font that is used for annotation objects? The documentation doesn't make it clear if there is. Is it taken from 'DefaultTextFontName' or 'DefaultAxesFontName'?

Mike Miller <mtmiller>
Group Member
Sun 17 Feb 2019 08:58:27 PM UTC, comment #12: 

Replacing "Helvetica" with "Calibri" in annotation.m also works well in Windows

Avinoam Kalma <avinoam>
Group Member
Sun 17 Feb 2019 07:23:03 PM UTC, comment #11: 

You're right: Almost every Windows system will see this warning. Unless Helvetica was installed manually.

But I don't think that we should change to Arial on all platforms. Afaik, Arial isn't available by default on Linux. So almost all Linux users would probably see this warning.

Also it would be interesting to see which default fonts Matlab uses on which platform. I am pretty sure this is Helvetica for Linux (and Mac?). On Windows, this is probably Arial. But it might also be Calibri which seems to have become the new default font in recent Windows versions.
If possible, we should use the same defaults for compatibility imho.

Markus Mützel <mmuetzel>
Group administrator
Sun 17 Feb 2019 04:22:48 PM UTC, comment #10: 

Just to clarify, there is no problem with "my" system,
because I am using the Windows MXE-Octave.

Second, it seems that the problem is from annotation.m
If we change the "Helvetica" to "Arial" everything is fine,
in Windows. I did not check in linux.
A simple patch attached.

(file #46295)

Avinoam Kalma <avinoam>
Group Member
Sun 17 Feb 2019 11:36:40 AM UTC, comment #9: 

The time until the release of Octave is quite short. This is "just" a warning and the replacement font used seems to be Arial anyway. Given these facts, I am re-targeting this bug to the development branch.
Maybe we can consider grafting any possible changes for a dot release of Octave 5.

If someone provides a changeset that prevents this warning without needing too intrusive changes in the next few days, it can still be considered for the final release.

Markus Mützel <mmuetzel>
Group administrator
Sat 16 Feb 2019 06:52:00 PM UTC, comment #8: 

Sounds like a plan.

That "Helvetica" in


function [str, f, s] = __maybe_munge_text__ (enhanced, obj, fld, ntrp)


looks to happen only when the fld variable is "displayname", i.e., obj.displayname.  I don't see "DisplayName" in properties anywhere.

Nonetheless, I put some text inside that _maybe_munge_text_ routine and although for the demo in question the "string" gets called, the "displayname" never does.  So, that particular "Helvetica" isn't being used in this case.  (But it should be changed, as you suggest.  Why even set the font here rather than use


     [f, s, fnt, it, bld] = get_fontname_and_size (obj);


?)

Yeah, I see "Helvetica" is specifically called out in the annotation.m demos.  I temporarily declared a handle to be recorded as global:


%!   global hh;
%!   hh = annotation ("textarrow", [x x0], [y y0], ...
%!               "string", lab{ii},  "fontsize", 20);


Looking at the global variable after test indicates:


    fontangle = normal
    fontname = Helvetica
    fontsize =  20
    fontunits = points
    fontweight = normal
    headlength =  10
    headstyle = vback2
    headwidth =  10
    horizontalalignment = left
    interpreter = tex
    linestyle = -
    linewidth =  0.50000
    position =

       2.0000e-01   5.0000e-01   3.0000e-01   5.5511e-17

    string = E


Creating some text object without a font results in:


    fontname = *


I don't know if there needs to be a font declared for the demo... unless the demo were trying to illustrate font properties, naming, sizing, substitution, etc.

Dan Sebald <sebald>
Sat 16 Feb 2019 05:43:51 PM UTC, comment #7: 

The problem is probably that we shouldn't use "Helvetica" on Windows (because it isn't installed by default).
It is used as the default font in annotation.m.
If I search the Octave sources for "Helvetica", it is also used in _gnuplot_draw_axes_.m and gl2ps-print.cc.
In _gnuplot_draw_axes_ at line 2328 we set "Arial" as a fall back font on Windows. A little bit further down in line 2386, "Helvetica" is used as a fall back font.

Maybe we should use "Arial" as the default font for Windows everywhere?
I wonder what Matlab is doing.


Markus Mützel <mmuetzel>
Group administrator
Sat 16 Feb 2019 05:21:20 PM UTC, comment #6: 

Good point.  I didn't understand that the Octave print script didn't even print with the change from bug #55648.

I've done


linux@ gnuplot
linux@ load 'after.gp'


and see no warning on my system.  (Perhaps warnings are directed somewhere else on my system, but I see plenty of warnings coming from GTK+ and the usual GUI framework, generally speaking, not from this particular Octave/gnuplot script.)  I've replaced "Helvetica" with "Sans", "Times", "BogusFont" and see no warnings.  The "Times" selection results in a font that does have serifs, so at least the substitution seems to make sense.

I don't think I'd consider this an Octave bug.  In fact, it isn't even a gnuplot bug, as I don't see the phrase "ugly output" in the gnuplot source tree anywhere.  I've cloned the Pango source

https://www.pango.org/Download
git clone https://gitlab.gnome.org/GNOME/pango.git

and here's where I see the phrase 'ugly output':


linux@ ~/src/pango/pango $ grep "ugly output" */*
grep: docs/xml: Is a directory
pango/pangocairo-font.c:          g_warning ("failed to create cairo %s, expect ugly output. the offending font is '%s'",
pango/pango-context.c:              g_warning ("failed to choose a font, expect ugly output. engine-type='%s', script='%s'",
pango/pangocoretext-fontmap.c:                             "weight/stretch as fallback, expect ugly output.",
pango/pango-fontmap.c:                     "expect ugly output.", ctmp1, ctmp2);
pango/pango-fontmap.c:                     "expect ugly output.", ctmp1, ctmp2);
pango/pangowin32-fontmap.c:                     "expect ugly output.", ctmp1, ctmp2);
pango/pangowin32-fontmap.c:                     "expect ugly output.", ctmp1, ctmp2);
pango/shape.c:                  g_warning ("shaping failure, expect ugly output. shape-engine='%s', font='%s', text='%.*s'",


So it is a Pango warning.

Why Avinoam sees the warning and I don't, I have no idea.  A.K., when you started seeing this warning, had you just finished a system upgrade or something?  Perhaps a linux bundle decided to compile Pango or gnuplot in some kind of verbose mode or something.

I've searched the Pango code for g_warning but don't see it inside a header file, so it's definition must come glib:

https://developer.gnome.org/glib/unstable/glib-Message-Logging.html#g-warning

and I'm guessing there is some way to compile with/without warning messages and perhaps on Avinoam's system the glib warnings are appearing somehow.  However, I do imagine on my system there is all kinds of font substitution going on as well.

Dan Sebald <sebald>
Sat 16 Feb 2019 11:09:06 AM UTC, comment #5: 

@Dan: Attached is the output of running the following with the patch from bug #55648:

graphics_toolkit gnuplot
demo annotation 1
drawnow ("pngcairo", "annotation", "after.gp")


I don't know how to call drawnow to produce the debug file without the patch from bug #55648.

Is this what you were asking for?

(file #46280)

Markus Mützel <mmuetzel>
Group administrator
Thu 14 Feb 2019 04:57:43 PM UTC, comment #4: 

This is a gnuplot warning, merely saying it can't find the requested font.  The best thing to do is call drawnow() to get a look at the actual gnuplot code generated before/after the application of the patch for bug #@55648.  It could be that the patch is actually doing something correct such that the font request is now complete, or vice versa it is doing something wrong such that the requested font string is incorrect.  Look at

"help drawnow"

sending the gnuplot script code to files before.gp and after.gp.  We can then see if the gnuplot code makes sense.

Dan Sebald <sebald>
Wed 13 Feb 2019 09:04:31 PM UTC, comment #3: 

Reopen, since I get this message after using the patch from
bug #55648

Avinoam Kalma <avinoam>
Group Member
Sat 12 Jan 2019 12:04:43 AM UTC, comment #2: 

No response.  Assuming this is no longer an issue.

Rik <rik5>
Group administrator
Mon 31 Dec 2018 04:41:03 PM UTC, comment #1: 

@Avinoam: Is this warning still present?  I think Octave tries to use FreeSans as the default font now and we ship that font with MXE Octave.

Rik <rik5>
Group administrator
Wed 07 Feb 2018 04:55:28 PM UTC, original submission:  


>> graphics_toolkit gnuplot
>> demo ('annotation', 1);
annotation example 1:
clf; axes ("visible", "off");
annotation ("textbox", [.25 .9 .5 .09], "string", ...
             {"Right Click on annotation objects", ...
              "to customize their appearance"}, ...
             "horizontalalignment", "center", "fitboxtotext", "off");
annotation ("ellipse", [.2 .2 .6 .6], "linewidth", 4);
ang = pi/2:-pi/2:-pi;
lab = {"N", "W", "S", "E"};
x0 = 0.5;
y0 = 0.5;
r = 0.3;
for ii = 1:4
   x = r * cos (ang(ii)) + x0;
   y = r * sin (ang(ii)) + y0;
   annotation ("textarrow", [x x0], [y y0], ...
               "string", lab{ii},  "fontsize", 20);
endfor

h = annotation ("doublearrow", [x0 x0], [y0-r y0+r], ...
                 "head1style", "diamond", "head1length", 60, ...
                 "head2style", "diamond", "head2length", 60);

>>
(gnuplot.exe:14344): Pango-WARNING **: couldn't load font "Helvetica Not-Rotated 200", falling back to "Sans Not-Rotat
ed 200", expect ugly output.

(gnuplot.exe:14344): Pango-WARNING **: couldn't load font "Helvetica Not-Rotated 400", falling back to "Sans Not-Rotat
ed 400", expect ugly output.


This is a new warning, did not appear in previous versions.

Avinoam Kalma <avinoam>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #46295:  annot.diff added by avinoam (1KiB - application/octet-stream)
file #46280:  after.gp added by mmuetzel (12KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by avinoam (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 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-02-20 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2019-02-20 pantxo StatusNone Ready For Test
    2019-02-17 avinoam Attached File- Added annot.diff, #46295
    2019-02-17 mmuetzel Release5.0.91 dev
    2019-02-16 mmuetzel Attached File- Added after.gp, #46280
    2019-02-13 avinoam StatusFixed None
        Open/ClosedClosed Open
        Releasedev 5.0.91
    2019-01-12 rik5 StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2018-12-31 rik5 StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code