bugGNU Octave - Bugs: bug #52150, all plot functions throw errors...

 
 

bug #52150: all plot functions throw errors when built with --without-fontconfig

Submitter:  Mike Miller <mtmiller>
Submitted:  Sun 01 Oct 2017 11:18:17 PM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 07 Oct 2017 04:14:32 PM UTC, comment #19: 

@Mike: On Fedora those fonts are:

  ls -lgo /usr/share/fonts/gnu-free/
total 10952
-rw-r--r--. 1  318512 Jul 26 11:32 FreeMonoBoldOblique.ttf
-rw-r--r--. 1  319480 Jul 26 11:32 FreeMonoBold.ttf
-rw-r--r--. 1  418844 Jul 26 11:32 FreeMonoOblique.ttf
-rw-r--r--. 1  614492 Jul 26 11:33 FreeMono.ttf
-rw-r--r--. 1  344856 Jul 26 11:33 FreeSansBoldOblique.ttf
-rw-r--r--. 1  424600 Jul 26 11:33 FreeSansBold.ttf
-rw-r--r--. 1  776496 Jul 26 11:33 FreeSansOblique.ttf
-rw-r--r--. 1 1623088 Jul 26 11:34 FreeSans.ttf
-rw-r--r--. 1  616756 Jul 26 11:34 FreeSerifBoldItalic.ttf
-rw-r--r--. 1 1356740 Jul 26 11:34 FreeSerifBold.ttf
-rw-r--r--. 1  951920 Jul 26 11:35 FreeSerifItalic.ttf
-rw-r--r--. 1 3423064 Jul 26 11:36 FreeSerif.ttf

rpm -qf /usr/share/fonts/gnu-free/FreeSans.ttf
gnu-free-sans-fonts-20120503-15.fc27.noarch


Just fyi

Dmitri.


Dmitri A. Sergatskov <dasergatskov>
Sat 07 Oct 2017 03:09:56 PM UTC, comment #18: 

Looks good to me, thank you for the help fixing this.

I'm closing this, I will take care of the option to use distro font files separately.

Mike Miller <mtmiller>
Group Member
Sat 07 Oct 2017 12:09:11 PM UTC, comment #17: 

I pushed the patch here:
http://hg.savannah.gnu.org/hgweb/octave/rev/2390079a8aed

I had previously downloaded the fonts from the same repository but the 20100919 version. I included the latest version (the one you mention) instead. As for the indentation at line 217, that is the default in emacs when continuing an expression. I put it back aligned with the "equal" symbol.

Do you want to leave this report open and discuss the use of system FreeFont here ?

Pantxo Diribarne <pantxo>
Group Member
Fri 06 Oct 2017 11:17:18 PM UTC, comment #16: 

Your latest patch gives me valid font files, but they are not exactly the same as what I have.

What is your source for the FreeSans files? I used the 20120503 release tarball from gnu.org. The fonts in the release look like this on my system


$ ls -lgo freefont-20120503/FreeSans*otf
-rw-r----- 1 233476 May  3  2012 freefont-20120503/FreeSansBoldOblique.otf
-rw-r----- 1 305436 May  3  2012 freefont-20120503/FreeSansBold.otf
-rw-r----- 1 473976 May  3  2012 freefont-20120503/FreeSansOblique.otf
-rw-r----- 1 856800 May  3  2012 freefont-20120503/FreeSans.otf
$ sha1sum freefont-20120503/FreeSans*otf
92369c6b1b7bb09304522c86d5c69c5b520b2561  freefont-20120503/FreeSansBoldOblique.otf
4eb8185cd846ec23f07eee89ab42f203439e60ba  freefont-20120503/FreeSansBold.otf
df133a79006cc10b3535857231f5d5d7f4f031ec  freefont-20120503/FreeSansOblique.otf
3c2b26cd087d9e5fa9ba2fd4ae38a8685b1eb550  freefont-20120503/FreeSans.otf


I just want to make sure we get the right files in there.

I also see a stray space on line 208 of ft-text-renderer.cc and the indentation on line 217 isn't right.

Other than that this patch looks perfect to me.

Mike Miller <mtmiller>
Group Member
Thu 05 Oct 2017 05:30:42 PM UTC, comment #15: 

Many thanks Mike. I attached a cset with your patch merged on mine.
Since I use mq extension I finally ended up using "hg qdiff > patchname" to export the cset and actually it makes use of "--git" switch.





(file #42070)

Pantxo Diribarne <pantxo>
Group Member
Wed 04 Oct 2017 09:41:09 PM UTC, comment #14: 

I may also add a configure option to make Octave play nice with distributions, something like


./configure --with-system-freefont=/usr/share/fonts/opentype/freefont ...


But that shouldn't hold up the basics of getting this done.

Mike Miller <mtmiller>
Group Member
Wed 04 Oct 2017 06:23:06 PM UTC, comment #13: 

Pantxo - attached is a patch made on top of yours that takes care of the rest of this.  Also I changed the files to otf and changed the extension to otf in your patch locally, that is not part of my exported patch.

We already have a handful of binary files checked in to hg, like icons. These font files are a little bigger, but I don't know of any other reasonable solution. I don't think we want to add a build-dependency on fontforge just to be able to build these fonts from their source files.

You can merge my patch into yours if you want, and add the FreeSans otf files.

I don't know why the exported patch didn't work. Have you tried "hg diff --git" and "hg export --git"? I have that set by default here, I think that may take care of this.

(file #42062)

Mike Miller <mtmiller>
Group Member
Tue 03 Oct 2017 09:42:23 PM UTC, comment #12: 

I started looking at this a few days ago, but the actual source of the error seemed so hard to trace--mainly because program flow is back into the C source and there was some type of macro GO_BODY.  For that reason, it was the core code making the decision that a text object should not be valid (the bounding box description failing because it doesn't return "4").  So although gnuplot should work still, in theory, program flow was stopped before reaching the toolkit code.  There would need to be a change in the code that allows the toolkit to continue, rather than error in the core.  In other words, the error/warning should be in the toolkit, not the core code.

As noted in the posts, the main question is what to do.  If there is no font-config, Qt font's don't work?  (Oh, I suppose the plotting never actually uses the Qt resource, but OpenGL...and it's only the GUI where we know Qt resources are available.)  Behavior option #1, i.e., simply issue a warning and leave text objects blank on the plot, seems OK if the warning included some phrase like, "Try a different toolkit".

Dan Sebald <sebald>
Tue 03 Oct 2017 09:07:08 PM UTC, comment #11: 

Oh, and I am fine with otf if it is the recommended format.

Pantxo Diribarne <pantxo>
Group Member
Tue 03 Oct 2017 09:05:52 PM UTC, comment #10: 

Sorry, the simple "hg add fontfiles" followed by "hg export -o patchname" did not include the files in the patch. only the following:


diff -r e250aeab3c85 -r 8aa94b7dda80 etc/fonts/FreeSans.ttf
Binary file etc/fonts/FreeSans.ttf has changed
diff -r e250aeab3c85 -r 8aa94b7dda80 etc/fonts/FreeSansBold.ttf
Binary file etc/fonts/FreeSansBold.ttf has changed
diff -r e250aeab3c85 -r 8aa94b7dda80 etc/fonts/FreeSansBoldOblique.ttf
Binary file etc/fonts/FreeSansBoldOblique.ttf has changed
diff -r e250aeab3c85 -r 8aa94b7dda80 etc/fonts/FreeSansOblique.ttf
Binary file etc/fonts/FreeSansOblique.ttf has changed
diff -r e250aeab3c85 -r 8aa94b7dda80 libinterp/corefcn/ft-text-renderer.cc
...


I tried to add the "-a" switch and the files where somewhat added but probably messed up because they are then treated as text (as the doc says).

What is the proper way to export a patch with binary data and should we include those binary files in version control?

>> No problem, I'll look at the missing pieces here for how to distribute and install the font files and what the default should be when OCTAVE_FONT_DIR is not set.


Thanks. I looked again at adding "octave::config::font_dir ()" in toplev.h as is done for info_dir but got lost again.

Pantxo Diribarne <pantxo>
Group Member
Tue 03 Oct 2017 06:45:52 PM UTC, comment #9: 

No problem, I'll look at the missing pieces here for how to distribute and install the font files and what the default should be when OCTAVE_FONT_DIR is not set.

I have a small problem with your patch so far. The font files aren't valid when I do an hg import of the patch you uploaded. Maybe something got corrupted or limited in the way the patch was created. I can drop in my own copies of the four files to work on it here.

Second, should we prefer OTF to TTF? I think FreeType can handle both formats equally on any platform, and since this is for Octave's use only, I don't think we have to consider OS compatibility. The OTF files are recommended by the project, and they are slightly smaller.

Mike Miller <mtmiller>
Group Member
Tue 03 Oct 2017 09:25:14 AM UTC, comment #8: 

I looked at this a bit and got lost before the time I had to start my day job :-).

Please find attached a patch that takes care of adding the fonts in the source directory (in etc/fonts/), and makes use of an environment variable OCTAVE_FONT_DIR to locate the default font files. Most of the job of setting the environment variable (except in run-octave) and distributing the font files remains to be done. Mike, could you handle this?

(file #42050)

Pantxo Diribarne <pantxo>
Group Member
Mon 02 Oct 2017 10:21:44 PM UTC, comment #7: 

Thanks, I hardcoded in the path to FreeSans on my system and confirm that takes care of this issue.

So yeah, maybe we should include a font file in Octave's repo, and install it under OCTAVE_HOME so that it can be found for the fallback case when Fontconfig is not used, or maybe even when Fontconfig is used but the system configuration is empty or corrupted somehow.

Keep in mind we would also have to find the font file when running in the build dir with ./run-octave, so there would have to be some kind of environment variable override similar to OCTAVE_JAVA_DIR or OCTAVE_DEFAULT_QT_SETTINGS.

Mike Miller <mtmiller>
Group Member
Mon 02 Oct 2017 09:13:00 PM UTC, comment #6: 


>> If a font file were included that Octave could rely on unconditionally, would this still require the freetype library?


Yes freetype is still needed but not fontconfig:
fontconfig takes care of matching fontnames to actual fonts files installed on its path. freetype does all the rest (font scaling, metrics, rasterization ...).

>> So would this be a new implementation of the text_renderer base class? When I looked into this I saw that it's set up to allow different implementations but uses freetype/fontconfig unconditionally for now.


No need for a new implementation since we would still have to use freetype, just provide a default file name here:
http://octave.org/doxygen/4.2/dd/d49/ft-text-renderer_8cc_source.html#l00263

We could even map the special "*" fontname to the distributed font file (and FreeSans looks like a good choice indeed).


Pantxo Diribarne <pantxo>
Group Member
Mon 02 Oct 2017 08:33:27 PM UTC, comment #5: 

Actually building Octave with only fontconfig missing leads to the problem described here.

If I build Octave without both freetype and fontconfig, then gnuplot works fine.

I get an initial warning message "warning: opengl_renderer::render_text: support for rendering text (FreeType) was unavailable or disabled when Octave was built", but after that everything appears to function fine. Sure, maybe some text related functions like legend may not be entirely accurate, but they do function.

Mike Miller <mtmiller>
Group Member
Mon 02 Oct 2017 06:18:29 PM UTC, comment #4: 

No, there's no problem with including a font file.

So would this be a new implementation of the text_renderer base class? When I looked into this I saw that it's set up to allow different implementations but uses freetype/fontconfig unconditionally for now.

If a font file were included that Octave could rely on unconditionally, would this still require the freetype library?

If Octave is built without both fontconfig and freetype, should gnuplot be disabled as well?

GNU FreeFont seems like an obvious choice.

https://www.gnu.org/software/freefont/

Mike Miller <mtmiller>
Group Member
Mon 02 Oct 2017 06:01:04 PM UTC, comment #3: 

AFAIK gnuplot relies on freetype/fontconfig only for the "extent" property (approximate) computation. This will leave functions such as "annotation" or "legend" without a way to determine how large the text is expected to be. So unfortunately solution 2 doesn't look acceptable either.

Is there any reason for not including a few font files if their license is free?

Pantxo Diribarne <pantxo>
Group Member
Mon 02 Oct 2017 04:17:07 PM UTC, comment #2: 

I think this is a corner case, so I would find option #2 acceptable. We had these tests all bundled together before in configure and we have successfully unbundled them. Instead of changing configure, I would change the code, so that if HAVE_FONTCONFIG is undefined, the OpenGL toolkits are not built.

Let's assume we do that. Do you believe that the gnuplot toolkit should be able to function normally without fontconfig? Because it doesn't.


$ ../configure --without-fontconfig --without-opengl --without-osmesa --without-qt --disable-docs
$ make
...
$ ./run-octave -q
>> available_graphics_toolkits
ans =
{
  [1,1] = gnuplot
}

>> plot (1)
warning: ft_text_renderer: unable to load appropriate font
warning: called from
    axes at line 66 column 10
    newplot at line 158 column 10
    plot at line 222 column 9
warning: ft_text_renderer: unable to load appropriate font
warning: called from
    axes at line 66 column 10
    newplot at line 158 column 10
    plot at line 222 column 9
warning: ft_text_renderer: unable to load appropriate font
warning: called from
    axes at line 66 column 10
    newplot at line 158 column 10
    plot at line 222 column 9
warning: ft_text_renderer: unable to load appropriate font
warning: called from
    axes at line 66 column 10
    newplot at line 158 column 10
    plot at line 222 column 9
warning: ft_text_renderer: unable to load appropriate font
warning: called from
    axes at line 66 column 10
    newplot at line 158 column 10
    plot at line 222 column 9
warning: ft_text_renderer: unable to load appropriate font
warning: called from
    axes at line 66 column 10
    newplot at line 158 column 10
    plot at line 222 column 9
warning: ft_text_renderer: unable to load appropriate font
warning: called from
    axes at line 66 column 10
    newplot at line 158 column 10
    plot at line 222 column 9
error: ft_text_renderer: invalid bounding box, cannot render
error: __goaxes__: unable to create graphics handle
error: called from
    axes at line 66 column 10
    newplot at line 158 column 10
    plot at line 222 column 9


This was the surprising part to me when I originally hit this bug. Is this also fixable without including some fallback font file? Or should we also disable the gnuplot toolkit?

Mike Miller <mtmiller>
Group Member
Mon 02 Oct 2017 08:07:46 AM UTC, comment #1: 

What do we want to do when we have no way to locate a font due to missing fontconfig support:

  • Simply silence those warning after they have been thrown once
  • Fallback to using gnuplot, in which case the build script should consider equivalence between "--without-fontconfig" and "--without-opengl"
  • Ship a default font file with Octave install. Probably a sans serif, Helvetica compatible and ideally full featured (in the sense that it should provide all TeX symbols that we use)


The first solution, which leaves the user with text free plots looks ridiculous, but very simple to implement.
The second solution is also very simple I guess (once you know the build system).
The third one has the advantage that we can use a consistent, full featured, default font on every system.

Pantxo Diribarne <pantxo>
Group Member
Sun 01 Oct 2017 11:18:17 PM UTC, original submission:  

Building Octave with the '--without-fontconfig' option seems to work, but it produces an Octave that can't do any plotting.

When I have more time I can go through historical versions of Octave to see how they behaved, but in the current development branch, only a warning is shown that says "features that depend on fontconfig will be disabled". Then when attempting to plot anything, a runtime error is thrown:


warning: ft_text_renderer: unable to load appropriate font
warning: called from
    axes at line 66 column 10
    newplot at line 158 column 10
    plot at line 222 column 9
warning: ft_text_renderer: unable to load appropriate font
warning: called from
    axes at line 66 column 10
    newplot at line 158 column 10
    plot at line 222 column 9
warning: ft_text_renderer: unable to load appropriate font
warning: called from
    axes at line 66 column 10
    newplot at line 158 column 10
    plot at line 222 column 9
warning: ft_text_renderer: unable to load appropriate font
warning: called from
    axes at line 66 column 10
    newplot at line 158 column 10
    plot at line 222 column 9
warning: ft_text_renderer: unable to load appropriate font
warning: called from
    axes at line 66 column 10
    newplot at line 158 column 10
    plot at line 222 column 9
warning: ft_text_renderer: unable to load appropriate font
warning: called from
    axes at line 66 column 10
    newplot at line 158 column 10
    plot at line 222 column 9
warning: ft_text_renderer: unable to load appropriate font
warning: called from
    axes at line 66 column 10
    newplot at line 158 column 10
    plot at line 222 column 9
error: ft_text_renderer: invalid bounding box, cannot render
error: __goaxes__: unable to create graphics handle
error: called from
    axes at line 66 column 10
    newplot at line 158 column 10
    plot at line 222 column 9


This is with any toolkit.

Can someone more familiar with the plotting system help determine how this should be addressed? Is fontconfig now a hard requirement for any plotting function using any of the toolkits? For the OpenGL toolkits only? Should there be a fallback path that allows gnuplot to be used without fontconfig support? Or should all plotting be disabled?

Mike Miller <mtmiller>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #42070:  defaultfont3.patch added by pantxo (1MiB - text/x-patch)
file #42062:  fonts.patch added by mtmiller (2KiB - text/x-patch)
file #42050:  defaultfont.patch added by pantxo (2MiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by mtmiller (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-10-07 mtmiller Open/ClosedOpen Closed
    2017-10-07 pantxo StatusIn Progress Fixed
    2017-10-05 pantxo Attached File- Added defaultfont3.patch, #42070
    2017-10-04 mtmiller Attached File- Added fonts.patch, #42062
    2017-10-03 pantxo Attached File- Added defaultfont.patch, #42050
        StatusNone In Progress

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code