Re: A backend("fltk") problem

[Michael D Godfrey]

On 09/02/2009 08:46 PM, 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.

  

No need to worry about this.  The problem was with
interpreter tex mode.  This fails if some fonts are not
installed.  There is still a general problem of how to
avoid problems with differing fonts on all the different
systems.  Sadly, the Linux community has decided that
each distribution should have a random set of fonts,
with some "automatically" installed and others only
installed depending on specific packages...

> In any case, the fonts that I mentioned,
> xorg-x11-fonts-75dpi-7.2-8.fc11.noarch
> xorg-x11-fonts-100dpi-7.2-8.fc11.noarc
> only fixed the "interpreter", "tex" problem
> in the unpatched system.
>
> To add a brief summary of what I know about fltk/OpenGL:
>
> 1. With the unofficial patches, all plotting that I have
>    tried seems to work well.  This is mainly plots that
>    gnuplot could not handle at all.
>
> 2. The things that do not work are print, and the
>    "interpreter", "tex" mode.  The main reason print
>    fails to do anything is that the drawnow call seems
>    to do nothing.  It is clear that ghostscript is not being
>    set up correctly. I made a few changes in print.m to
>    get that far.  "interpreter", "tex"  is just ignored.
    

The status of the fltk/OpenGL backend as far as I know is consistent
with your observation: printing is not yet implemented - it is (was?)
planned to be done using the gl2ps library (actually consisting of one
c-file and one h-file). the tex interpreter is also unimplemented but
as I understand Michael Goffioul laid down the groundwork for using
LaTeX in the current text handling routines in that they use cached
bitmaps, which are now generated by freetype, but could be generated
by LaTeX.
I don't think I'll be able to work on these for at least the coming
month or so, but I will be available for email questions.

Shai

  

> There may be more significant problems, but I think
> that with the 2 above items resolved it would at least
> be at a point where it could be made available as
> a "beta" test.
    

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

This is basically correct, but the TeX mode is very helpful,
at least for me.

Shai
  

Thanks for your response.

Michael