Re: A backend("fltk") problem

[John W. Eaton]

On  3-Sep-2009, Shai Ayal wrote:

| On Thu, Sep 3, 2009 at 1:49 AM, Michael D.
| Godfrey<address@hidden> wrote:
| > On 09/02/2009 02:22 PM, John W. Eaton wrote:
| >>
| >> Off list, I sent Michael a patch to try to avoid the crash he was
| >> seeing.
| >>
| >> Back on the mailing list:
| >>
| >> On  1-Sep-2009, Michael D. Godfrey wrote:
| >>
| >> | I said:
| >> |
| >> |>  For now, I will just try commenting the ::error
| >> |
| >> | I said I would try this with almost zero expectation that it
| >> | would work, but it does !!
| >> |
| >> | So far, I only wrote a title at the top of a plot, but it
| >> | looks right and in a sans serif font that looks about right.
| >>
| >> What versions of freetype and fontconfig do you have installed?  I
| >> seem to have freetype 2.3.9 and fontconfig 2.6.0.
| >>
| >
| > [vzero:plot] rpm -q fontconfig
| > fontconfig-2.7.1-1.fc11.x86_64
| > fontconfig-2.7.1-1.fc11.i586
| > [vzero:plot] rpm -q freetype
| > freetype-2.3.9-5.fc11.x86_64
| > freetype-2.3.9-5.fc11.i586
| >
| >> When I try something like
| >>
| >>   set (0, 'defaultaxesfontname', 'foobarfont')
| >>   set (0, 'defaulttextfontname', 'foobarfont')
| >>   text (0.5, 0.5, 'foobar')
| >>
| >> I don't see a crash.  It still works for me and uses some default
| >> font (even without the change I sent to you).  Stepping through
| >> ft_manager::do_get_font, I see that the font name is "foobarfont", but
| >> even so, FcFontMatch returns a valid font object.  That's apparently
| >> not happening for you, so maybe there is a difference in the versions
| >> of freetype and/or fontconfig that we have installed, and my version
| >> is returning some default font when there is no match on the font
| >> pattern?  I see there is a call to
| >>
| >> This all works for me even if I remove what I think are the
| >> corresponding font packages that you mentioned.  On my system:
| >>
| >>   xfonts-base xfonts-100dpi xfonts-75dpi
| >>
| >> So now I'm a bit confused about exactly what dependency we should be
| >> adding.
| >>
| >
| > I am not clear about this either.  Right now I do not have
| > a copy of the current system without the patch that removes the
| > error::  lines.
| >>
| >> jwe
| >>
| 
| I could not understand what the original problem was here.

Sorry, the problem was the crash reported here:

  https://www-old.cae.wisc.edu/pipermail/bug-octave/2009-August/009333.html

I was able to reproduce this only by stepping through the
ft_manager::do_get_font function and setting match to 0 after this
statement:

  match = FcFontMatch (0, pat, &res);
              
Then the crash actually occurs later.  I never found exactly why, but
I think the best solution is to ensure that do_get_font always returns
a valid font, even if it is just some fallback font that we either
distribute with Octave or expect to be present based on package
dependencies.

| IMHO lack of printing is the #1 issue. tex is more on the nice to have list

I agree, but at least partial TeX parsing is already handled by the
gnuplot backend in an interpreted function, so I think that should not
be too hard to translate to C++.  Another place to look for TeX
support is the code in matplotlib, which I think has several levels of
TeX support from simple parsing of basic things like \theta to passing
the string to TeX and getting some graphics object back that is then
inserted in the plot.

jwe