Re: bug report and troubles linking

[David Turner]

Hi Nathan,

> > Yes, this is a known problem, and comes from a bug in the standard
> > scan-converter which, apparently, is unable to render certain rotated
> > glyphs.
> 
> uhuh.
> 
Actually, "ftstring" was the first program to exhibit this bug, it's rather
new !!

> > The smooth renderer will become the default for anti-aliased rendering.
> > Note that it was recently completed this week and that you should try to
> > download the latest version through CVS, ViewCVS or one of our mirrors..
> 
> Yes, for gnome canvas the new renderer makes a lot more sense.  Is it
> still believed that rendering directly to the canvas is bad?  Would it be
> possible to store a set of the spans some how(I did this a couple of years
> back in a windowing system project where we kept regions as a set of
> packed spans)?  That structure could easily be faster than copying an
> image for each rendered glyph?
> 

It was never believed to be "bad", it simply was impractical due to the
algorithm used by the standard renderer (which was forced to make two passes
on the renderer glyph).

The "smooth" renderer is all about direct rendering and supports it. You
should use the new function FT_Outline_Render to implement that. See also
the structure FT_Raster_Params in "include/ftimage.h".

Note that the smooth renderer is the only one that supports direct rendering
for now. I'd like to do the same for the monochrome renderer, but the
requirements of TrueType drop-out control make this thing hard to
implement easily..

OFF-TOPIC:
Actually, the algorithm used in the smooth renderer is based on ideas
taken from the LibArt renderer, though the implementations are extremely
different. That's funny, given that Raph Levien told me that LibArt's
SVPs were inspired from FreeType's "profiles" :-)

By the way, I have not performed benchmarks of the two renderers but would
be interested in any numbers...

> > >   Secondly, I'm having a bit of trouble getting the build environment
> > > right.  I've copied the libfreetype.a file into my project dir, copied the
> > > include dir into ~/include/freetype2, modified the headers to point to the
> > > correct files and linked with
> >
> > FT_Init_FreeType is defined in "src/base/ftinit.c" which should normally
> > compile as "obj/ftinit.o", during a normal build this file should be added
> > the libfreetype.a.
> 
> omesupport -lgnomeui -lart_lgpl -lgdk_pixbuf -lgnomecanvaspixbuf
> libfreetype.a ./canvas3.o -o canvas3 ~/freetype2-tarball/obj/ftinit.o
> gcc: ~/freetype2-tarball/obj/ftinit.o: No such file or directory
> 
> but
> 
> address@hidden canvas]$ ls -l ~/freetype2-tarball/obj/ftinit.o
> -rw-r--r--   1 njh      postg       20756 Apr  7 10:08
> /home/njh/freetype2-tarball/obj/ftinit.o
> 
> It gets weirder every minute :-)
> 
> > Can you check that this function is correctly there (use a utility like
> > 'nm' to list the symbols of the library) ?
> 
> address@hidden canvas]$ nm libfreetype.a | grep FT_Init
> 00000000 T FT_Init_FreeType
> 00003a9c T FT_Init_Extensions
> address@hidden canvas]$
> 
> Now if my understanding is correct, this means that it is defined, and is
> the first routine in one of the relocatable blocks.
> 

??? Can't help you there for now, maybe I'll do some check today..

- David

> njh