Sat 07 Oct 2017 04:14:32 PM UTC, comment #19:
@Mike: On Fedora those fonts are:
Just fyi
Dmitri.
|
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.
|
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 ?
|
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
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.
|
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)
|
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
But that shouldn't hold up the basics of getting this done.
|
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)
|
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".
|
Tue 03 Oct 2017 09:07:08 PM UTC, comment #11:
Oh, and I am fine with otf if it is the recommended format.
|
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:
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.
|
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.
|
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)
|
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.
|
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).
|
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.
|
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/
|
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?
|
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.
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?
|
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.
|
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:
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?
|