Re: Build system considerations

[Vincent Torri]

On Thu, Apr 30, 2020 at 2:34 AM David Turner  wrote:
>
> Starting a thread here to discuss potential build system improvements for 
> FreeType.
>
> The current FreeType 2 build system has many flaws. To its credit, it was 
> designed in a very different time, when things like CMake / Meson / Ninja/ 
> Maven / GN / Bazel didn't even exist, when Autotools was considered the best 
> system to configure your build (ah!), and GNU Make 3.81 was considered new 
> and bleeding edge, and didn't necessarily exist for all platforms. I'm not 
> even sure pkg-config was available on all Linux distros until quite a long 
> time. As I said ... very different times.
>
> Despite that, it was also designed to make FreeType buildable on a maximum 
> amount of systems, and I attribute part of its success to that specific 
> feature, especially in the embedded world. While we probably no longer care 
> about developers using DOS and OS/2 systems to build the library, I would 
> really appreciate if any replacement could continue in this direction.
>
> I think it would also be acceptable if the build system used to develop 
> FreeType itself, might be different than the one used by other developers 
> that simply want to use it in their own projects. For example something that 
> can build and run tests easily with sanitizers, fuzzing, remote bots and 
> other goodies, or can integrate well with a continuous integration system. 
> While at the same time, being able to generate simple Makefiles / CMakefiles 
> / BUILD / BUILD.gn / whatever corresponding to a specific configuration of 
> the library (which is what 95% of developers using the library need).
>
> I have experience with CMake (I find it a vast improvement over auto-tools 
> for package / feature detection, but a hot mess for about anything else), 
> GN/Ninja (very powerful, but essentially requires too much dependencies to 
> get the most out of it) and Bazel (can be hard to get into, very powerful, 
> but requirements are a bit crazy at the moment). I'm curious about Meson.

i prefer meson compared to cmake because :
 * more readable syntax (the main point for me)
 * meson honors CFLAGS/LDFLAGS
 * cross compilation is simpler

regards

Vincent Torri

Re: Build system considerations

[Werner LEMBERG]

> [...] I have experience with CMake (I find it a vast improvement
> over auto-tools for package / feature detection, but a hot mess for
> about anything else), GN/Ninja (very powerful, but essentially
> requires too much dependencies to get the most out of it) and Bazel
> (can be hard to get into, very powerful, but requirements are a bit
> crazy at the moment).  I'm curious about Meson.

I still favor autotools over cmake.  Especially the syntax of the
latter makes me cringe :-) On the other hand, we *do* have contributed
cmake support and some reports both for bugs and improvments in the
bug tracker for it.

And I haven't tried ninja or mason; this is lazyness on my side since
I'm not involved in any project that uses those build systems.

Whatever we do, I strongly believe that the build system using
autotools must stay.  Maybe we can enhance it by using automake...

Note that improvement of FreeType's build system is also a potential
GSoC project (see https://www.freetype.org/gsoc.html); this year there
was no proposal for that, however.


Werner

Re: I'm back

[Werner LEMBERG]

>> [...] I think it would be helpful if FreeType (and more open source
>> projects) tagged bugfix releases more often.

Tagging is the easy thing, but doing the release process is tedious,
for which I often lack time and, admittedly, energy.

> We should probably look at the patches applied on top of previous
> releases as well and see what important things should be moved into
> a release branch.  I'll file a bug for this with more details.  The
> main question will be how long do we support older releases, and
> what goes into fixes (I would suggest only security fixes as a
> starting point).

Having a helping hand in doing releases would be very, very helpful...


Werner

Re: I'm back

[Werner LEMBERG]

>> My favorite pet issue I never got around to fixing: make stem
>> darkening for the autohinter be as good as the CFF variant. Also,
>> at least basic stem darkening for bytecode'd TTFs.
> 
> Can you clarify what that means exactly? I think I lack context
> and/or examples :-)

I leave explanations to Nikolaus :-)

>> And even a basic testing framework sounds good.  One could, if so
>> inclined, even use https://github.com/rougier/freetype-py and use
>> pytest and hypothesis to hammer out a test suite.
>
> I'd prefer something that tests the FreeType API directly instead,
> so something based on C or C++ instead. GoogleTest seems a good
> candidate for this.

There are two things to test.

  * API and code coverage

  * Rendering

For the latter we have a potential GSoC project proposal this year, so
let's please wait until May 4th before continuing the discussion.

> Another possibility is to change the way regression testing is
> performed (generating MD5 directly in ftobjs.c is ... unelegant and
> limited).

What's the problem with MD5?  The idea is to find out whether two
FreeType versions render a glyph differently.  I'm not aware of
something simpler.  It's not intended for API testing, of course.

> Is there a specific corpus of font files being used currently for
> regression testing?

For regression testing with have Armin's project:

  https://github.com/freetype/freetype2-testing

> Should we try to create one or improve the existing one?

Well, we need a different corpus for rendering testing – I think
we should use what Chromium currently uses.

BTW, Chromium does a 'live' testing of FreeType, this is, the project
monitors FreeType's git HEAD and reports rendering differences to
Chromium developers, which in turn report to us.  Of course, they
would like to get rid of that eventually :-)


Werner

Re: I'm back

[Werner LEMBERG]

>> not a pressure issue, but i would like to have VF driver. A Summer
>> of Code task has begun, never finished, though.
>
> Are you talking about TeX Virtual Fonts, or OpenType Variable Fonts
> here?

He talks about the former.  Support for OpenType VFs is already part
of FreeType.

> For the former, that sounds like a lot of work, for a format that
> isn't used to create new fonts anymore.  And as far as I understand,
> most TeX fonts of interest have been transliterated to OpenType
> already.

Well, there are still people interested in such font formats,
obviously :-) I like a lot that FreeType supports many different font
formats, so why not the TeX ones?  It is very unfortunate that the
GSoC project some years ago didn't deliver anything useful – the job
was to integrate the excellent 'VFlib' library stuff into FreeType,
and the guy seemed to be overwhelmed with this job.

>> I would be interested in knowing whether anyone is using Jamfiles
>> these days?
> 
> So in other words, let's get rid of the Jamfiles if nobody is using
> them today.  If someone is opposed to that, please speak up!

Given that a special, unmaintained version of Jam is needed to build
FreeType, I think that removing Jam support is the right way to
proceed.

As a consequence I've just added a sentence to the CHANGES file that
Jam support will be removed in the release after the next one (i.e.,
not in 2.10.2 but in 2.10.3).


Werner

Re: [Freetype-devel] Re: Build system considerations

[Alexei Podtelezhnikov]

On Wed, Apr 29, 2020 at 10:17 PM suzuki toshiya
 wrote:
> It is a pity that I hear the lack of -fvisibility=hidden is
> not only current status but promised in the future release X-(.

Suzuki san,

We have -fvisibility=hidden despite libtool.

Alexei

Re: [Freetype-devel] Re: Build system considerations

[suzuki toshiya]

Dear Alexei, Turner,

It is a pity that I hear the lack of -fvisibility=hidden is
not only current status but promised in the future release X-(.

BTW, during the participation to Poppler and SVG Native Viewer,
I had big headache by the CMake's lack of the seamless (or
side-by-side) support for the shared and static libraries.

I feel similar impression with GN and Ninja combination,
from my small experience to build Chromium and Skia.

Is there any recommended alternative? Or, should we accept
the "modern" situation where we have to execute twice to build
shared and static libraries?

Regards,
mpsuzuki

P.S.
Welcome back Turner! I'm very happy to hear from you again!!



Alexei Podtelezhnikov wrote:
> On Wed, Apr 29, 2020 at 8:34 PM David Turner  wrote:
>> Starting a thread here to discuss potential build system improvements for 
>> FreeType.
>>
>> The current FreeType 2 build system has many flaws. To its credit, it was 
>> designed in a very different time, when things like CMake / Meson / Ninja/ 
>> Maven / GN / Bazel didn't even exist, when Autotools was considered the best 
>> system to configure your build (ah!), and GNU Make 3.81 was considered new 
>> and bleeding edge, and didn't necessarily exist for all platforms. I'm not 
>> even sure pkg-config was available on all Linux distros until quite a long 
>> time. As I said ... very different times.
> 
> Most serious projects I have encountered so far use ./configure; make.
> It is the libtool that annoys me. They refused to implement
> -fvisibiity=hidden  when I asked. They said that libtool was current
> when building shared libraries was hard, which is actually true. Let's
> just get rid of libtool as whatever it does for us is quite minimal.
> 
> Alexei
> 
> 

Re: Build system considerations

[Alexei Podtelezhnikov]

On Wed, Apr 29, 2020 at 8:34 PM David Turner  wrote:
>
> Starting a thread here to discuss potential build system improvements for 
> FreeType.
>
> The current FreeType 2 build system has many flaws. To its credit, it was 
> designed in a very different time, when things like CMake / Meson / Ninja/ 
> Maven / GN / Bazel didn't even exist, when Autotools was considered the best 
> system to configure your build (ah!), and GNU Make 3.81 was considered new 
> and bleeding edge, and didn't necessarily exist for all platforms. I'm not 
> even sure pkg-config was available on all Linux distros until quite a long 
> time. As I said ... very different times.

Most serious projects I have encountered so far use ./configure; make.
It is the libtool that annoys me. They refused to implement
-fvisibiity=hidden  when I asked. They said that libtool was current
when building shared libraries was hard, which is actually true. Let's
just get rid of libtool as whatever it does for us is quite minimal.

Alexei

Re: I'm back

[David Turner]

Le lun. 27 avr. 2020 à 18:09, Ben Wagner  a écrit :

> One thing that's been on my mind is around releasing (and this is a
> fairly general observation not specific to FreeType). FreeType has
> generally tagged a VER-2-X-X release about once every six months and
> hasn't had maintained release branches. Distros (and other users)
> generally only update to tagged releases or branches and then try to
> maintain a patch pile of cherry-picks for bug fixes (essentially a
> release branch out of tree). In the present day any non-rolling distro
> model is slightly crazy since most open source projects work this way;
> the distro should be at more or less tip of tree or there will be
> known public exploitable bugs which the distro maintainer probably
> doesn't even know should be cherry-picked. However even rolling
> distros don't generally always stay at tip of tree to avoid incidental
> intermediate API/ABI breakage so tend to lean on the developers to tag
> commits to bless them. All of that to say, I think it would be helpful
> if FreeType (and more open source projects) tagged bugfix releases
> more often. For example if there are no API changes at all since the
> previous release tag a bugfix release as soon as reasonable.  It may
> seem a bit silly from the developer point of view, but it means that
> most users will get bugfixes much quicker. The versioned distros will
> still need to cherry-pick things back to their old versions, but users
> that keep up to date will benefit greatly.
>
> Using release branches (as they are described in Trunk Based Development
) for this makes total sense.
I have started looking at how various distributions / projects configure /
build FreeType [1], but only for the latest version (2.10.1).
For that one, the list of patches is rather minimal imho (most are about
changing configuration options).

We should probably look at the patches applied on top of previous releases
as well and see what important things should be moved into a release branch.
I'll file a bug for this with more details. The main question will be how
long do we support older releases, and what goes into fixes (I would
suggest only security fixes as a starting point).


>
> I was reminded of this sort of issue this morning when I experienced
> an extreme version of this issue with the 'ardour' package in debian
> which is currently code from two years ago and the package didn't ship
> in the bullseye release because the old code didn't work with newer
> libraries even though upstream had long since fixed the issue but
> there have been no new tags since.
>
>
>
[1] Nix:
https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/libraries/freetype
(subpixel-rendering + table-validation)

Debian testing: https://packages.debian.org/testing/libs/libfreetype6
(subpixel-rendering + table-validation + scale-phantom-points +
verbose-libtool)

Ubuntu focal: https://packages.ubuntu.com/focal/libs/libfreetype6 (same as
debian)

Fedora: https://src.fedoraproject.org/rpms/freetype/tree/
(subpixel-rendering + table validation + ABI fixes(?!?) + libtool fixes)

OpenSuse:
https://build.opensuse.org/package/show/openSUSE%3AFactory/freetype2
(subpixel-rendering, enable long family names, enable infinality,
libpng-not-required, cmex-font-workaround)

ArchLinux:
https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/freetype2
(table validation, enable infinality, enable long pcf family names, phantom
points)

Gentoo:
https://gitweb.gentoo.org/repo/gentoo.git/tree/media-libs/freetype/freetype-2.10.1.ebuild
(TODO)

FreeBSD: https://www.freshports.org/print/freetype2/

NetBSD:
https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/graphics/freetype2/patches/
(TODO)

OpenBSD: only using freetype 1.3.1 !!

ReactOS: ??

Skia: https://github.com/google/skia/tree/master/third_party/freetype2
modules: no raster1, type1, pfr, bitmapped formats
options: seems to be using the default, i.e. no subpixel rendering, no
harfbuzz, no adobe glyph list

Le ven. 24 avr. 2020 à 16:02, David Turner  a écrit :
> >
> > Hello freetype-devel@ list members,
> >
> > It's been a very very long time, but I have some free time in the coming
> weeks to work on FreeType. Werner invited me to write a small announcement
> here and I'm currently looking at the official bugs list.
> >
> > I'd like to know what are, in your opinion, the most pressing issues to
> work on at that point?
> >
> > Apart from that, I had the following things in mind:
> >
> > - Improving / refactoring the build system a little. E.g. it should be
> possible to simplify the rules.mk/module.mk files considerably, and
> auto-generate most of the Makefiles / Jamfiles / CMakefiles from a single
> source of truth (exact format to be defined), at least the parts that deal
> with the headers / sources / configuration headers and the module
> dependencies.
> >
> > - Improve testing (unit and regression tests to be exact) There are lots
> of 

Re: I'm back

[David Turner]

Le ven. 24 avr. 2020 à 22:46, Nikolaus Waxweiler  a
écrit :

> Woah 
>
> My favorite pet issue I never got around to fixing: make stem darkening
> for the autohinter be as good as the CFF variant. Also, at least basic
> stem darkening for bytecode'd TTFs.


Can you clarify what that means exactly? I think I lack context and/or
examples :-)


> Then Qt can go all in on stem
> darkening and rendering fonts correctly. And hopefully everyone else.
>
> What do you mean by "going all in on stem darkening", especially for QT?
Are you advocating for UIs with darker / bolder fonts or something like
that?
Just trying to understand.


> Also, the build system generation thing sounds very meta. I'd prefer
> settling on a single build system (either CMake or Meson and nothing
> else) 
>
> I was thinking about something much simpler at first. For example, I have
some local changes to considerably simplify the content of the rules.mk /
module.mk.
This uses a few custom GNU Make functions but that's a hidden /
implementation detail. The point is to make these .mk files easily
parseable by something else.

The current build system was designed in a very different time, and there
is definitely value in changing it more drastically. I'll start a different
thread to discuss the idea though.

And even a basic testing framework sounds good. One could, if so
> inclined, even use https://github.com/rougier/freetype-py and use
> pytest and hypothesis to hammer out a test suite.
>
> I'd prefer something that tests the FreeType API directly instead, so
something based on C or C++ instead. GoogleTest seems a good candidate for
this.
Another possibility is to change the way regression testing is performed
(generating MD5 directly in ftobjs.c is ... unelegant and limited).
There are probably several dimensions to explore from this, from the
simplest things to full goodies like Skia Gold
 which is really impressive, can be
used for non-Skia projects, but requires setting up / administering /
paying for Google-Cloud accounts / services.

Is there a specific corpus of font files being used currently for
regression testing? Should we try to create one or improve the existing one?

Re: Compiler warnings when building utilities in ft2demos

[David Turner]

Thank you, filed as https://savannah.nongnu.org/bugs/index.php?58275 now

Le mer. 29 avr. 2020 à 18:18, WILSON, MICHAEL  a
écrit :

> Good afternoon,
>
>
>
> When building FreeType, GCC is warning of strncpy() calls which are not
> nul terminated.
>
> Probably not a big problem in view of the context.
>
>
>
> Example :
>
>
>
> src/ftchkwd.c:172:9: warning: 'strncpy' output truncated before
> terminating nul
>
> copying 4 bytes from a string of the same length [-Wstringop-truncation]
>
>  strncpy( filename + strlen( filename ), ".ttf", 4 );
>
>  ^~~
>
> src/ftchkwd.c:173:9: warning: 'strncpy' output truncated before
> terminating nul
>
> copying 4 bytes from a string of the same length [-Wstringop-truncation]
>
>  strncpy( alt_filename + strlen( alt_filename ), ".ttc", 4 );
>
>  ^~~
>
>
>
> There are 8 source files using the same code sequence to append “.ttf” or
> “.ttc” to filenames.
>
> Two of them (ftdump.c, ftlint.c) will copy the nul (5th byte).
>
> Six do not (compos.c, ftchkwd.c, ftmemchk.c, ftsbit.c, fttimer.c, fttry.c).
>
>
>
>
>
> # grepall '\.ttf' | grep 'strncpy.*4'
>
> ./ft2demos-2.10.1/src/compos.c:102:strncpy( filename + strlen(
> filename ), ".ttf", 4 );
>
> ./ft2demos-2.10.1/src/ftchkwd.c:172:strncpy( filename + strlen(
> filename ), ".ttf", 4 );
>
> ./ft2demos-2.10.1/src/ftmemchk.c:273:strncpy( filename + strlen(
> filename ), ".ttf", 4 );
>
> ./ft2demos-2.10.1/src/ftsbit.c:206:  strncpy( filename + strlen(
> filename ), ".ttf", 4 );
>
> ./ft2demos-2.10.1/src/fttimer.c:233:  strncpy( filename + strlen(
> filename ), ".ttf", 4 );
>
> ./ft2demos-2.10.1/src/fttry.c:119:strncpy( filename + strlen(
> filename ), ".ttf", 4 );
>
>
>
>
>
> Thanks.
>
>
>
> Mike Wilson
>
>
>

Build system considerations

[David Turner]

Starting a thread here to discuss potential build system improvements for
FreeType.

The current FreeType 2 build system has many flaws. To its credit, it was
designed in a very different time, when things like CMake / Meson / Ninja/
Maven / GN / Bazel didn't even exist, when Autotools was considered the
best system to configure your build (ah!), and GNU Make 3.81 was considered
new and bleeding edge, and didn't necessarily exist for all platforms. I'm
not even sure pkg-config was available on all Linux distros until quite a
long time. As I said ... very different times.

Despite that, it was also designed to make FreeType buildable on a maximum
amount of systems, and I attribute part of its success to that specific
feature, especially in the embedded world. While we probably no longer care
about developers using DOS and OS/2 systems to build the library, I would
really appreciate if any replacement could continue in this direction.

I think it would also be acceptable if the build system used to develop
FreeType itself, might be different than the one used by other developers
that simply want to use it in their own projects. For example something
that can build and run tests easily with sanitizers, fuzzing, remote bots
and other goodies, or can integrate well with a continuous integration
system. While at the same time, being able to generate simple Makefiles /
CMakefiles / BUILD / BUILD.gn / whatever corresponding to a specific
configuration of the library (which is what 95% of developers using the
library need).

I have experience with CMake (I find it a vast improvement over auto-tools
for package / feature detection, but a hot mess for about anything else),
GN/Ninja (very powerful, but essentially requires too much dependencies to
get the most out of it) and Bazel (can be hard to get into, very powerful,
but requirements are a bit crazy at the moment). I'm curious about Meson.

I don't have something specific to propose, but that's my current point of
view. I may be wrong or misguided, so please share your feedback in this
thread.

Let the flame^W war^W games begin :-)

- David

Re: I'm back

[David Turner]

Le lun. 27 avr. 2020 à 18:21, Vincent Torri  a
écrit :

> Hello
>
> not a pressure issue, but i would like to have VF driver. A Summer of
> Code task has begun, never finished, though.
>
> Are you talking about TeX Virtual Fonts, or OpenType Variable Fonts here?

For the former, that sounds like a lot of work, for a format that isn't
used to create new fonts anymore.
And as far as I understand, most TeX fonts of interest have been
transliterated to OpenType already.

For the second, it looks like there are fonts available from
https://github.com/adobe-fonts/variable-font-collection-test
that could be a starting point, but we may have indeed other priorities for
now.


> about build system, i would say meson only for Windows, Linux, BSD*
> and Solaris, and no change for the other OS. That would simplify the
> build system. are Jamfiles really useful these days ? In addition,
> having a lot of build system is a pain to have them always up to date
>
> I would be interested in knowing whether anyone is using Jamfiles these
days?
I found them useful to me 10-15 years ago when I was hacking heavily on the
library because they built faster, and more correctly, and supported
rebuilding both the library and the demos at the same time.
However, all of this can be served by a better build system too, whatever
form it takes (let's keep that for a separate thread).

So in other words, let's get rid of the Jamfiles if nobody is using them
today. If someone is opposed to that, please speak up!

- David


> best regards
>
> Vincent Torri
>
> On Fri, Apr 24, 2020 at 10:02 PM David Turner  wrote:
> >
> > Hello freetype-devel@ list members,
> >
> > It's been a very very long time, but I have some free time in the coming
> weeks to work on FreeType. Werner invited me to write a small announcement
> here and I'm currently looking at the official bugs list.
> >
> > I'd like to know what are, in your opinion, the most pressing issues to
> work on at that point?
> >
> > Apart from that, I had the following things in mind:
> >
> > - Improving / refactoring the build system a little. E.g. it should be
> possible to simplify the rules.mk/module.mk files considerably, and
> auto-generate most of the Makefiles / Jamfiles / CMakefiles from a single
> source of truth (exact format to be defined), at least the parts that deal
> with the headers / sources / configuration headers and the module
> dependencies.
> >
> > - Improve testing (unit and regression tests to be exact) There are lots
> of possibilities here, and it will probably better to do this in small
> incremental steps.
> >
> > Voila, I'd be happy to read your suggestions, Happy to be here.
> >
> > - David Turner
>

Re: I'm back

[Alexei Podtelezhnikov]

On Fri, Apr 24, 2020 at 4:02 PM David Turner  wrote:
> Voila, I'd be happy to read your suggestions, Happy to be here.

.. and another project is on the table after we lost Moazin's GSoC
proposal on font-rs. I was actually advocating for a couple of
FT_Renderer modules for alternative rasterizers:
Raph Levien's font-rs for SIMD (or fontdue) and Pathfinder for GPU.
They claim to be the fastest rasterizer out there. Here is the links:

https://github.com/raphlinus/font-rs
https://github.com/mooman219/fontdue
https://github.com/servo/pathfinder

Alexei

Re: I'm back

[Alexei Podtelezhnikov]

On Fri, Apr 24, 2020 at 4:02 PM David Turner  wrote:
> Voila, I'd be happy to read your suggestions, Happy to be here.

Welcome back, David!

If you still enjoy coding the renderers... We need to implement a
color one and deal with FT_Glyph and FT_GlyphSlot insufficiencies for
that. I made some progress in the "color" branch but lost steam. This
is for modern COLR/CPAL emoji fonts. The goal is to make them work
seamlessly even with FTC caching.

The renderer itself has been implemented in the "color" branch. To
store the layer make-up and colors, I used FT_GlyphSlot->subglyphs and
expanded FT_OultineGlyph. Two things are still needed but I lack the
knowledge: (1) parsing of COLR/CPAL into subglyphs and (2) fitting FTC
for color bitmaps. I would love to recruit your help here.

Thank you,
Alexei

Compiler warnings when building utilities in ft2demos

[WILSON, MICHAEL]

Good afternoon,

When building FreeType, GCC is warning of strncpy() calls which are not nul 
terminated.
Probably not a big problem in view of the context.

Example :

src/ftchkwd.c:172:9: warning: 'strncpy' output truncated before terminating nul
copying 4 bytes from a string of the same length [-Wstringop-truncation]
 strncpy( filename + strlen( filename ), ".ttf", 4 );
 ^~~
src/ftchkwd.c:173:9: warning: 'strncpy' output truncated before terminating nul
copying 4 bytes from a string of the same length [-Wstringop-truncation]
 strncpy( alt_filename + strlen( alt_filename ), ".ttc", 4 );
 ^~~

There are 8 source files using the same code sequence to append ".ttf" or 
".ttc" to filenames.
Two of them (ftdump.c, ftlint.c) will copy the nul (5th byte).
Six do not (compos.c, ftchkwd.c, ftmemchk.c, ftsbit.c, fttimer.c, fttry.c).


# grepall '\.ttf' | grep 'strncpy.*4'
./ft2demos-2.10.1/src/compos.c:102:strncpy( filename + strlen( filename 
), ".ttf", 4 );
./ft2demos-2.10.1/src/ftchkwd.c:172:strncpy( filename + strlen( 
filename ), ".ttf", 4 );
./ft2demos-2.10.1/src/ftmemchk.c:273:strncpy( filename + strlen( 
filename ), ".ttf", 4 );
./ft2demos-2.10.1/src/ftsbit.c:206:  strncpy( filename + strlen( filename 
), ".ttf", 4 );
./ft2demos-2.10.1/src/fttimer.c:233:  strncpy( filename + strlen( filename 
), ".ttf", 4 );
./ft2demos-2.10.1/src/fttry.c:119:strncpy( filename + strlen( filename 
), ".ttf", 4 );


Thanks.

Mike Wilson