[Lasi-devel] liblasi release ASAP?

[Alan W. I. <ir...@be...>]

Hi Andrew:

I am bringing this discussion back to the libLASi list since my news on your
last fix is good and there are libLASi release implications.

On 2008-02-07 12:58-0000 Andrew Ross wrote:

> Alan,
>
> You are right that it is a font issue. Example 0 explicitly asks for
> the Arial font. I don't have that installed so it falls back to one of
> the gsfonts. Unfortunately this is a bitmap font. LASi currently assumes
> any font it gets is an outline font. If you look in drawGlyph you can
> see that the returned glyph (of type FT_Glyph) is case to a
> FT_OutlineGlyph. Obviously for a bitmap font this is invalid and the
> attempt to access the outline member results in the segfault.
>
> For my particular case with Debian testing I don't have Arial installed
> (which example 0 requests). Fontconfig offers one of the bitmap gsfonts
> as an alternative. On all my other systems I have the msttcorefonts
> installed so I don't see the problem.
>
> Note that this is not actually because of the missing glyphs. All the
> text in example 0 is rendered (or attempts to) in this font. Only the
> 4 unusual glyphs are not found.
>
> As a temporary workaround I have surrounded the code which draws the
> glyph with an if {} statement to check that the glyph is an outline
> glyph before plotting. It should just leave a blank if the glyph is a
> bitmap.
>
> A better solution would be to try to force pango to only return
> outline fonts. I can't see a way of doing this though. I guess usually
> you want a bitmap at the end of the day for rendering on screen. The
> FT_LOAD_NO_BITMAP option to FT_Load_Glyph is a bit of a red herring.
> According to the documentation it means "Ignore bitmap strikes when
> loading. Bitmap-only fonts ignore this flag." So it doesn't do what
> we need. Of course in this case because we had specifically asked for
> Arial and Arial is not installed we're rather at the whim of the
> font-config defaults.
>
> Can you check that the temporary workaround fixes your problems with
> plplot, or at least that it prevents a segfault? If this is the case,
> perhaps we should go ahead and release.
>
> Andrew
>
> P.S. I also note using fc-list that I have no bitmap fonts available
> under debian oldstable or either of the Ubuntu versions I have to hand.
> I suspect this is why I've not seen the problem. This must be a
> fontconfig configuration issue, since I definitely do have the gsfonts
> installed.
>
> P.P.S.
> You can disable font-config from returning bitmap fonts globally (on
> debian look at /etc/fonts/conf.avail/70-no-bitmaps.conf and make a
> symlink into /etc/font/conf.d). Alternatively you can add the contents
> of /etc/fonts/conf.avail/70-no-bitmaps.conf to your ~/.fonts.conf file.
>

Everything works fine for me now with the identical font configuration that
caused the plplot and libLASi errors I reported to this list recently.  The
-dev psttfc segfaults are gone and the results for what I identified as
scaled bitmap glyphs before for example 23 are now blank.  Before I was also
having a problem with a modified form of MissingGlyphExample.cpp where I
used testString[]={0x61, 0x62, 0xe2,0xab,0xb4,0x61, 0x62, 0x00}; to put "ab"
both before and after the glyph, 0xe2,0xab,0xb4 = 2af4 = "TRIPLE VERTICAL
BAR BINARY RELATION" which according to gucharmap is not available on my
system.  In my previous tests the "ab" strings did not show up in the
result, but now they do.  So it appears that your "temporary workaround"
solves this missing glyph issue as well. Thus, I think your "temporary
workaround" is the permanent fix that we should adopt for safety/robustness.

A big thanks, Andrew, for following up on my bug report (which I know was
difficult to replicate). It's a superb feeling to have both of these
problems resolved.

I agree we are ready to make an official release of libLASi using the
SourceForge facilities.

Ed, are you comfortable with a libLASi release at this time as well?  If so,
I propose to do it as soon as you give the OK (which will presumably
be today).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________