I'm back

[David Turner]

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

[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
<https://trunkbaseddevelopment.com/>) 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
> s

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
>

[patches] Minor build system improvements

[David Turner]

Here are two cumulative patches that try to simplify the rules.mk and
module.mk used by the FreeType 2 build system. The point is to remove
GNU-Make specific statements from these files, making them declarative
instead. I.e. after applying the first patch, a module.mk will contain
something like:

# See builds/modules.mk for documentation about this file's content
MODULE_CLASS_NAME := sfnt
MODULE_CLASS_TYPE := module
MODULE_CLASS_DESCRIPTION := Helper module for TrueType & OpenType formats

Similarly, after applying the second patch, a rules.mk will look like:

MODULE_SOURCES := \
  pngshim.c   \
  sfdriver.c  \
  sfobjs.c\
  sfwoff.c\
  sfwoff2.c   \
  ttbdf.c \
  ttcmap.c\
  ttcolr.c\
  ttcpal.c\
  ttkern.c\
  ttload.c\
  ttmtx.c \
  ttpost.c\
  ttsbit.c\
  woff2tags.c \

MODULE_HEADERS := \
  $(MODULE_SOURCES:%.c=%.h) \
  sferrors.h \

MODULE_WRAPPER := sfnt.c

Compared to their previous content, this drastically simplifies the file,
and makes them much easier to understand and maintain. All of this comes at
the price of more "magic" in the GNU Make scripts under builds/freetype.mk
and builds/modules.mk, which now heavily use custom and non-trivial GNU
Make functions (that I've tried to document as most as possible).

The goal is to make these files (rules.mk / module.mk) much easier to parse
with something else, so we can start experimenting with better build
systems. It shouldn't be difficult to write a small Python script that
reads these files for example, then transform that into something more
interesting (e.g. a CMake / Meson / GN fragment).

Please take a look and let me know if you have any issue with the approach
used here.

NOTE: These patches should not change the output of the current build
system at all!

- David
From 4095fc04234a73b825dc122b86d903835988863d Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Thu, 30 Apr 2020 11:03:33 +0200
Subject: build: Simplify module.mk syntax

This patch modifies the syntax expected from module.mk
files to make it considerably simpler. Now, each file
should only contain declarations like:

  MODULE_CLASS_NAME := psaux
  MODULE_CLASS_TYPE := module
  MODULE_CLASS_DESCRIPTION := Postcript Type 1 & Type 2 helper module

These are parsed by builds/modules.mk which uses them
to recreate ftmodule.h exactly as previously.

This makes the modules.mk much easier to understand, and
a future patch will do something similar for rules.mk files,
possibly merging them into a single file for each module.

Note that all of this introduces far more 'magic' in the build
system (i.e. the use of non-trivial custom GNU Make functions),
and comments have been added to try to explain what they are
doing.

However, this is a necessary first step before being able to
move the FreeType 2 build system in a different direction.
---
 builds/modules.mk| 188 ++-
 builds/toplevel.mk   |  11 +--
 builds/utils/common.mk   |  37 
 builds/utils/compiler.mk |  88 ++
 builds/utils/host.mk |  81 +
 src/autofit/module.mk|  11 +--
 src/bdf/module.mk|  11 +--
 src/cff/module.mk|  11 +--
 src/cid/module.mk|  11 +--
 src/gxvalid/module.mk|  11 +--
 src/otvalid/module.mk|  11 +--
 src/pcf/module.mk|  11 +--
 src/pfr/module.mk|  11 +--
 src/psaux/module.mk  |  11 +--
 src/pshinter/module.mk   |  11 +--
 src/psnames/module.mk|  11 +--
 src/raster/module.mk |  11 +--
 src/sfnt/module.mk   |  11 +--
 src/smooth/module.mk |  19 ++--
 src/truetype/module.mk   |  11 +--
 src/type1/module.mk  |  11 +--
 src/type42/module.mk |  11 +--
 src/winfonts/module.mk   |  11 +--
 23 files changed, 432 insertions(+), 179 deletions(-)
 create mode 100644 builds/utils/common.mk
 create mode 100644 builds/utils/compiler.mk
 create mode 100644 builds/utils/host.mk

diff --git a/builds/modules.mk b/builds/modules.mk
index ae2e238f1..e3f61ace4 100644
--- a/builds/modules.mk
+++ b/builds/modules.mk
@@ -16,64 +16,166 @@
 # DO NOT INVOKE THIS MAKEFILE DIRECTLY!  IT IS MEANT TO BE INCLUDED BY
 # OTHER MAKEFILES.
 
+include $(TOP_DIR)/builds/utils/common.mk
+include $(TOP_DIR)/builds/utils/host.mk
 
 # This file is in charge of handling the generation of the modules list
-# file.
+# file (i.e. ftmodule.h) from the content of the module.mk files found in
+# the source tree.
+#
+# Each module.mk should contain variable definitions that look like:
+#
+#  MODULE_CLASS_NAME := 
+#  MODULE_CLASS_TYPE := 
+#  MODULE_CLASS_DESCRIPTION := 
+#
+# Where  is the module's class variable name prefix.
+# Where  is one of "module", "driver" or "renderer"
+# And where  is a small one-line description of the module.
+#
+# Some module.mk may define up to three modules by using
+# MODULE_CLASS_XXX_2 and MODULE_CLASS_XXX_3 definitions as well, but this
+

Re: Build system considerations

[David Turner]

Le jeu. 30 avr. 2020 à 23:33, Albert Astals Cid  a écrit :

> El dijous, 30 d’abril de 2020, a les 19:35:19 CEST, Behdad Esfahbod va
> escriure:
> > Hi David,
> >
> > Thanks for bringing this up.  I come from the GNOME camp.  My
> understanding
> > is that meson is replacing autotools longterm, sidestepping attempts like
> > cmake, the same way that git replaced CVS, sidestepping mercurial,
> bazaar,
> > etc.
>
> I am afraid that is your very biased life bubble.
>
> I'm not sure you realize that what you wrote sounds insensitive and is
bordering ad-hominen.
You could have said that you disagree and that this doesn't match your
experience for example.
Instead you tone devalues the point you're trying to make.


> CMake is the industry standard.
>
> I know comparisons are not easy, but let's search for "project" (a keyword
> my little knowledge of meson says that is present in all meson using
> projects) in meson files in github
> https://github.com/search?l=Meson&q=project&type=Code
> 6500 instances
>
> Now let's search for CMAKE_CXX_STANDARD a keyword in CMake used for C++
> projects (and not even mandatory to use)
> https://github.com/search?l=CMake&q=CMAKE_CXX_STANDARD&type=Code
> 246000 instances
>
> And that's not including the C based projects or similar.
>
> I know you don't have to choose build systems based on popularity, but
> saying that meson is sidestepping cmake is far from the truth.
>
>
I think Behdad was talking about the Gnome world here, not the rest of the
industry / open source community.
In all cases, I'm not a big fan of blindly following industry standards
just because they exist (*cough* JavaScript).

Just to clarify again for the context of this thread:

A) One of the major features of FreeType is that is can be easily built on
many many systems (included embedded ones with weird toolchains), and it's
something I'd like to keep for the core library.
  In other words, I really want to keep the ability to compile an official
release of FreeType with "./configure && make". That doesn't mean we have
to use auto-tools or the current Make-based system though.
  We may also consider providing CMake scripts to help use of FreeType
releases into CMake-based projects.

B) For people developing FreeType (instead of using it in their project),
it would be really useful to have a better build system to use. E.g. one
that allows building _and_ running tests easily, at a minimum.
I'd like to see easy support for cross-compilation, or even remote
cross-compilation (e.g. being able to automate a remote build on a Windows
or OS X machine through SSH is invaluable when doing cross-platform
development, as I have done that in the past), but these are minor compared
to the ability to run tests as soon as possible.
This second build system might be completely different from make/CMake,
and I don't care at all as long as we can support A) properly. Keep in mind
that FreeType has very few developers (which is perfectly ok), so choosing
a solution that brings joy is more important than something that could
support a team of 50 people working on it, or is industry standard.

I guess the best thing will be to experiment with several build systems to
see what they can offer. I'll try to setup something this week-end, but
feel free to contribute something so we can all check that.


Cheers,
>   Albert
>
> >
> > In the latest HarfBuzz release we added a meson build system.  Over the
> > next few months I expect us to remove our cmake one and eventually the
> > autotools one (which is the "official" one right now).
> >
> > Hope that helps,
> > behdad
> >
> > On Wed, Apr 29, 2020 at 5: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.
> > >
> > > 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

Re: Build system considerations

[David Turner]

Le jeu. 30 avr. 2020 à 03:30, Alexei Podtelezhnikov  a
écrit :

> 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.
>
> As far as I understand, libtool exists because building shared libraries
for ten different Unix-like system is a portability nightmare.
On the other hand, building them for a standard Linux distribution, or OS
X, is a well known problem, so we may consider keeping autotools/libtool as
an escape hatch for esoteric systems that still exist, and use something
simpler/better for Linux and OS X?


> Alexei
>

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

[David Turner]

Le jeu. 30 avr. 2020 à 10:40, Nikolaus Waxweiler  a
écrit :

> One thing regarding build systems and IDE/tool integration:
>
> Cmake and others can generate a
> https://clang.llvm.org/docs/JSONCompilationDatawas a portabililty
> nightmarebase.html
>  that help
> tools like static analyzers and language servers and IDEs parse
> projects. It's very nice have when you hack on something.
>
> It also means that you have to have an entry for every single .c file,
> unless I'm missing something. FreeType bundles several .c files into
> bigger .c files, breaking the database. Werner mentioned that this is
> done because older compilers have worse inlining or dead code
> elimination or something like that. It would still be nice to have the
> database.
>
> The wrapper source files are used for two reasons:

1) Speed up compilation (though this is less of an issue with today's
powerful CPUs and multiple cores)

2) Much better / smaller generated machine code, because all FT_LOCAL
functions are really "static" and can be freely inlined by the simplest
compiler.
Getting the same level of optimization without wrappers requires
link-time-optimization (LTO), which may or may not be available depending
on the toolchain you're using, and cannot always be enabled by projects
embedding the library for multiple reasons (LTO is super slow, ThinLTO
makes it slightly better, but only if you use Clang, etc).

Apart from that, it would be easy to write a script to generate the proper
compilation database from the rules.mk/module.mk file with the patches I've
submitted to the mailing list (in another thread).
Also other tools can output such a database (e.g. GN has
--export-compile-commands=default for example, not sure about Meson).

Something to consider when cleaning up the build system :)
>
> 2020-04-30 9:11 GMT+01:00, suzuki toshiya :
> > The circular dependency is a headache, but I don't think the
> > reconsideration of the building system is good place to discuss
> > the simplification of the dependency between FreeType and harfbuzz.
> >
> > In my understanding, the features of harfbuzz used by FreeType are
> > very small subset, the classification of character encoding, script
> > and language. Although I sympathize with the circular dependency
> > problem, it would not be good idea to cloning them into FreeType
> > source code, because of the different time-frames between FreeType
> > and Unicode related features of harfbuzz (or Unicode itself).
> >
> > Some meta-building system would be the easiest way to avoid the
> > manual and repeated building of FreeType and harfbuzz, aslike some
> > GNU toolchains (binutils + gcc + gdb) ?
> >
> > Regards,
> > mpsuzuki
> >
> > P.S.
> > But, I'm interested in the decision under a situation: if harfbuzz
> > requires libstdc++, should we care the dependency of FreeType?
> >
> >
> > Vincent Torri wrote:
> >> On Thu, Apr 30, 2020 at 8:39 AM Werner LEMBERG  wrote:
> >>>
>  currently, to have harfbuzz support, freetype must be compiled
>  without hb support, then build hb with freetype support, then
>  freetype with hb.
> 
>  it would be nice to remove this circular dependency
> >>> AFAIK, this would only be possible by splitting either HarfBuzz or
> >>> FreeType into two packages, and this won't happen.
> >>
> >> or moving/coying some functions from freetype to hb, or conversely  ?
> >>
> >> Vincent Torri
> >>
> >>
> >
> >
>
>

Re: Build system considerations

[David Turner]

Le ven. 1 mai 2020 à 10:12, Albert Astals Cid  a écrit :

>
>
> I apologize if somebody felt personally wronged by my comment.
>
> Since I don't see anything wrong with it, I would be very happy if you
> could please explain what's wrong with it so I can try to improve myself in
> the future.
>
> Sure, "life bubble" is essentially a reference to the poster's private
life, which seems irrelevant here. "very biased" sounds judgemental, using
it in other contexts may be completely appropriate, but in this specific
one, looks like you may be trying to attack the poster's character instead
of the point he's trying to make.
That may not be what you tried to express, but I guarantee you that's how
it is perceived. It is likely that you misread Behdad's post (which was
*indeed* a bit ambiguous) and drew conclusions too quickly, assuming either
ill-intent or incompetence, but I encourage you to find better ways to
react to this kind of situation in the future.

Also don't worry too much about it, we all make mistakes, me included, and
the Internet is an unforgiving place where many of the bad decisions we
make on public lists are written in stone and searchable decades to come. I
hope you'll still be happy to contribute to the discussion after this :)

- David


> Best Regards,
>   Albert
>
>
>

Re: [patches] Minor build system improvements

[David Turner]

Yes, none of that is urgent :) Feel free to not push them to master for now
(branch or no branch).
I'd still value your input on the content though, hope it's not too scary :)


Le ven. 1 mai 2020 à 10:25, Werner LEMBERG  a écrit :

>
> > Here are two cumulative patches that try to simplify the rules.mk
> > and module.mk used by the FreeType 2 build system.  [...]
>
> Thanks a lot, will check them soon!
>
> Since I'm going to cut a new release soon I wonder whether it makes
> sense to put this patch temporarily into a branch, avoiding issues
> shortly before the new version...
>
>
> Werner
>

[freetype2-demos] Fix compiler warnings

[David Turner]

This patches removes a few compiler warnings when building the FreeType 2
demo programs.
It also replaces a few strncpy() calls with snprintf() for safety /
simplicity.

This should fix https://savannah.nongnu.org/bugs/?58275
From 33ebbd7333d10a5dbac6cac9c37c95a573e24e80 Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Thu, 30 Apr 2020 02:12:59 +0200
Subject: Fix compilation warnings

Fix various compiler warnings when building the FreeType 2
demo programs:

- graph/x11/grx11.c: Changed the return type of
  gr_x11_surface_listen_event() to match the expected type.

- src/: Remove problematic uses of strncpy() and replace
  them with snprintf() which takes the size of the target
  buffer and remove un-needed uses of the alt_filename[]
  array.

Bug: 58257
---
 graph/x11/grx11.c |  4 +++-
 src/compos.c  | 17 +
 src/ftchkwd.c | 16 
 src/ftdump.c  | 16 
 src/ftlint.c  | 17 +
 src/ftmemchk.c| 17 +
 src/ftsbit.c  | 14 --
 src/fttimer.c | 14 ++
 src/fttry.c   | 13 ++---
 9 files changed, 34 insertions(+), 94 deletions(-)

diff --git a/graph/x11/grx11.c b/graph/x11/grx11.c
index c923e0a..9bca06b 100644
--- a/graph/x11/grx11.c
+++ b/graph/x11/grx11.c
@@ -1148,7 +1148,7 @@ typedef  unsigned long   uint32;
   }
 
 
-  static void
+  static int
   gr_x11_surface_listen_event( grX11Surface*  surface,
intevent_mask,
grEvent*   grevent )
@@ -1237,6 +1237,8 @@ typedef  unsigned long   uint32;
   Set_Key:
 grevent->type = gr_key_down;
 grevent->key  = grkey;
+
+return 1;
   }
 
 
diff --git a/src/compos.c b/src/compos.c
index 46ee2ae..a4cdd87 100644
--- a/src/compos.c
+++ b/src/compos.c
@@ -65,7 +65,6 @@
 int   i, file_index;
 unsigned int  id;
 char  filename[1024 + 4];
-char  alt_filename[1024 + 4];
 char* execname;
 char* fname;
 
@@ -90,19 +89,13 @@
 i--;
   }
 
-  filename[1024] = '\0';
-  alt_filename[1024] = '\0';
-
-  strncpy( filename, fname, 1024 );
-  strncpy( alt_filename, fname, 1024 );
-
 #ifndef macintosh
-  if ( i >= 0 )
-  {
-strncpy( filename + strlen( filename ), ".ttf", 4 );
-strncpy( alt_filename + strlen( alt_filename ), ".ttc", 4 );
-  }
+  snprintf(filename, sizeof(filename), "%s%s", fname,
+   (i >= 0 ? ".ttf" : ""));
+#else
+  snprintf(filename, sizeof(filename), "%s", fname);
 #endif
+
   i = strlen( filename );
   fname = filename;
 
diff --git a/src/ftchkwd.c b/src/ftchkwd.c
index 7673847..46194a0 100644
--- a/src/ftchkwd.c
+++ b/src/ftchkwd.c
@@ -119,7 +119,6 @@
 
 int i, file_index;
 charfilename[1024 + 4];
-charalt_filename[1024 + 4];
 char*   execname;
 char*   fname;
 
@@ -160,18 +159,11 @@
 i--;
   }
 
-  filename[1024] = '\0';
-  alt_filename[1024] = '\0';
-
-  strncpy( filename, fname, 1024 );
-  strncpy( alt_filename, fname, 1024 );
-
 #ifndef macintosh
-  if ( i >= 0 )
-  {
-strncpy( filename + strlen( filename ), ".ttf", 4 );
-strncpy( alt_filename + strlen( alt_filename ), ".ttc", 4 );
-  }
+  snprintf(filename, sizeof(filename), "%s%s", fname,
+   (i >= 0 ? ".ttf" : ""));
+#else
+  snprintf(filename, sizeof(filename), "%s", fname);
 #endif
 
   /* Load face */
diff --git a/src/ftdump.c b/src/ftdump.c
index 56c4672..9015d66 100644
--- a/src/ftdump.c
+++ b/src/ftdump.c
@@ -857,7 +857,6 @@
   {
 inti, file;
 char   filename[1024];
-char   alt_filename[1024];
 char*  execname;
 intnum_faces;
 intoption;
@@ -935,12 +934,6 @@
 
 file = 0;
 
-strncpy( filename, argv[file], 1019 );
-strncpy( alt_filename, argv[file], 1019 );
-
-filename[1019] = '\0';
-alt_filename[1019] = '\0';
-
 /* try to load the file name as is, first */
 error = FT_New_Face( library, argv[file], 0, &face );
 if ( !error )
@@ -955,11 +948,10 @@
   i--;
 }
 
-if ( i >= 0 )
-{
-  strncpy( filename + strlen( filename ), ".ttf", 5 );
-  strncpy( alt_filename + strlen( alt_filename ), ".ttc", 5 );
-}
+snprintf(filename, sizeof(filename), "%s%s", argv[file],
+ (i >= 0 ? ".ttf" : ""));
+#else
+snprintf(filename, sizeof(filename), "%s", argv[file]);
 #endif
 
 /* Load face */
diff --git a/src/ftlint.c b/src/ftlint.c
index 02bb4e6..cdb0473 100644
--- a/src/ftlint.c
+++ b/src/ftlint.c
@@ -63,7 +63,6 @@
 int   i, 

Re: [freetype2-demos] Fix compiler warnings

[David Turner]

Le ven. 1 mai 2020 à 13:53, Alexei Podtelezhnikov  a
écrit :

>
> This should fix https://savannah.nongnu.org/bugs/?58275
>
> <0001-Fix-compilation-warnings.patch>
>
>
> We still use Emacs style for commit messages
>

I'm not sure what that means. I've updated the commit message to look like
what is currently in the git log.


> and track them in ChangeLog, which is debatable
>
> Yes, it seems a bit odd these days, but I'll let Werner be the judge on
that :-)
From 1b44f35d259622ebb837d9d00833502ac751df13 Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Thu, 30 Apr 2020 02:12:59 +0200
Subject: [build] Fix compilation warnings

Fix various compiler warnings when building the FreeType 2
demo programs:

* graph/x11/grx11.c: Changed the return type of
  gr_x11_surface_listen_event() to match the expected type.

* src/: Remove problematic uses of strncpy() and replace
  them with snprintf() which takes the size of the target
  buffer and remove un-needed uses of the alt_filename[]
  array.

Reported as https://savannah.nongnu.org/bugs/?58275
---
 graph/x11/grx11.c |  4 +++-
 src/compos.c  | 17 +
 src/ftchkwd.c | 16 
 src/ftdump.c  | 16 
 src/ftlint.c  | 17 +
 src/ftmemchk.c| 17 +
 src/ftsbit.c  | 14 --
 src/fttimer.c | 14 ++
 src/fttry.c   | 13 ++---
 9 files changed, 34 insertions(+), 94 deletions(-)

diff --git a/graph/x11/grx11.c b/graph/x11/grx11.c
index c923e0a..9bca06b 100644
--- a/graph/x11/grx11.c
+++ b/graph/x11/grx11.c
@@ -1148,7 +1148,7 @@ typedef  unsigned long   uint32;
   }
 
 
-  static void
+  static int
   gr_x11_surface_listen_event( grX11Surface*  surface,
intevent_mask,
grEvent*   grevent )
@@ -1237,6 +1237,8 @@ typedef  unsigned long   uint32;
   Set_Key:
 grevent->type = gr_key_down;
 grevent->key  = grkey;
+
+return 1;
   }
 
 
diff --git a/src/compos.c b/src/compos.c
index 46ee2ae..a4cdd87 100644
--- a/src/compos.c
+++ b/src/compos.c
@@ -65,7 +65,6 @@
 int   i, file_index;
 unsigned int  id;
 char  filename[1024 + 4];
-char  alt_filename[1024 + 4];
 char* execname;
 char* fname;
 
@@ -90,19 +89,13 @@
 i--;
   }
 
-  filename[1024] = '\0';
-  alt_filename[1024] = '\0';
-
-  strncpy( filename, fname, 1024 );
-  strncpy( alt_filename, fname, 1024 );
-
 #ifndef macintosh
-  if ( i >= 0 )
-  {
-strncpy( filename + strlen( filename ), ".ttf", 4 );
-strncpy( alt_filename + strlen( alt_filename ), ".ttc", 4 );
-  }
+  snprintf(filename, sizeof(filename), "%s%s", fname,
+   (i >= 0 ? ".ttf" : ""));
+#else
+  snprintf(filename, sizeof(filename), "%s", fname);
 #endif
+
   i = strlen( filename );
   fname = filename;
 
diff --git a/src/ftchkwd.c b/src/ftchkwd.c
index 7673847..46194a0 100644
--- a/src/ftchkwd.c
+++ b/src/ftchkwd.c
@@ -119,7 +119,6 @@
 
 int i, file_index;
 charfilename[1024 + 4];
-charalt_filename[1024 + 4];
 char*   execname;
 char*   fname;
 
@@ -160,18 +159,11 @@
 i--;
   }
 
-  filename[1024] = '\0';
-  alt_filename[1024] = '\0';
-
-  strncpy( filename, fname, 1024 );
-  strncpy( alt_filename, fname, 1024 );
-
 #ifndef macintosh
-  if ( i >= 0 )
-  {
-strncpy( filename + strlen( filename ), ".ttf", 4 );
-strncpy( alt_filename + strlen( alt_filename ), ".ttc", 4 );
-  }
+  snprintf(filename, sizeof(filename), "%s%s", fname,
+   (i >= 0 ? ".ttf" : ""));
+#else
+  snprintf(filename, sizeof(filename), "%s", fname);
 #endif
 
   /* Load face */
diff --git a/src/ftdump.c b/src/ftdump.c
index 56c4672..9015d66 100644
--- a/src/ftdump.c
+++ b/src/ftdump.c
@@ -857,7 +857,6 @@
   {
 inti, file;
 char   filename[1024];
-char   alt_filename[1024];
 char*  execname;
 intnum_faces;
 intoption;
@@ -935,12 +934,6 @@
 
 file = 0;
 
-strncpy( filename, argv[file], 1019 );
-strncpy( alt_filename, argv[file], 1019 );
-
-filename[1019] = '\0';
-alt_filename[1019] = '\0';
-
 /* try to load the file name as is, first */
 error = FT_New_Face( library, argv[file], 0, &face );
 if ( !error )
@@ -955,11 +948,10 @@
   i--;
 }
 
-if ( i >= 0 )
-{
-  strncpy( filename + strlen( filename ), ".ttf", 5 );
-  strncpy( alt_filename + strlen( alt_filename ), ".ttc", 5 );
-}
+snprintf(filename, sizeof(filename), &q

Re: Build system considerations

[David Turner]

buzz we need, and if it's worth
re-implementing in FreeType2 itself. But something tells me implementing
hb_shape() can be really subtle. Any informed opinions on this?

I'm adding two git bundles related to the experiments I've described there
(nothing to consider for submission, imho, for now).
I'll prepare some patches to simplify our existing build files and
customization process as explained above, unless someone has better
suggestions.

Regards,

- Digit









Le jeu. 30 avr. 2020 à 01:39, David Turner  a écrit :

> 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
>
>


freetype2-meta-build.bundle
Description: Binary data


freetype2-meson-build.bundle
Description: Binary data

Re: The TrueType rendering accuracy nightmare

[David Turner]

Le jeu. 14 mai 2020 à 20:35, piotrunio-2...@wp.pl  a
écrit :

> The standard ppem of the test font is: 16
> The standard string of the test font is:  !"#$%
>
> From the image, it is evident that both FreeType and TD renderer (my own
> renderer that relies on FreeType but uses my own rasterizer,
> https://typedesign.netlify.app/tdrenderer.html) are extremely glitchy. It
> is very important to take research into TrueType rendering to properly
> simulate the Microsoft bilevel renderer because it would help render fonts
> correctly. The immense complexity of FreeType's rasterizer is still not
> enough. What a nightmare!
>
> What are we supposed to answer to your post exactly? The bitmap you posted
has little context that explains how it was generated (in particular how
you configured the TrueType interpreter for FreeType), or what we're
supposed to see as defects (hint: when it comes to vector graphics
rendering: differences != defects).
The web page you link to mentions that your code is buggy anyway. We spent
a lot of time tuning the TrueType interpreter and the monochrome
rasterizer, trying to match the bi-level rendering of Windows for popular /
well-known fonts (e.g. Arial), but we do not guarantee that rendering
results will be 100% identical for all fonts, since some of the geometric
computations performed during bytecode execution have varying level of
accuracy / rounding behaviour, depending on their exact implementation
details (which have never been part of the spec). However, if you think we
are wrong, we would be happy to see you research on the topic explaining
how to improve things in the code base, so we can answer to your claims on
a technical basis.

I'm sorry if you thought that FreeType would match rendering 100% of the
time, we never made this claim, even if we try very hard. Of course, you're
free to help us improve the situation.

- David

Re: Build system considerations

[David Turner]

Le dim. 17 mai 2020 à 21:47, Nikolaus Waxweiler  a
écrit :

> First off: all of this sounds fantastic! I always love when stuff is
> deleted :)
>
> > In the end, and this is personal opinion, I find Meson cleaner than
> CMake,
>
> I'd vote for removing CMake support. Its inofficial status means that
> people shouldn't rely on it anyway, even if there inevitably are
> people that do.
>
> > - I would like to drop the dynamic module instantiation / lookup code
> from
> > the library, to simplify certain code paths.
>
> Has this ever been used by anyone?
>
> Yes, I did for a company I worked for a long time, then I rewrote an
open-source version of it (the PFR font driver).
But things are very different now,


> > - There are many things I'd like to get rid of, but apparently [cut off]
>
> ... yes? :D
>
> > - Finally, the largest issue I've seen is the dependency on Harfbuzz. The
> > situation where both libraries depend on each other is a little bit
> > ridiculous. I wonder how much of Harfbuzz we need, and if it's worth
> > re-implementing in FreeType2 itself. But something tells me implementing
> > hb_shape() can be really subtle. Any informed opinions on this?
>
> This can probably only be answered by HarfBuzz people. I think Behdad
> is lurking here somewhere...
>

Re: The TrueType rendering accuracy nightmare

[David Turner]

That's actually great feedback, thanks Piotr, we'll have a look.

Le dim. 17 mai 2020 à 20:47, Alexei Podtelezhnikov  a
écrit :

> >> From the image, it is evident that both FreeType and TD renderer (my
> own renderer that relies on FreeType but uses my own rasterizer,
> https://typedesign.netlify.app/tdrenderer.html) are extremely glitchy. It
> is very important to take research into TrueType rendering to properly
> simulate the Microsoft bilevel renderer because it would help render fonts
> correctly. The immense complexity of FreeType's rasterizer is still not
> enough. What a nightmare!
> >>
> > What are we supposed to answer to your post exactly?
>
> In Piotr's defense, he is much more constructive in his bug reporting.
> I does look that he identified and helped with:
> https://savannah.nongnu.org/bugs/index.php?58373 where the borderline
> pixels on horizontal stems are not turned on
> https://savannah.nongnu.org/bugs/index.php?58352 where rounding in
> bytecode seems to be off by 1.
>
> Alexei
>

Re: Build system considerations

[David Turner]

Le dim. 17 mai 2020 à 21:47, Nikolaus Waxweiler  a
écrit :

> First off: all of this sounds fantastic! I always love when stuff is
> deleted :)
>
> > In the end, and this is personal opinion, I find Meson cleaner than
> CMake,
>
> I'd vote for removing CMake support. Its inofficial status means that
> people shouldn't rely on it anyway, even if there inevitably are
> people that do.
>
>
I think providing a CMakeLists.txt that can be used directly to compile
FreeType as a sub-project in a CMake-based project is still a very useful
thing.
As well as a FindFreeType.cmake or FreeTypeConfig.cmake module to be
installed to make the system library available.

But that's just for the core library. I.e. the ability to build
documentation, install the library, or create distribution packages in
CMake are probably superfluous.
I hope to see something like the following for the future:

- Meson as the primary build system for FreeType developers, which includes
the ability to run tests, sanitizers, coverage analysis, etc.
- Creating a distribution package should ensure the result supports
config/make and CMake out of the box to build a default configuration of
the library (with regards to features/modules, not external dependencies).
The meta-build script would be useful for this.
- The distribution package should probably only contain what's needed to
build the library, and not all the extra tests we may use during
development (maybe we can separate them with git submodules, I don't know
yet).
- A developer that wants to use FreeType with a different module/feature
configuration would have to generate a new version of ftconfig.h/ftoption.h
and use that in his/her own build system.

But as I said, baby steps, so let's not throw CMake support just yet.

By the way, I've compared the size of the stripped libfreetype.so binaries
created by the 3 build systems:

default: 712 KiB
CMake: 812 KiB
Meson: 896 KiB

All generated on Linux from the same sources with the same ftconfig.h /
ftoption.h (in particular with all external dependencies enabled), and with
-fvisibility=hidden enabled for all of them.
I don't understand why there is such a large differenc yet.

Re: [Freetype-devel] Re: GSOC - Distance Fields

[David Turner]

I agree with Alexei that it's probably a good idea to start writing a
prototype with whatever language / format you feel the more fluent first so
we can look at the algorithms and the outputted data.
This can later be rewritten into something more FreeType-specific (e.g.
fixed-floats are better than floats if you have simple ranges like
[-1.0..1.0] in general).

- David

Le mer. 13 mai 2020 à 16:59, Alexei Podtelezhnikov  a
écrit :

> On Wed, May 13, 2020 at 10:37 AM Anuj Verma  wrote:
> >
> > > What do you need from FreeType to calculate DF?
> > > Do you see or know
> > where to find everything you need?
> >
> > I will need the bitmap and/or the outline depending upon the type of
> font. And yes I know where to find those. They both can be accessed from
> FT_Face.
>
> Great! Without further delay, go ahead and write a standalone program
> that calculates DF for a outline glyph in whatever format you choose
> or is appropriate. This is a lot of work by itself. How are you going
> to calculate it straight from Bezier outlines should concern you much
> more than memory issues.
>
> We can think about integrating it into FreeType ,once you have a
> standalone implementation.
>
> Alexei
>
>

Re: Logging Library-GSOC

[David Turner]

Le lun. 18 mai 2020 à 09:03, Priyesh kumar  a
écrit :

> Hey,
> I wanted to ask that after selecting desirable external library how should
> I proceed:
> 1. Should I stick to the existing debugging facility in which filtering of
> log messages is based on debug level comparisons of various FreeType's
> components and only use the external library to write log messages to file
> instead of stderr?
> OR
> 2. Most external libraries provide some log levels capabilities
> themselves, so,  should I think in direction of utilizing those. In case
> yes, then how should that be utilized?
>
> I recommend not baking details of the logging library into the rest of
FreeType whenever possible. One thing that can be done is to send
structured logs from FreeType, i.e. instead of FT_Message() sending a
string to whatever log, the function could instead send a (component,
level, message) tuple, which would allow filtering externally (in the log
library, through whatever means are necessary). Also something useful when
tracing is scoping traces with start/stop events, but that would require
new FT_TRACE_XXX() macros, so should probably be considered a stretch goal.
Just keep this in mind if you intend to modify that part of the code.


> In the 2nd case, FreeType's logger will completely depend on the external
> library, and developers will also need to learn some new information to use
> the logger. And In the worst-case scenario, if the external library drops
> some functionality, we will need to make amendments to the logger.
>
> I still don't know what the benefits of these external logging libraries
will be. Can you clarify what are we supposed to gain from this in
practical terms? Every dependency we add to the library becomes a
maintenance burden, so I would be in favor of the least coupling possible.

According to me, the 1st option is better since the experience of using the
> logger will be the same for the client and developers and the only
> dependency of FreeType on external library will be of writing log messages
> to a file.
>
> Please guide me...
> Thanks
> Priyesh
>
>

Patches to remove Jamfiles from freetype2 and freetype2-demos

[David Turner]

Here are two patches to remove the Jamrules/Jamfiles from the build and
documentation.

- David
From bfae69d8320e269975ba59f6293031242e9d7653 Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Mon, 18 May 2020 09:16:12 +0200
Subject: [build] Remove Jamfile files from the tree.

These have not been used in a very very long time, so
better remove them. A corresponding patch will be submitted
to the freetype2-demos repository.
---
 Jamfile| 224 -
 Jamrules   |  71 -
 builds/unix/configure.raw  |   4 -
 devel/ftoption.h   |   2 +-
 include/freetype/config/ftoption.h |   2 +-
 src/Jamfile|  19 ---
 src/autofit/Jamfile|  53 ---
 src/base/Jamfile   |  90 
 src/bdf/Jamfile|  31 
 src/bzip2/Jamfile  |  18 ---
 src/cache/Jamfile  |  37 -
 src/cff/Jamfile|  36 -
 src/cid/Jamfile|  34 -
 src/gxvalid/Jamfile|  52 ---
 src/gzip/Jamfile   |  16 ---
 src/lzw/Jamfile|  16 ---
 src/otvalid/Jamfile|  37 -
 src/pcf/Jamfile|  32 -
 src/pfr/Jamfile|  35 -
 src/psaux/Jamfile  |  45 --
 src/pshinter/Jamfile   |  34 -
 src/psnames/Jamfile|  31 
 src/raster/Jamfile |  32 -
 src/sfnt/Jamfile   |  42 --
 src/smooth/Jamfile |  32 -
 src/tools/Jamfile  |   5 -
 src/truetype/Jamfile   |  37 -
 src/type1/Jamfile  |  35 -
 src/type42/Jamfile |  32 -
 src/winfonts/Jamfile   |  16 ---
 30 files changed, 2 insertions(+), 1148 deletions(-)
 delete mode 100644 Jamfile
 delete mode 100644 Jamrules
 delete mode 100644 src/Jamfile
 delete mode 100644 src/autofit/Jamfile
 delete mode 100644 src/base/Jamfile
 delete mode 100644 src/bdf/Jamfile
 delete mode 100644 src/bzip2/Jamfile
 delete mode 100644 src/cache/Jamfile
 delete mode 100644 src/cff/Jamfile
 delete mode 100644 src/cid/Jamfile
 delete mode 100644 src/gxvalid/Jamfile
 delete mode 100644 src/gzip/Jamfile
 delete mode 100644 src/lzw/Jamfile
 delete mode 100644 src/otvalid/Jamfile
 delete mode 100644 src/pcf/Jamfile
 delete mode 100644 src/pfr/Jamfile
 delete mode 100644 src/psaux/Jamfile
 delete mode 100644 src/pshinter/Jamfile
 delete mode 100644 src/psnames/Jamfile
 delete mode 100644 src/raster/Jamfile
 delete mode 100644 src/sfnt/Jamfile
 delete mode 100644 src/smooth/Jamfile
 delete mode 100644 src/tools/Jamfile
 delete mode 100644 src/truetype/Jamfile
 delete mode 100644 src/type1/Jamfile
 delete mode 100644 src/type42/Jamfile
 delete mode 100644 src/winfonts/Jamfile

diff --git a/Jamfile b/Jamfile
deleted file mode 100644
index 76ccdeed0..0
--- a/Jamfile
+++ /dev/null
@@ -1,224 +0,0 @@
-# FreeType 2 top Jamfile.
-#
-# Copyright (C) 2001-2020 by
-# David Turner, Robert Wilhelm, and Werner Lemberg.
-#
-# This file is part of the FreeType project, and may only be used, modified,
-# and distributed under the terms of the FreeType project license,
-# LICENSE.TXT.  By continuing to use, modify, or distribute this file you
-# indicate that you have read the license and understand and accept it
-# fully.
-
-
-# The HDRMACRO is already defined in FTJam and is used to add
-# the content of certain macros to the list of included header
-# files.
-#
-# We can compile FreeType 2 with classic Jam however thanks to
-# the following code
-#
-if ! $(JAM_TOOLSET)
-{
-  rule HDRMACRO
-  {
-# nothing
-  }
-}
-
-
-# We need to invoke a SubDir rule if the FT2 source directory top is not the
-# current directory.  This allows us to build FreeType 2 as part of a larger
-# project easily.
-#
-if $(FT2_TOP) != $(DOT)
-{
-  SubDir  FT2_TOP ;
-}
-
-
-# The following macros define the include directory, the source directory,
-# and the final library name (without library extensions).  They can be
-# replaced by other definitions when the library is compiled as part of
-# a larger project.
-#
-
-# Name of FreeType include directory during compilation.
-# This is relative to FT2_TOP.
-#
-FT2_INCLUDE_DIR ?= include ;
-
-# Name of FreeType source directory during compilation.
-# This is relative to FT2_TOP.
-#
-FT2_SRC_DIR ?= src ;
-
-# Name of final library, without extension.
-#
-FT2_LIB ?= $(LIBPREFIX)freetype ;
-
-
-# Define FT2_BUILD_INCLUDE to point to your build-specific directory.
-# This is prepended to FT2_INCLUDE_DIR.  It can be used to specify
-# the location of a custom  which will point to custom
-# versions of `ftmodule.h' and `ftoption.h', for example.
-#
-FT2_BUILD_INCLUDE ?= ;
-
-# The list of modules to compile on any given build of the library.
-# By default, this wi

[patch] Remove obsolete HAVE_STDINT_H probing

[David Turner]

It turns out the macro is never used, anad  is never included.
From 3d9ce21da3fb4af2a90147ee513add6542808dcd Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Mon, 18 May 2020 09:33:38 +0200
Subject: [build] Remove obsolete HAVE_STDINT_H probing macro.

This macro was updated by the unix configure script and the
CMakeLists.txt one, but is never used in the source tree
(nor is  included anywhere), so removing it entirely
should be safe.
---
 CMakeLists.txt  | 6 --
 builds/unix/ftconfig.in | 1 -
 2 files changed, 7 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index a7aec4d05..17787a171 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -240,7 +240,6 @@ endif ()
 if (UNIX)
   check_include_file("unistd.h" HAVE_UNISTD_H)
   check_include_file("fcntl.h" HAVE_FCNTL_H)
-  check_include_file("stdint.h" HAVE_STDINT_H)
 
   file(READ "${PROJECT_SOURCE_DIR}/builds/unix/ftconfig.in"
 FTCONFIG_H)
@@ -254,11 +253,6 @@ if (UNIX)
   "#undef +(HAVE_FCNTL_H)" "#define \\1 1"
   FTCONFIG_H "${FTCONFIG_H}")
   endif ()
-  if (HAVE_STDINT_H)
-string(REGEX REPLACE
-  "#undef +(HAVE_STDINT_H)" "#define \\1 1"
-  FTCONFIG_H "${FTCONFIG_H}")
-  endif ()
   string(REPLACE "/undef " "#undef "
 FTCONFIG_H "${FTCONFIG_H}")
 else ()
diff --git a/builds/unix/ftconfig.in b/builds/unix/ftconfig.in
index 7f3737776..a8c7d8acd 100644
--- a/builds/unix/ftconfig.in
+++ b/builds/unix/ftconfig.in
@@ -56,7 +56,6 @@ FT_BEGIN_HEADER
 
 #undef HAVE_UNISTD_H
 #undef HAVE_FCNTL_H
-#undef HAVE_STDINT_H
 
   /* There are systems (like the Texas Instruments 'C54x) where a `char`  */
   /* has 16~bits.  ANSI~C says that `sizeof(char)` is always~1.  Since an */
-- 
2.20.1

Re: Logging Library-GSOC

[David Turner]

Le lun. 18 mai 2020 à 10:49, Priyesh kumar  a
écrit :

> Thanks for the reply...
>
> *>I recommend not baking details of the logging library into the rest of
> FreeType whenever possible. One thing that can be done is to send
> structured logs from FreeType, i.e. instead of >FT_Message() sending a
> string to whatever log, the function could instead send a (component,
> level, message) tuple, which would allow filtering externally (in the log
> library, through >whatever means are necessary). Also something useful when
> tracing is scoping traces with start/stop events, but that would require
> new FT_TRACE_XXX() macros, so should probably be >considered a stretch
> goal. Just keep this in mind if you intend to modify that part of the code.*
> Got that...will keep this in mind while exploring external logging
> libraries.
>
> *>I still don't know what the benefits of these external logging libraries
> will be. Can you clarify what are we supposed to gain from this in
> practical terms? Every dependency we add to the >library becomes a
> maintenance burden, so I would be in favor of the least coupling possible.*
> Yes, I agree that any new library adds to maintenance burden but we
> already had a discussion around this sometime back. The summary of the
> discussion was that a well maintained external library comes with mature
> API's and gets a lot of testing and hence that would be ideal to integrate.
> Please refer to this mail thread for details(
> https://lists.nongnu.org/archive/html/freetype-devel/2020-02/msg00025.html )
> and let me know in case of any concern.
>
> I'm afraid, this thread doesn't seem to answer any of my concerns. Also in
the last message you said you would explore logging libraries, and I would
be curious about the results, i.e.:

- Can you give one *concrete example* of an actual logging library that
would be useful for FreeType developers for development purposes. Because I
failed to find one.

- What would be the actual benefits to using an external logging library
really? The only thing I can think of is using structured debug messages
(i.e. sending a (component, level, message) tuple instead of a string to
whatever receives the log messages, to allow better filtering). But we can
easily refactor ftdebug.c to do that, with a default implementation that
prints to stderr / , and a debug-only API to inject a custom sink callback
at runtime. Only then can we decide to optionally provide a sink that
depends on a specific third-party library, as an option.

- Do you plan to improve the debugging macros used by FreeType. If so, how
exactly?

Note that the quality of the logging library(ies) has nothing to do with
this. I would rather not introduced a surperfluous dependency to the build.

- David


> Thanks,
> Priyesh
>

Re: Build system considerations

[David Turner]

Le mar. 19 mai 2020 à 14:09, Hugh McMaster  a
écrit :

> On Mon, 18 May 2020 at 23:59, Werner LEMBERG wrote:
> > > - Meson as the primary build system for FreeType developers, which
> > >   includes the ability to run tests, sanitizers, coverage analysis,
> > >   etc.
> >
> > It seems that Meson can create cmake package files, and probably build
> > scripts, too.  Wouldn't that be the best solution?  I can also imagine
> > that Meson builds `configure.ac`...
>
> Is there any opportunity to avoid modifying ftoption.h directly to
> enable, say, subpixel rendering with a new build system? Carrying
> permanent patches for downstream packaging is annoying.
>
> Personally, I'd like to be able to enable various options via
> configure flags or a configurable file (JSON, anyone?) that's not a C
> header. Python could do nicely here.
>
> I think there is an opportunity here. The current customization scheme was
designed for
embedded system development where you could not assume anything fancy in the
development environment (e.g. developing on DOS or Win9x), so modifying
header files
and relying on GNU Make was the sanest possible option at the time. The
auto-tools
scripts came after that, which shows.

We probably want to introduce that gradually though (i.e. add the configure
option while
still supporting custom ftoption.h in a first step, and warning about the
fact that the latter
will change in the future, probably with some judicious use of #warning and
macros).

But for now, I'd rather work on removing the modules/driver system from the
implementation,
which also touches the subject of customizability of the build, which is
still very important to me.


> Other than that, the removal of RPATHs should be revisited. That's a
> topic for another thread.
>

Yes, please start a thread about the issue and why you think it's a
good/bad idea.

Re: Logging Library-GSOC

[David Turner]

Le mar. 19 mai 2020 à 09:30, Priyesh kumar  a
écrit :

> Thanks for the reply,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *>Basically yes.  As an improvement, I would like that the value of
> the>`FT_COMPONENT` macro can be displayed optionally, e.g.>[afhints] foo
> bar>[ttgxvar] sproink>...>The idea is that you first do a run with
> `FT2_DEBUG=any:7:labels` to>see all those tags, then redo it with, say,>
> FT2_DEBUG=afhints:7>to get only the 'afhints' debug messages if this is
> what you need for>debugging.*
>
> Thanks, I will keep this in mind...
>
>
>
> *> >2. Most external libraries provide some log levels capabilities>>
> themselves, so, should I think in direction of utilizing>>those. In
> case yes, then how should that be utilized?*
> *>Please elaborate and show examples.*
>
>
>
>
> *>> In the 2nd case, FreeType's logger will completely depend on the>>
> external library, and developers will also need to learn some new>>
> information to use the logger.  And In the worst-case scenario, if>> the
> external library drops some functionality, we will need to make>>
> amendments to the logger.*
> *>I agree.*
>


> In the 2nd point I wanted to ask that should I completely reimplement the
> logger using APIs of external library.
> Since you agreed with the below point, I don't think the 2nd point makes
> any sense now...
> Will proceed with the 1st point...
>
> I'm sorry but that doesn't make any sense to me. There is absolutely no
point in making part of FreeType depend on a specific external logger
library at this point.
Also we don't even know which library, or which API. This looks like a
solution looking for a problem.

Also we don't necessarily send logs to stderr, e.g. there are already
several versions of ftdebug.c, i.e. the one under builds/windows/ uses
OutputDebugStringA(), or the one under builds/amiga/ uses KVPrintf(), etc..
All Werner wants is structured outputs, which can easily be done in the
current code base with minimal refactor of the FT_TRACE macro
implementations.

I'm sorry but all I see in your posts are vague promises and little
concrete ideas.

I recommend you start presenting how you plan modifying the current code
base to achieve structured outputs (in very technical terms), then explain
how one could hook FreeType to a *specific* logging library (e.g. with a
runtime callback, or a configurable dependency).
And for each step, explain the benefits / drawbacks of the approach you're
suggesting.

Thanks

- David


> Thanks,
> Priyesh
>
> On Mon, May 18, 2020 at 9:03 PM Werner LEMBERG  wrote:
>
>>
>>
>>
>> > I wanted to ask that after selecting desirable external library how
>> > should I proceed:
>>
>> [For David T.: The idea is to statically link the library into
>>  FreeType using a git submodule.  In other words, it's 'external' only
>>  because it is developed by other people.]
>>
>> > 1. Should I stick to the existing debugging facility in which
>> >filtering of log messages is based on debug level comparisons of
>> >various FreeType's components and only use the external library
>> >to write log messages to file instead of stderr?
>>
>> Basically yes.  As an improvement, I would like that the value of the
>> `FT_COMPONENT` macro can be displayed optionally, e.g.
>>
>>   [afhints] foo bar
>>   [ttgxvar] sproink
>>   ...
>>
>> The idea is that you first do a run with `FT2_DEBUG=any:7:labels` to
>> see all those tags, then redo it with, say,
>>
>>   FT2_DEBUG=afhints:7
>>
>> to get only the 'afhints' debug messages if this is what you need for
>> debugging.
>>
>> > 2. Most external libraries provide some log levels capabilities
>> >themselves, so, should I think in direction of utilizing
>> >those. In case yes, then how should that be utilized?
>>
>> Please elaborate and show examples.
>>
>> > In the 2nd case, FreeType's logger will completely depend on the
>> > external library, and developers will also need to learn some new
>> > information to use the logger.  And In the worst-case scenario, if
>> > the external library drops some functionality, we will need to make
>> > amendments to the logger.
>>
>> I agree.
>>
>> > According to me, the 1st option is better since the experience of
>> > using the logger will be the same for the client and developers and
>> > the only dependency of FreeType on external library will be of
>> > writing log messages to a file.
>>
>> Yep.
>>
>>
>> Werner
>>
>

Re: [freetype2] Remove #include FT_XXX_H includes from library sources

[David Turner]

And here's the patch to fix freetype2-demos compilation first.

Le jeu. 4 juin 2020 à 02:42, David Turner  a écrit :

> Since nobody does development on DOS or Windows 9x anymore, we can finally
> drop the requirement to use file names limited to the 8.3 format, which was
> the reason why the FT_LONG_HEADER_NAME_H macros were introduced in the
> first place.
>
> This bundle contains patches to replace all #include FT_XXX_H statements
> from the library into the corresponding #include 
> include.
>
> Note that:
>
> - This doesn't try to rename any file.
>
> - The macros are still defined by  to avoid
> breaking existing client codes. We will likely have to live with them for a
> _very_ long time, but that's life.
>
> - A few configuration-related macros are kept (e.g. FT_CONFIG_CONFIG_H,
> FT_MODULE_H) are kept intentionally. I'd like to get rid of FT_MODULE_H
> entirely in the future by refactoring the way feature configuration is
> performed, but that's for a very different time.
>
> - The public headers should not be renamed. On the other hand, anything
> under include/freetype/internal/ might be renamed to clearer names in the
> future.
>
> IMPORTANT: This currently breaks ftdiff.c in freetype2-demos because it
> tries to include FT_INTERNAL_OBJECTS_H, this should be addressed by a
> different patch.
>
> The bundle contains 88 commits. Each one renaming a single macro. I
> recommend submitting the bundle squashed after verifying that everything
> works, but I'll let you choose otherwise if you prefer :-)
>
> - David
>
From d6e2e57d08ab4c7db628be2ea8a01bc3ffc27482 Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Thu, 4 Jun 2020 02:46:45 +0200
Subject: [build] Include internal headers by their real names.

The FT_INTERNAL_XXX_H macros are going to disappear.
---
 mac/ftoldmac.c  | 6 +++---
 src/compos.c| 2 +-
 src/ftdiff.c| 4 ++--
 src/ftdump.c| 6 +++---
 src/ftgrid.c| 6 +++---
 src/ftinspect/engine/engine.cpp | 4 ++--
 src/ftvalid.c   | 8 
 src/ftview.c| 6 +++---
 8 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/mac/ftoldmac.c b/mac/ftoldmac.c
index 8b02f85..04a97c4 100644
--- a/mac/ftoldmac.c
+++ b/mac/ftoldmac.c
@@ -29,12 +29,12 @@
 #include FT_TRUETYPE_IDS_H
 
   /* the following header shouldn't be used in normal programs */
-#include FT_INTERNAL_DEBUG_H
+#include 
 
   /* showing driver name */
 #include FT_MODULE_H
-#include FT_INTERNAL_OBJECTS_H
-#include FT_INTERNAL_DRIVER_H
+#include 
+#include 
 
   /* FSSpec functions are deprecated since Mac OS X 10.4 */
 #ifndef HAVE_FSSPEC
diff --git a/src/compos.c b/src/compos.c
index 1b76ae3..7d5d19c 100644
--- a/src/compos.c
+++ b/src/compos.c
@@ -17,7 +17,7 @@
 
 #include 
 #include FT_FREETYPE_H
-#include FT_INTERNAL_GLYPH_LOADER_H
+#include 
 
 #include 
 #include 
diff --git a/src/ftdiff.c b/src/ftdiff.c
index c1c2e5e..0728714 100644
--- a/src/ftdiff.c
+++ b/src/ftdiff.c
@@ -24,8 +24,8 @@
   /* showing driver name -- the two internal header files */
   /* shouldn't be used in normal programs */
 #include FT_MODULE_H
-#include FT_INTERNAL_OBJECTS_H
-#include FT_INTERNAL_DRIVER_H
+#include 
+#include 
 
 #include 
 #include 
diff --git a/src/ftdump.c b/src/ftdump.c
index b6f2b27..c3e277e 100644
--- a/src/ftdump.c
+++ b/src/ftdump.c
@@ -17,12 +17,12 @@
 #include FT_MULTIPLE_MASTERS_H
 
   /* the following header shouldn't be used in normal programs */
-#include FT_INTERNAL_DEBUG_H
+#include 
 
   /* showing driver name */
 #include FT_MODULE_H
-#include FT_INTERNAL_OBJECTS_H
-#include FT_INTERNAL_DRIVER_H
+#include 
+#include 
 
   /* error messages */
 #undef FTERRORS_H_
diff --git a/src/ftgrid.c b/src/ftgrid.c
index 29df45f..8a73bf2 100644
--- a/src/ftgrid.c
+++ b/src/ftgrid.c
@@ -20,12 +20,12 @@
 #include 
 
   /* the following header shouldn't be used in normal programs */
-#include FT_INTERNAL_DEBUG_H
+#include 
 
   /* showing driver name */
 #include FT_MODULE_H
-#include FT_INTERNAL_OBJECTS_H
-#include FT_INTERNAL_DRIVER_H
+#include 
+#include 
 
 #include FT_STROKER_H
 #include FT_SYNTHESIS_H
diff --git a/src/ftinspect/engine/engine.cpp b/src/ftinspect/engine/engine.cpp
index b770846..d8bb903 100644
--- a/src/ftinspect/engine/engine.cpp
+++ b/src/ftinspect/engine/engine.cpp
@@ -13,8 +13,8 @@
 #include FT_LCD_FILTER_H
 
 // internal FreeType header files; only available in the source code bundle
-#include FT_INTERNAL_DRIVER_H
-#include FT_INTERNAL_OBJECTS_H
+#include 
+#include 
 
 
 /
diff --git a/src/ftvalid.c b/src/ftvalid.c
index b4474ff..c8bae7d 100644
--- a/src/ftvalid.c
+++ b/src/ftvalid.c
@@ -26,10 +26,10 @@
 #include FT_GX_VALID

Re: [freetype2] Remove #include FT_XXX_H includes from library sources

[David Turner]

Le ven. 5 juin 2020 à 00:00, Werner LEMBERG  a écrit :

>
> This is the first time ever that I got a git bundle to handle, and I'm
> stuck.  I don't know how to apply it to the git repository.  Trying
>
>   git pull freetype2-remove-macro-includes.bundle
>
> results in
>
>   fatal: Couldn't find remote ref HEAD
>
> Ditto for `git fetch`.
>
> Please advise.
>
> No problem :-) there are several ways to use bundles (and I agree the
documentation is lacking):

1) The easy way: use it as a git remote:

$ git remote add bundle /path/to/bundle
$ git fetch bundle
>From /home/david/Downloads/freetype2-remove-macro-includes.bundle
 * [new branch]  remove-macro-includes ->
bundle/remove-macro-includes

This is convenient because this fetches all the heads from the bundle at
once, and gives you remote branches for all the heads in the bundle.

2) The hard way: git fetch /path/to/bundle 

Where  is one of the references listed by "git bundle list-heads
/path/to/bundle". For this specific bundle:

$ git bundle list-heads ~/Downloads/freetype2-remove-macro-includes.bundle
2ebe58073a90538b64170fc274dc5530032726d8 refs/heads/remove-macro-includes

So you could then try:

$ git fetch ~/Downloads/freetype2-remove-macro-includes.bundle
remove-macro-includes
>From /home/david/Downloads/freetype2-remove-macro-includes.bundle
 * branchremove-macro-includes -> FETCH_HEAD

Note that the fetch only creates FETCH_HEAD (which will be overwritten on a
future fetch), so you don't have a label defined in your repository.
You can create a branch from it easily with:

$ git branch remove-macro-includes FETCH_HEAD

Hope this helps. Let me know if you prefer a different format. I can
probably attach patch files generated with "git format-patch" as well, but
bundles are far more convenient and safe.

- David

PS: To create a bundle that includes all patches from origin/master to a
local branch, use:

$ git bundle create /path/to/new/bundle origin/master..my_branch

This creates a head named "my_branch" in the bundle.







> Werner
>

Re: GSOC Build tests

[David Turner]

Le sam. 6 juin 2020 à 15:31, Werner LEMBERG  a écrit :

>
> Hello Greg,
>
>
> > So over the week I started writing continuous integration build
> > tests for several platforms. You can preview them here:
> >
> https://dev.azure.com/fundies/freetype2/_build/results?buildId=146&view=results
>
> this looks great!
>
> I agree, thank you for doing this.

> Please let me know if there are any additional compilers, operating
> > systems or configurations you would like tested.
>
> Maybe Android?  I'm not sure whether this is necessary, given that it
> is basically a Unix system.
>
> I don't think it's needed at this point.


> > Also, if you would like any other build system tested other than
> > cmake tested.
>
> Actually, the 'official' build system is
>
>   ./configure 
>   make
>   make install
>
> This is only for Unix systems, the GNU-Make build system should work on
Windows and supports a number of compilers.
For compiing on Windows with a gcc compiler, you would do:

  make setup
  make

I don't think there is an install step though, it just generate a
freetype.dll under objs/ iirc (I have tested that in a long time).

Other compilers are supported with "make setup ", you can type "make
setup list' to see the list of available values.
"visualc" corresponds to Visual Studio (but probably an older version, like
the 2013, so I'm not sure it would work).
It it worth giving it a try, but if this fails, just let us know, and I'll
try to fix it.

The cmake stuff is contributed code not maintained by the FreeType
> team.  We probably will migrate to another build system like Meson in
> the near future; you can find some discussion in this thread:
>
>
> https://lists.nongnu.org/archive/html/freetype-devel/2020-05/msg00103.html
>
> > I would also like to test freetype-demos but I'm not sure if those
> > are only valid on desktop configurations.
>
> Yes, it might be problematic to test the demo programs that uses a
> GUI.  Maybe (some of) the command line tools will work.
>
> All demo programs should compile and run on Win32, if not that's a bug we
should fix.
Only ftgamma / ftgrid / ftview are GUI programs IIRC.

In the future, I'd like to add unit and regression tests to the library
though, but that will happen after the build system switch.

> I did have some issues with Mac/iOS builds as your repo seems to
> > have an iOS.cmake that is 6 years old and incompatible with modern
> > xcode and I had so set a blank signing key for OS X.  I found a
> > newer iOS.cmake to replace your current one and it seems to work
> > however it does not currently bundle the binaries in the packaging
> > stage.  Please let me know if you have better solution for either of
> > these.
>
> Maybe other people can chime in who have more experience with cmake.
>
> That's the kind of issues you will get all the time with CMake, there are
10 different versions of the tool being used in the wild, which are mostly
similar,
but it's very hard to get CMake modules from third-party libraries that
work well for everyone (especially when cross-compiling with different
sysroots,
many will pick up the wrong headers / versions of the module's dependencies
due to subtle configuration issues)

Also one of the reasons why I'm not a huge fan of CMake, even if it's the
"standard".

Unfortunately, I don't have a solution for the iOS issue you describe.


> > Lastly, I'm not familiar with how to commit to your repo I only get
> > "fatal: remote error: access denied or repository not exported:
> > /freetype/freetype2.git" without ever being prompted for a login.
>
> This is an issue that must be fixed.  Have you registered your SSH
> public key?
>
>   https://savannah.gnu.org/maintenance/SshAccess/
>
> (be careful not to add a final, additional newline if you submit the
> key).
>
> After doing the above, you should be able to check out read/write
> versions of the FreeType git repositories as
>
>   git clone fund...@git.sv.gnu.org/srv/git/freetype/freetype2.git
>   git clone fund...@git.sv.gnu.org/srv/git/freetype/freetype2-demos.git
>
> > So instead here is a patch:
> >
> https://github.com/fundies/freetype2/commit/564f8d163fbed71cccd1a9ea5733e28da82b7d7e.patch
>
> I hope you will be able to check this into your personal branch by
> yourself soon :-)
>
>
> Werner
>
>

Re: GSOC Build tests

[David Turner]

Le sam. 6 juin 2020 à 21:53, Greg Williamson  a écrit :

> So autotools is the current build system but that will only work on linux
> and mingw correct? I can certainly check freetype builds with autotools on
> those platforms but I don't think it's compatible with msvc & xcode. I
> can't really check meson if it hasn't been checked in yet afaict. I'm not
> the biggest fan of cmake and your cmakelists does seem to have a few issues
> but I think it's far more widely used than meson. I see many projects and
> even IDEs such as visual studio / qtrceator / codelite and more have
> built-in cmake support whereas meson is more of a niche. I don't mind
> adding build tests for meson if that's the route you choose but I think
> fixing your cmake issues is more practical. As for demos, I only mean to
> check that they compile against the current freetype. I assume however
> these demos will not build on iOS so I won't try testing demos there. If
> I'm incorrect on that let me know and I'll adjust the tests accordingly. As
> I go forward and start functionality tests I will likely write a standalone
> program that links freetype and  google test using cmake and as I am most
> familiar with cmake but it shouldn't be much work to convert it to whatever
> build system you decide on later.
>
> I agree there is little point in building the demos for iOS. I would also
avoid Android, because you won't be able to run the GUI programs anyway
(programming model is too different). Technically, you can run command-line
programs on Android, but this involves pushing the executables and test
data files with "adb", which is rather involved. Given how portable the
library is, there is no good reason to support that in our testing scheme.


> Thanks for instructions on git. I typically use github with my login
> directly and not ssh keys so I wasn't familiar with that process. I'll get
> that setup asap and push my commits there.
>
> On Sat, Jun 6, 2020 at 9:31 AM Werner LEMBERG  wrote:
>
>>
>> Hello Greg,
>>
>>
>> > So over the week I started writing continuous integration build
>> > tests for several platforms. You can preview them here:
>> >
>> https://dev.azure.com/fundies/freetype2/_build/results?buildId=146&view=results
>>
>> this looks great!
>>
>> > Please let me know if there are any additional compilers, operating
>> > systems or configurations you would like tested.
>>
>> Maybe Android?  I'm not sure whether this is necessary, given that it
>> is basically a Unix system.
>>
>> > Also, if you would like any other build system tested other than
>> > cmake tested.
>>
>> Actually, the 'official' build system is
>>
>>   ./configure 
>>   make
>>   make install
>>
>> The cmake stuff is contributed code not maintained by the FreeType
>> team.  We probably will migrate to another build system like Meson in
>> the near future; you can find some discussion in this thread:
>>
>>
>> https://lists.nongnu.org/archive/html/freetype-devel/2020-05/msg00103.html
>>
>> > I would also like to test freetype-demos but I'm not sure if those
>> > are only valid on desktop configurations.
>>
>> Yes, it might be problematic to test the demo programs that uses a
>> GUI.  Maybe (some of) the command line tools will work.
>>
>> > I did have some issues with Mac/iOS builds as your repo seems to
>> > have an iOS.cmake that is 6 years old and incompatible with modern
>> > xcode and I had so set a blank signing key for OS X.  I found a
>> > newer iOS.cmake to replace your current one and it seems to work
>> > however it does not currently bundle the binaries in the packaging
>> > stage.  Please let me know if you have better solution for either of
>> > these.
>>
>> Maybe other people can chime in who have more experience with cmake.
>>
>> > Lastly, I'm not familiar with how to commit to your repo I only get
>> > "fatal: remote error: access denied or repository not exported:
>> > /freetype/freetype2.git" without ever being prompted for a login.
>>
>> This is an issue that must be fixed.  Have you registered your SSH
>> public key?
>>
>>   https://savannah.gnu.org/maintenance/SshAccess/
>>
>> (be careful not to add a final, additional newline if you submit the
>> key).
>>
>> After doing the above, you should be able to check out read/write
>> versions of the FreeType git repositories as
>>
>>   git clone fund...@git.sv.gnu.org/srv/git/freetype/freetype2.git
>>   git clone fund...@git.sv.gnu.org/srv/git/freetype/freetype2-demos.git
>>
>> > So instead here is a patch:
>> >
>> https://github.com/fundies/freetype2/commit/564f8d163fbed71cccd1a9ea5733e28da82b7d7e.patch
>>
>> I hope you will be able to check this into your personal branch by
>> yourself soon :-)
>>
>>
>> Werner
>>
>

Re: [freetype2] Remove #include FT_XXX_H includes from library sources

[David Turner]

Le mar. 9 juin 2020 à 01:06, Alexei Podtelezhnikov  a
écrit :

>
> >> We can remove  as well, can't we? It is only used to
> >> define the macros. So it is either ft2build.h and macros or neither.
> >
> > Not until all the consumers of FreeType are adapted to use direct
> > header inclusion instead of the macros,
>
> Perhaps I was not clear. There is no point to have #include 
> in the FreeType source files that do not use macros any longer. The files
> that use FT_CONFIG_OPTION_H still need it.
>
> But I do share the sentiment that it is probably too late for this kind of
> change. The ship has sailed.
>
> I agree, we simply cannot change the source API at this point, which means
we will need to support , the macros for the public headers,
and *avoid* renaming the public headers themselves (because something is
bound to break if we do).

On the other hand, what we can do is:

   - Rename / move any internal header. Personally, I'm not too fond of
   CamelCase or Mixed_Camel_Case in header names :)
   - Stop using  and the macros inside the FreeType sources
   (the patch is a first step in this direction).
   - If we deprecate a public API (e.g. I'm preparing patches to do that
   for FT_Add_Module() and related functions), they need to still be available
   and defined (as well as all types they depend on), but the implementation
   return FT_Err_Unimplemented_Feature.
   Of course, the doc should be updated with a "don't use this" message or
   something along that line.

I would also like to get rid of ftmodule.h, and change the ftconfig.h file
to only contain user-selectable options (it currently contains definitions
that really belong to the implementation, and that nobody in its right mind
would use in client code anyway), but this requires changing the way the
library's features are configured, and that will probably happen after the
module-API-deprecation anyway, or maybe after we change our primary build
system. But none of that is urgent.

Re: [freetype2] Remove #include FT_XXX_H includes from library sources

[David Turner]

Le lun. 8 juin 2020 à 13:37, Werner LEMBERG  a écrit :

>
> Hello David,
>
>
> > Since nobody does development on DOS or Windows 9x anymore, we can
> > finally drop the requirement to use file names limited to the 8.3
> > format, which was the reason why the FT_LONG_HEADER_NAME_H macros
> > were introduced in the first place.  [...]
>
> Here's my patch, condensing your commits, adding some documentation,
> and fixing some glitches.  Please check!
>
> > - The public headers should not be renamed.
>
> What do you think about introducing a bunch of header files with long
> names that do something like the following:
>
>   file `FT_Multiple_Masters.h`:
>
> #include 
> /* EOF */
>
>
If this is about the public headers, why not, but let's do this in a future
patch (with some documentation explaining what the new headers are, some
simple sed or python scripts so developers can easily change the includes
in their sources if they want to).
Also, I would rather have  include the new public header instead,
it's cleaner, but I wonder if this is going to break scripts that try to
list the headers explicitly in build systems or packaging scripts.

As for the name, we should keep using  format as part of
the official source API, because it avoids a lot of needless conflicts to
happen.
On the other hand, we can use #include "ftmm.h" (instead of )
because this first search in the header's current directory.

To be honest, I don't consider that a big priority for now, compared to the
other build refactors / cleanups. It's easier not to do anything for now,
to avoid breaking things unexpectedly for our users :-)

>
>   Werner
>

Re: [freetype2] Remove #include FT_XXX_H includes from library sources

[David Turner]

Thanks Werner, the patch looks good to me :-)

Le lun. 8 juin 2020 à 13:37, Werner LEMBERG  a écrit :

>
> Hello David,
>
>
> > Since nobody does development on DOS or Windows 9x anymore, we can
> > finally drop the requirement to use file names limited to the 8.3
> > format, which was the reason why the FT_LONG_HEADER_NAME_H macros
> > were introduced in the first place.  [...]
>
> Here's my patch, condensing your commits, adding some documentation,
> and fixing some glitches.  Please check!
>
> > - The public headers should not be renamed.
>
> What do you think about introducing a bunch of header files with long
> names that do something like the following:
>
>   file `FT_Multiple_Masters.h`:
>
> #include 
> /* EOF */
>
>
>   Werner
>

Re: FT_Add_Module() and related functions

[David Turner]

Hello everyone,

Le mar. 9 juin 2020 à 14:14, Alexei Podtelezhnikov  a
écrit :

> Hi David,
>
> I actually thought about FT_Add_Module as a visionary interface for
> dynamically plugging alternative renderers:
>
> https://github.com/raphlinus/font-rs
> https://github.com/mooman219/fontdue
> https://github.com/servo/pathfinder
>
> Admittedly, none of those projects explored this possibility or there
> are more straightforward ways to achieve this.
>
>
I'm not against the idea of being able to plug external renderers to
FreeType if it makes sense. The OT-SVG case is a compelling reason to.
However, I want to deprecate the existing module API. It has grown a little
too complex for its own good, and there are opportunities to simplify the
codebase (making the code both shorter and more maintainable), by getting
rid of the ability to add/replace/remove arbitrary modules.

That would not prevent us from introducing a new way to "plug" renderers,
probably with a new interface, that would be much more specific, and would
deal better with subtle issues like deallocating bitmap buffers that were
allocated by the renderer.

In the case of OT-SVG, I haven't looked at the problem in detail, but it
looks like this would require a new glyph image type to support (doable),
and the ability to provide FreeType with an interface it could use to
render these with a third-party library.
Do you know if the format allows compositing SVG and non-SVG glyphs
together? That would be ... difficult to support though.

I don't think we want to statically link any SVG renderer to the library by
default. There are so many subtleties related to vector graphics rendering,
that there is no "good" default choice to make. In other words, any default
we select at link time would probably be inappropriate for a lot of
developers anyway.

- David

Then there is this whole discussion on how to integrate SVG, which
> again comes down to using an alternative renderer module and whether
> it is worth hooking inside a single module or Add/Remove multiple
> modules.
> https://lists.nongnu.org/archive/html/freetype-devel/2019-07/msg00058.html
>
> So I know that nobody uses FT_Add_Module but it is not a bad interface.
>
> Alexei
>

Re: intel compiler support interest?

[David Turner]

Le dim. 14 juin 2020 à 07:06, Stephen McDowell  a
écrit :

> Hi Alexei,
>
> It's only __builtin_shuffle that's a problem.  I'm a simd novice at best
> hehe.  I played around for a good long while trying to find an equivalent
> shuffle intrinsic, for now I was just working off of the GCC examples for
> __builtin_shuffle: https://godbolt.org/z/gPiZQL
>
> It's technically successful, but with a big caveat that in order for me to
> try and translate this to the freetype code I need help understanding how
> the mask={0,1,1,3} gets transformed into 212 in emitted `pshufd xmm0, xmm0,
> 212` from the gcc __builtin_shuffle call.  Look for `#define MAGIC` in the
> example, anything stick out as to how that value is created?  If we know
> how that is done, I can begin looking into shorts (v82 type used in
> freetype code) rather than int in the example code.
>
> 212 decimal is 0xD4 hex, which is binary for 11010100, or 11_01_01_00 when
separating 2-bit values, which corresponds to the {0, 1, 1, 3} mask in
little-endian order.
For more details, see
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#cats=Swizzle&text=shuffle_epi32&expand=5144
which explains how the second argument to __mm_shuffle_epi32 is interpreted
by the CPU.


> I'm game to push a little further on it, but to be honest adding in
> conditional trickery for intel will make this code more confusing.  It's
> going to have to convert between v82 and one of the _mXXXi vector types and
> shuffle splitting (can't call _mm_shuffle* with v82 type).  In other words,
> while intel users may not get the fastest possible code, previously none of
> this code was vectorized anyway so it's kind of a wash.  That said, I
> totally understand the desire to vectorize it if we can :)
>
> I think it makes sense to first disable the vectorized code path to get
the source to build properly with the Intel compiler.
A second patch could try to optimize the code using Intel intrinsics on x86
and x86_64, this would probably be portable to more compilers. Not sure
this is worth it though.

>
>
> Let me know your thoughts!
>
> -Stephen
>
>
> On Sat, Jun 13, 2020 at 2:36 PM Alexei Podtelezhnikov 
> wrote:
>
>> On Fri, Jun 12, 2020 at 8:07 AM Stephen McDowell 
>> wrote:
>> > I help maintain the spack package manager when I can, currently users
>> with intel compilers cannot build / install any version after 2.7.1 due to
>> the usage of __builtin_shuffle (for some reason Intel still doesn't support
>> this).
>>
>> Is there by any chance an equivalent intrinsic?
>>
>> https://software.intel.com/sites/landingpage/IntrinsicsGuide/#cats=Bit%20Manipulation
>> What about __builtin_clz that FreeType also uses?
>>
>

Re: Overlap oversampling

[David Turner]

Le mar. 23 juin 2020 à 05:42, Alexei Podtelezhnikov  a
écrit :

> Hi again,
>
> The oversampling is implemented though inflating the outline and then
> averaging the increased number of cells using FT_RASTER_FLAG_DIRECT
> mechanism. The first two patches set the stage by splitting the code
> paths for LCD rendering out of the way and trying
> FT_RASTER_FLAG_DIRECT for FT_RENDER_MODE_LCD. The third one implements
> oversampling by replacing the normal rendering with oversampling if
> SCALE is 2 or 4 (as opposed to 1). Again the proposal is to have it as
> FT_RENDER_MODE_SLOW eventually. The slightly complicated averaging of
> cells is due to 255/4+255/4+255/4+255/4 = 252 instead of 255, so we
> have to do rounding, yet avoid overflowing.
>
> Thanks, I'll take a look at your patches.

However, please don't call it FT_RENDER_MODE_SLOW, the fact that it is slow
is an implementation detail, and we could very well replace this with a
different algorithm in the future (maybe slow, maybe not). So something
like FT_RENDER_MODE_OVERLAPPED_OUTLINES seems more appropriate, since it
describes why you would want to use this mode, instead of what its
performance profile is :-)

Comments?
>
> Alexei
>

[patch] Simplify ftconfig.h

[David Turner]

[build] Simplify 

This patch simplifies the content of ftconfig.h by
moving things around a little, i.e.:

- Move public compiler macros needed by the FreeType
  API headers to ,
  while all other macros that are only used by the
  implementation are moved to
   instead.

- Move integer type definitions to
   while allowing
  the header's includer to define FT_SIZEOF_INT and
  FT_SIZEOF_LONG (as required on Unix).

- Move Mac support macro definitions to
  . It is unclear
  at this point if this is required by the public
  API header. Otherwise, this might be moved to
   instead.

- Rename builds/unix/ftconfig.in to
  builds/unix/ftconfig.h.in since we are no longer
  limited to 8.3 file names (yeah!). Also make
  the file's content drastically shorter since
  it can now include the other config/ headers
  listed above.

NOTE: This patch does not try to move the definitions
of HAVE_UNISTD_H and HAVE_FCNTL_H from the public
ftconfig.h header generated by `configure` on Unix.
However, these values have no place in a public
header, and should probably be moved to compiler
flags instead. Maybe in a future patch.
From ea9b5d98169bc9cc67f2ac4acad0af25f38116ab Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Tue, 23 Jun 2020 20:54:41 +0200
Subject: [build] Simplify 

This patch simplifies the content of ftconfig.h by
moving things around a little, i.e.:

- Move public compiler macros needed by the FreeType
  API headers to ,
  while all other macros that are only used by the
  implementation are moved to
   instead.

- Move integer type definitions to
   while allowing
  the header's includer to define FT_SIZEOF_INT and
  FT_SIZEOF_LONG (as required on Unix).

- Move Mac support macro definitions to
  . It is unclear
  at this point if this is required by the public
  API header. Otherwise, this might be moved to
   instead.

- Rename builds/unix/ftconfig.in to
  builds/unix/ftconfig.h.in since we are no longer
  limited to 8.3 file names (yeah!). Also make
  the file's content drastically shorter since
  it can now include the other config/ headers
  listed above.

NOTE: This patch does not try to move the definitions
of HAVE_UNISTD_H and HAVE_FCNTL_H from the public
ftconfig.h header generated by `configure` on Unix.
However, these values have no place in a public
header, and should probably be moved to compiler
flags instead. Maybe in a future patch.
---
 builds/unix/configure.raw   |  22 +-
 builds/unix/ftconfig.h.in   |  77 +++
 builds/unix/ftconfig.in | 602 
 include/freetype/config/compiler_macros.h   |  89 +++
 include/freetype/config/ftconfig.h  | 531 +
 include/freetype/config/integer_types.h | 245 
 include/freetype/config/mac_support.h   |  49 ++
 include/freetype/internal/compiler_macros.h | 271 +
 include/freetype/internal/ftcalc.h  |   1 +
 include/freetype/internal/ftdebug.h |   2 +
 include/freetype/internal/ftdrv.h   |   1 +
 include/freetype/internal/ftmemory.h|   1 +
 include/freetype/internal/ftobjs.h  |   1 +
 include/freetype/internal/ftserv.h  |   1 +
 include/freetype/internal/ftvalid.h |   3 +-
 src/raster/ftraster.h   |   1 +
 16 files changed, 751 insertions(+), 1146 deletions(-)
 create mode 100644 builds/unix/ftconfig.h.in
 delete mode 100644 builds/unix/ftconfig.in
 create mode 100644 include/freetype/config/compiler_macros.h
 create mode 100644 include/freetype/config/integer_types.h
 create mode 100644 include/freetype/config/mac_support.h
 create mode 100644 include/freetype/internal/compiler_macros.h

diff --git a/builds/unix/configure.raw b/builds/unix/configure.raw
index 50f270119..f04c4c2b3 100644
--- a/builds/unix/configure.raw
+++ b/builds/unix/configure.raw
@@ -12,7 +12,7 @@
 # fully.
 
 AC_INIT([FreeType], [@VERSION@], [freet...@nongnu.org], [freetype])
-AC_CONFIG_SRCDIR([ftconfig.in])
+AC_CONFIG_SRCDIR([ftconfig.h.in])
 
 
 # Don't forget to update `docs/VERSIONS.TXT'!
@@ -109,11 +109,11 @@ AC_CHECK_SIZEOF([long])
 AC_TYPE_LONG_LONG_INT
 
 
-# check whether cpp computation of size of int and long in ftconfig.in works
+# check whether cpp computation of size of int and long in ftconfig.h.in works
 
-AC_MSG_CHECKING([whether cpp computation of bit length in ftconfig.in works])
+AC_MSG_CHECKING([whether cpp computation of bit length in ftconfig.h.in works])
 orig_CPPFLAGS="${CPPFLAGS}"
-CPPFLAGS="-I${srcdir} -I. -I${srcdir}/../../include/freetype/config ${CPPFLAGS}"
+CPPFLAGS="-I${srcdir} -I. -I${srcdir}/../../include ${CPPFLAGS}"
 
 ac_clean_files=
 if test ! -f ft2build.h; then
@@ -124,10 +124,10 @@ fi
 cat > conftest.c <<\_ACEOF
 #include 
 #define FT_CONFIG_OPTIONS_H "ftoption.h"
-#define FT_CONFIG_STANDARD_LIBRARY_H "ftstdlib.h"
+#define FT_CONFIG_STANDARD_LIBRARY_H 
 #defin

Re: [patch] Simplify ftconfig.h

[David Turner]

Good catch, here's the updated patch that also modifies
builds/vms/ftconfig.h

We might remove support for __BORLANDC__ et al in the future, but I prefer
to do that in a separate patch (as well as all support code under builds/
for these compilers).
Just moving things around is simpler to review and implement so far :)

Thank you

Le mar. 23 juin 2020 à 22:03, Alexei Podtelezhnikov  a
écrit :

> On Tue, Jun 23, 2020 at 3:05 PM David Turner  wrote:
> >
> > [build] Simplify 
> >
> > This patch simplifies the content of ftconfig.h by
> > moving things around a little, i.e.:
>
> This greatly consolidates a lot of redundancy in multiple copies of
> ftconfig.h too. However, I think you missed the third copy for
> ftconfig.h in builds/vms/ftconfig.h. I also wonder if __BORLANDC__,
> __WATCOMC__, and __MWERKS__ are still worth mentioning.
>
From eb779dec558e0f7dc1626318911532a8a529fdb7 Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Tue, 23 Jun 2020 20:54:41 +0200
Subject: [build] Simplify 

This patch simplifies the content of ftconfig.h by
moving things around a little, i.e.:

- Move public compiler macros needed by the FreeType
  API headers to ,
  while all other macros that are only used by the
  implementation are moved to
   instead.

- Move integer type definitions to
   while allowing
  the header's includer to define FT_SIZEOF_INT and
  FT_SIZEOF_LONG (as required on Unix).

- Move Mac support macro definitions to
  . It is unclear
  at this point if this is required by the public
  API header. Otherwise, this might be moved to
   instead.

- Rename builds/unix/ftconfig.in to
  builds/unix/ftconfig.h.in since we are no longer
  limited to 8.3 file names (yeah!). Also make
  the file's content drastically shorter since
  it can now include the other config/ headers
  listed above.

- Update builds/vms/ftconfig.h as well.

NOTE: This patch does not try to move the definitions
of HAVE_UNISTD_H and HAVE_FCNTL_H from the public
ftconfig.h header generated by `configure` on Unix.
However, these values have no place in a public
header, and should probably be moved to compiler
flags instead. Maybe in a future patch.
---
 builds/unix/configure.raw   |  22 +-
 builds/unix/ftconfig.h.in   |  77 +++
 builds/unix/ftconfig.in | 602 
 builds/vms/ftconfig.h   | 491 +---
 include/freetype/config/compiler_macros.h   |  89 +++
 include/freetype/config/ftconfig.h  | 531 +
 include/freetype/config/integer_types.h | 245 
 include/freetype/config/mac_support.h   |  49 ++
 include/freetype/internal/compiler_macros.h | 271 +
 include/freetype/internal/ftcalc.h  |   1 +
 include/freetype/internal/ftdebug.h |   2 +
 include/freetype/internal/ftdrv.h   |   1 +
 include/freetype/internal/ftmemory.h|   1 +
 include/freetype/internal/ftobjs.h  |   1 +
 include/freetype/internal/ftserv.h  |   1 +
 include/freetype/internal/ftvalid.h |   3 +-
 src/raster/ftraster.h   |   1 +
 17 files changed, 754 insertions(+), 1634 deletions(-)
 create mode 100644 builds/unix/ftconfig.h.in
 delete mode 100644 builds/unix/ftconfig.in
 create mode 100644 include/freetype/config/compiler_macros.h
 create mode 100644 include/freetype/config/integer_types.h
 create mode 100644 include/freetype/config/mac_support.h
 create mode 100644 include/freetype/internal/compiler_macros.h

diff --git a/builds/unix/configure.raw b/builds/unix/configure.raw
index 50f270119..f04c4c2b3 100644
--- a/builds/unix/configure.raw
+++ b/builds/unix/configure.raw
@@ -12,7 +12,7 @@
 # fully.
 
 AC_INIT([FreeType], [@VERSION@], [freet...@nongnu.org], [freetype])
-AC_CONFIG_SRCDIR([ftconfig.in])
+AC_CONFIG_SRCDIR([ftconfig.h.in])
 
 
 # Don't forget to update `docs/VERSIONS.TXT'!
@@ -109,11 +109,11 @@ AC_CHECK_SIZEOF([long])
 AC_TYPE_LONG_LONG_INT
 
 
-# check whether cpp computation of size of int and long in ftconfig.in works
+# check whether cpp computation of size of int and long in ftconfig.h.in works
 
-AC_MSG_CHECKING([whether cpp computation of bit length in ftconfig.in works])
+AC_MSG_CHECKING([whether cpp computation of bit length in ftconfig.h.in works])
 orig_CPPFLAGS="${CPPFLAGS}"
-CPPFLAGS="-I${srcdir} -I. -I${srcdir}/../../include/freetype/config ${CPPFLAGS}"
+CPPFLAGS="-I${srcdir} -I. -I${srcdir}/../../include ${CPPFLAGS}"
 
 ac_clean_files=
 if test ! -f ft2build.h; then
@@ -124,10 +124,10 @@ fi
 cat > conftest.c <<\_ACEOF
 #include 
 #define FT_CONFIG_OPTIONS_H "ftoption.h"
-#define FT_CONFIG_STANDARD_LIBRARY_H "ftstdlib.h"
+#define FT_CONFIG_STANDARD_LIBRARY_H 
 #define FT_UINT_MAX  UINT_MAX
 #define FT_ULONG_MAX ULONG_MAX
-#include "ftconfig.in"
+#include "ftconfig.h.in"

Re: [patch] Simplify ftconfig.h

[David Turner]

And the previous patch didn't handle CMakeLists.txt properly, so here's a
third version that fixes the issue.

Le mar. 23 juin 2020 à 22:25, David Turner  a écrit :

> Good catch, here's the updated patch that also modifies
> builds/vms/ftconfig.h
>
> We might remove support for __BORLANDC__ et al in the future, but I prefer
> to do that in a separate patch (as well as all support code under builds/
> for these compilers).
> Just moving things around is simpler to review and implement so far :)
>
> Thank you
>
> Le mar. 23 juin 2020 à 22:03, Alexei Podtelezhnikov 
> a écrit :
>
>> On Tue, Jun 23, 2020 at 3:05 PM David Turner  wrote:
>> >
>> > [build] Simplify 
>> >
>> > This patch simplifies the content of ftconfig.h by
>> > moving things around a little, i.e.:
>>
>> This greatly consolidates a lot of redundancy in multiple copies of
>> ftconfig.h too. However, I think you missed the third copy for
>> ftconfig.h in builds/vms/ftconfig.h. I also wonder if __BORLANDC__,
>> __WATCOMC__, and __MWERKS__ are still worth mentioning.
>>
>
From 8f19504ac39fa66712a1a59954236c9ed161bbd4 Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Tue, 23 Jun 2020 20:54:41 +0200
Subject: [build] Simplify 

This patch simplifies the content of ftconfig.h by
moving things around a little, i.e.:

- Move public compiler macros needed by the FreeType
  API headers to ,
  while all other macros that are only used by the
  implementation are moved to
   instead.

- Move integer type definitions to
   while allowing
  the header's includer to define FT_SIZEOF_INT and
  FT_SIZEOF_LONG (as required on Unix).

- Move Mac support macro definitions to
  . It is unclear
  at this point if this is required by the public
  API header. Otherwise, this might be moved to
   instead.

- Rename builds/unix/ftconfig.in to
  builds/unix/ftconfig.h.in since we are no longer
  limited to 8.3 file names (yeah!). Also make
  the file's content drastically shorter since
  it can now include the other config/ headers
  listed above.

- Update builds/vms/ftconfig.h as well.

- Update CMakeLists.txt

NOTE: This patch does not try to move the definitions
of HAVE_UNISTD_H and HAVE_FCNTL_H from the public
ftconfig.h header generated by `configure` on Unix.
However, these values have no place in a public
header, and should probably be moved to compiler
flags instead. Maybe in a future patch.
---
 CMakeLists.txt  |   4 +-
 builds/unix/configure.raw   |  22 +-
 builds/unix/ftconfig.h.in   |  77 +++
 builds/unix/ftconfig.in | 602 
 builds/vms/ftconfig.h   | 491 +---
 include/freetype/config/compiler_macros.h   |  89 +++
 include/freetype/config/ftconfig.h  | 531 +
 include/freetype/config/integer_types.h | 245 
 include/freetype/config/mac_support.h   |  49 ++
 include/freetype/internal/compiler_macros.h | 271 +
 include/freetype/internal/ftcalc.h  |   1 +
 include/freetype/internal/ftdebug.h |   2 +
 include/freetype/internal/ftdrv.h   |   1 +
 include/freetype/internal/ftmemory.h|   1 +
 include/freetype/internal/ftobjs.h  |   1 +
 include/freetype/internal/ftserv.h  |   1 +
 include/freetype/internal/ftvalid.h |   3 +-
 src/raster/ftraster.h   |   1 +
 18 files changed, 755 insertions(+), 1637 deletions(-)
 create mode 100644 builds/unix/ftconfig.h.in
 delete mode 100644 builds/unix/ftconfig.in
 create mode 100644 include/freetype/config/compiler_macros.h
 create mode 100644 include/freetype/config/integer_types.h
 create mode 100644 include/freetype/config/mac_support.h
 create mode 100644 include/freetype/internal/compiler_macros.h

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 17787a171..c9befb421 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -241,7 +241,7 @@ if (UNIX)
   check_include_file("unistd.h" HAVE_UNISTD_H)
   check_include_file("fcntl.h" HAVE_FCNTL_H)
 
-  file(READ "${PROJECT_SOURCE_DIR}/builds/unix/ftconfig.in"
+  file(READ "${PROJECT_SOURCE_DIR}/builds/unix/ftconfig.h.in"
 FTCONFIG_H)
   if (HAVE_UNISTD_H)
 string(REGEX REPLACE
@@ -253,8 +253,6 @@ if (UNIX)
   "#undef +(HAVE_FCNTL_H)" "#define \\1 1"
   FTCONFIG_H "${FTCONFIG_H}")
   endif ()
-  string(REPLACE "/undef " "#undef "
-FTCONFIG_H "${FTCONFIG_H}")
 else ()
   file(READ "${PROJECT_SOURCE_DIR}/include/freetype/config/ftconfig.h"
 FTCONFIG_H)
diff --git a/builds/unix/configure.raw b/builds/unix/configure.raw
index 50f270119..f04c4c2b3 100644
--- a/builds/unix/configure.raw
+++ b/builds/unix/configure.raw
@@ -12,7 +12,7 @@
 # fully.
 
 AC_I

Re: Overlap oversampling

[David Turner]

So, could have a deep look at the patches here. They're pretty neat. I'll
just recommend documenting the subtle computations in
ft_smooth_slow_spans() a little better, and avoid branches altogether, by
using bit twiddling to perform saturated addition instead (removing
branches from loops is always best for performance). I.e. something like
the following:

  /* This function averages inflated spans in direct rendering mode.
   * It assumes that coverage spans are rendered in a SCALE*SCALE
   * inflated pixel space, and computes the contribution of each
   * span 'sub-pixel' to the target bitmap's pixel. I.e.:
   *
   *  If (x, y) are a pixel coordinates in inflated space, then
   *  (xt := x/SCALE, yt := y/SCALE) are the pixel coordinates in the target
   *  bitmap, where '/' denotes integer division.
   *
   *  Let's define GRIDSIZE := SCALE * SCALE, then if `c` is the 8-bit
coverage
   *  for (x, y) in inflated space, then its contribution to (xt, yt) would
be
   *  ct := c // GRIDSIZE, where '//' denotes division of real numbers (i.e.
   *  without truncation to a lower fixed or floating point precision).
   *
   *  Since these can only be stored on 8-bit target bitmap pixels, there
are
   *  at least two ways to approximate the sum:
   *
   * 1) Compute `ct := FLOOR(c // GRIDSIZE)`, which means that if all
   *pixels in inflated space have full coverage (i.e. value 255),
then
   *their contribution sums will be GRIDSIZE * FLOOR(255 /
GRIDSIZE),
   *which will be 252 (for SCALE == 2), or 240 (for SCALE == 4).
   *
   *A later passe will be needed to scale the values to the 0..255
   *range.
   *
   * 2) Compute `ct := ROUND(c // GRIDSIZE)`, in which case the total
   *contribution sum may reach 256 for both `SCALE == 2` and
   *`SCALE == 4`, which cannot be stored in an 8-bit pixel byte of
the
   *target bitmap. To deal with this, perform saturated arithmetic
to
   *ensure that the value never goes over 255. This avoids an
   *additional rescaling step, and is implemented below.
   */
  static void
  ft_smooth_slow_spans( int y,
int count,
const FT_Span*  spans,
TOrigin*target )
  {
unsigned char*  dst = target->origin - ( y / SCALE ) * target->pitch;
unsigned intx;

for ( ; count--; spans++ )
{
  unsigned coverage = (spans->coverage + GRIDSIZE / 2) / GRIDSIZE;


  for ( x = 0; x < spans->len; x++ )
  {
/* The following performs a saturated addition of d[0] + coverage */
unsigned char*  d = &dst[(spans->x + x) / SCALE];
unsigned int  sum = d[0] + coverage;


d[0] = (FT_Byte)(d | -(sum >> 8));
  }
}
  }

Here's a Compiler Explorer link <https://godbolt.org/z/TiyjEi> that
compares the two implementations.


Can you tell me how to actually test that the code works as expected though?

Thanks

- David

Le mar. 23 juin 2020 à 20:16, David Turner  a écrit :

>
>
> Le mar. 23 juin 2020 à 05:42, Alexei Podtelezhnikov 
> a écrit :
>
>> Hi again,
>>
>> The oversampling is implemented though inflating the outline and then
>> averaging the increased number of cells using FT_RASTER_FLAG_DIRECT
>> mechanism. The first two patches set the stage by splitting the code
>> paths for LCD rendering out of the way and trying
>> FT_RASTER_FLAG_DIRECT for FT_RENDER_MODE_LCD. The third one implements
>> oversampling by replacing the normal rendering with oversampling if
>> SCALE is 2 or 4 (as opposed to 1). Again the proposal is to have it as
>> FT_RENDER_MODE_SLOW eventually. The slightly complicated averaging of
>> cells is due to 255/4+255/4+255/4+255/4 = 252 instead of 255, so we
>> have to do rounding, yet avoid overflowing.
>>
>> Thanks, I'll take a look at your patches.
>
> However, please don't call it FT_RENDER_MODE_SLOW, the fact that it is
> slow is an implementation detail, and we could very well replace this with
> a different algorithm in the future (maybe slow, maybe not). So something
> like FT_RENDER_MODE_OVERLAPPED_OUTLINES seems more appropriate, since it
> describes why you would want to use this mode, instead of what its
> performance profile is :-)
>
> Comments?
>>
>> Alexei
>>
>

Re: I'm back

[David Turner]

Le dim. 28 juin 2020 à 04:19, Behdad Esfahbod  a écrit :

> Hi David,
>
> I've been meaning to reply to your request but the list of things I wanted
> to communicate kept growing exponentially and so I have not been able to
> say.
>
> But here, from a technical perspective this is my biggest issue, which you
> can also see as a roadmap:
>
>   https://gitlab.gnome.org/GNOME/pango/-/issues/404#note_851881
>
>
Thanks for the link Bhedad, this gives useful history about your woes and
considerations. I'd like to address some of these here.

First of all, the reason why FreeType has never been designed to be
"thread-safe" (in the sense where it supports multiple threads operating on
its objects concurrently [1]) is *entirely and very very intentional*.
The library was designed, first and foremost to be as efficient as possible
on embedded systems with limited memory and operating system primitives.
Any kind of thread-safety scheme, even atomic refcounts, would have been
detrimental to its portability, and most likely performance.
Reducing memory usage means using in-place modification of existing objects
and aggressive caching of state within various objects under a root
FT_Library instance.
That's why we have FT_Size and FT_GlyphSlot objects, very visible in the
API, but there are also various levels of caching internally (most of them
simple LRU lists that only change occasionally, but still a potential
source of thread races).
And as far as I know, this has always been pointed out explicitly in the
FT_Library documentation.

I understand that if you expected otherwise, you may have been disappointed
(to keep it politely). However I do not consider the API to be "broken"
regarding thread-safety, it's just not designed for this use case, at all.
It solves a very different problem.
Thus there is no way to "fix all thread-safety" issues in it, without
changing the internals and the API tremendously. You may have made some
modifications to the library to get rid of the most annoying thread-related
issues you've encountered,
but I assure you there are still by-design thread-races in many places.
Also, some of the fixes seem a little dubious, i.e. the raster pool is now
a fixed 16 kiB now, while it used to be resizable by the user.
This was useful when rendering large vector graphics (not fonts) with the
FreeType rasterizers. Now the algorithm are essentially quadratic, which
makes it painful or unusable for this use case.

The root of your problem seems to be a vast impedance mismatch between the
Cairo / Pango / Harfbuzz APIs which expect, or encourage, several threads
(probably from clients, which would be worse) to use FT_Face objects
liberally.
This simply cannot work reliably.

My only immediate recommendation would be to use a different "face"
abstraction object for these, that would either reimplement FreeType, or
parts of it (the route Pango seems to have chosen), or wrap FreeType
objects behind the right amount of
caching and thread-specific synchronization to make it work (like other
libraries like Skia do). I can't tell you which way is best. It would be
interesting to discuss which properties these "thread-safe font objects"
could have.
Maybe we can write a sane and small library on top of FreeType to provide
just that. I just don't think there is a way to do that within it.

Another alternative would be to refactor the FreeType library considerably
into a new version (with a different thread-safe API where it matters), but
that's a far harder problem, is likely to result in something that will be
larger, more complex internally, use more memory, and likely be slower.
At least we could rewrite the internals with a better language than C89 :)
But I'd rather have an extensive unit-test and regression test suite before
trying this.

- David

[1] Except if each thread has its own FT_Library instance (and
corresponding set of FT_Face/FT_Size/FT_GlyphSlot objects.

I will keep trying to comment on the two GSoC projects, and eventually get
> to write about the health of the freetype as a community project.
>
> Cheers,
> behdad
>
> On Fri, Apr 24, 2020 at 1:03 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 mo

Re: [patch] Simplify ftconfig.h

[David Turner]

Le mer. 24 juin 2020 à 13:49, Alexei Podtelezhnikov  a
écrit :

> Hello David,
>
> >  create mode 100644 include/freetype/config/compiler_macros.h
> >  create mode 100644 include/freetype/config/integer_types.h
> >  create mode 100644 include/freetype/config/mac_support.h
> >  create mode 100644 include/freetype/internal/compiler_macros.h
>
> The same filename albeit in different folders might be confusing and
> prone to errors.


Oh, very good point, I'll change this.

Also _macros.h is a bit redundant.


I don't think so, the header is really about defining macros that are
compiler-specific.


> How about
> config/ftconfig-compiler.h and internal/ftcompiler.h?


First, we should avoid our cryptic short names now, the use of prefixes
like "ft" was due to the fact that some people didn't even have proper
directories when developing for embedded systems (a long long time ago).
So any public header began with "ft", all TrueType headers, began with
"tt", etc... We really don't need this anymore. We need to keep the public
header names consistent to avoid breaking all kinds of scripts that operate
on them, but for anything new, or under internal/ or even src/, we are now
free to rename everything to something vastly more meaningful.
The good thing is we don't have to do this all at once, progressively will
be good.

Also ftconfig-compiler.h makes me think about a compiler for configuration
files, I find "compiler_macros.h" or "compiler_defines.h" more explicit.



> Personally, I
> would rather reflect custody in the names: ftconfig-types.h
> ftconfig-mac.h. It might just be me but I am not a big fan of
> verbosity in C including filenames.
>
>
We should also decide whether to chose a dash or an underscore as the word
separator for header and source file names :-)
I have no favorites here, but being consistent will be less ambiguous for
everyone.



> Alexei
>

Re: [patch] Simplify ftconfig.h

[David Turner]

Le mar. 30 juin 2020 à 07:23, Werner LEMBERG  a écrit :

>
> > We should also decide whether to chose a dash or an underscore as
> > the word separator for header and source file names :-) I have no
> > favorites here, but being consistent will be less ambiguous for
> > everyone.
>
> I definitely prefer '-' over '_'.
>
> Thanks, let's go with it. Here's the rebased and updated patch then.

>
> Werner
>
From 1d2fe6e959f4fb4a3321eab1a104298118273541 Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Tue, 23 Jun 2020 20:54:41 +0200
Subject: [build] Simplify 

This patch simplifies the content of ftconfig.h by
moving things around a little, i.e.:

- Move public compiler macros needed by the FreeType
  API headers to ,
  while all other macros that are only used by the
  implementation are moved to
   instead.

- Update the definitions of FT_BASE() and related
  macro to ensure that internal functions have hidden
  visibility by default (see FT_INTERNAL_FUNCTION_ATTRIBUTE)
  in  for details).

- Move integer type definitions to
   while allowing
  the header's includer to define FT_SIZEOF_INT and
  FT_SIZEOF_LONG (as required on Unix).

- Move Mac support macro definitions to
  . It is unclear
  at this point if this is required by the public
  API header. Otherwise, this might be moved to
   instead.

- Rename builds/unix/ftconfig.in to
  builds/unix/ftconfig.h.in since we are no longer
  limited to 8.3 file names (yeah!). Also make
  the file's content drastically shorter since
  it can now include the other config/ headers
  listed above.

- Update builds/vms/ftconfig.h as well.

- Update CMakeLists.txt

NOTE: This patch does not try to move the definitions
of HAVE_UNISTD_H and HAVE_FCNTL_H from the public
ftconfig.h header generated by `configure` on Unix.
However, these values have no place in a public
header, and should probably be moved to compiler
flags instead. Maybe in a future patch.
---
 CMakeLists.txt  |   4 +-
 builds/unix/configure.raw   |  22 +-
 builds/unix/ftconfig.h.in   |  77 +++
 builds/unix/ftconfig.in | 602 
 builds/vms/ftconfig.h   | 491 +---
 include/freetype/config/ftconfig.h  | 531 +
 include/freetype/config/integer-types.h | 245 
 include/freetype/config/mac-support.h   |  49 ++
 include/freetype/config/public-macros.h |  82 +++
 include/freetype/internal/compiler-macros.h | 278 +
 include/freetype/internal/ftcalc.h  |   1 +
 include/freetype/internal/ftdebug.h |   2 +
 include/freetype/internal/ftdrv.h   |   1 +
 include/freetype/internal/ftmemory.h|   1 +
 include/freetype/internal/ftobjs.h  |   1 +
 include/freetype/internal/ftserv.h  |   1 +
 include/freetype/internal/ftvalid.h |   3 +-
 src/raster/ftraster.h   |   1 +
 18 files changed, 755 insertions(+), 1637 deletions(-)
 create mode 100644 builds/unix/ftconfig.h.in
 delete mode 100644 builds/unix/ftconfig.in
 create mode 100644 include/freetype/config/integer-types.h
 create mode 100644 include/freetype/config/mac-support.h
 create mode 100644 include/freetype/config/public-macros.h
 create mode 100644 include/freetype/internal/compiler-macros.h

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 17787a171..c9befb421 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -241,7 +241,7 @@ if (UNIX)
   check_include_file("unistd.h" HAVE_UNISTD_H)
   check_include_file("fcntl.h" HAVE_FCNTL_H)
 
-  file(READ "${PROJECT_SOURCE_DIR}/builds/unix/ftconfig.in"
+  file(READ "${PROJECT_SOURCE_DIR}/builds/unix/ftconfig.h.in"
 FTCONFIG_H)
   if (HAVE_UNISTD_H)
 string(REGEX REPLACE
@@ -253,8 +253,6 @@ if (UNIX)
   "#undef +(HAVE_FCNTL_H)" "#define \\1 1"
   FTCONFIG_H "${FTCONFIG_H}")
   endif ()
-  string(REPLACE "/undef " "#undef "
-FTCONFIG_H "${FTCONFIG_H}")
 else ()
   file(READ "${PROJECT_SOURCE_DIR}/include/freetype/config/ftconfig.h"
 FTCONFIG_H)
diff --git a/builds/unix/configure.raw b/builds/unix/configure.raw
index 50f270119..f04c4c2b3 100644
--- a/builds/unix/configure.raw
+++ b/builds/unix/configure.raw
@@ -12,7 +12,7 @@
 # fully.
 
 AC_INIT([FreeType], [@VERSION@], [freet...@nongnu.org], [freetype])
-AC_CONFIG_SRCDIR([ftconfig.in])
+AC_CONFIG_SRCDIR([ftconfig.h.in])
 
 
 # Don't forget to update `docs/VERSIONS.TXT'!
@@ -109,11 +109,11 @@ AC_CHECK_SIZEOF([long])
 AC_TYPE_LONG_LONG_INT
 
 
-# check whether cpp computation of size of int and long in ftconfig.in works
+# check whether cpp computation of size of int and long in ftconfig.h.in works
 
-AC_MSG_CHECKING([whether cpp computation of bit length in ftconfig.in works])
+AC_MSG_CHECK

Re: [patch] Simplify ftconfig.h

[David Turner]

Le mar. 30 juin 2020 à 15:27, Werner LEMBERG  a écrit :

>
> > Here's the rebased and updated patch then.
>
> Thanks.  However, what you've sent are actually two completely
> separate things: The splitting of `ftconfig.h` into smaller files, and
> the modification of `FT_BASE' and friends.  Please change this into
> two separate commits, which makes it much easier to follow the
> changes.
>
> Yes, here's it is as a bundle of 5 intermediate commits.
As a reminder, to use it, do:

git remote add bundle /path/to/bundle
git fetch bundle

This will print the remote branch (i.e. bundle/ftconfig-cleanup in this
case)

- David

>
> Werner
>


freetype2-ftconfig-cleanup.bundle
Description: Binary data

Re: [patch] Simplify ftconfig.h

[David Turner]

*Ouch* :-)

Werner, please don't commit something if you think there are still problems
in it, that's what code reviews are, and I'm currently on vacation, so
we've been lucky I could glimpse at my email and have time to fix it.
See attached patch for a fix. Sorry about that. We need a better way to
automatically check our builds. Note that the freetype2-demos issue didn't
appear on my workstation because I was doing an incremental build, and our
dependencies are so wrong that Make didn't catch the need to recompile the
demo sources, only relink the binaries. Yet another reason to change our
build.

I'll work on a proper rebuild-check script first though...

- David

Le lun. 6 juil. 2020 à 08:31, Werner LEMBERG  a écrit :

> > [...] compilation of the the demo programs fails with
> >
> > freetype2-demos/src/ftbench.c: In function ‘face_requester’:
> >   freetype2-demos/src/ftbench.c:165:5: warning:
> > implicit declaration of function ‘FT_UNUSED’
> [-Wimplicit-function-declaration]
> >FT_UNUSED( face_id );
> >^
>
> I've fixed this meanwhile.  So only two issues for you, David :-)
>
>
>     Werner
>
From 8abef31464aea930e3d947fa611845eff97d Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Mon, 6 Jul 2020 10:56:36 +0200
Subject: [build] Fix multi and C++ builds.

The following builds were failing due to previous changes:

  make multi
  make multi CC="c++"

This patch fixes the issues, which were missing includes to
get the right macro definitions in multi-build mode.
---
 include/freetype/config/ftconfig.h |  3 ---
 include/freetype/config/ftheader.h | 20 
 src/cache/ftccache.h   |  2 +-
 src/cache/ftcmru.h |  1 +
 src/pcf/pcfutil.h  |  2 +-
 src/psaux/pserror.h|  1 +
 src/psaux/psft.h   |  2 +-
 src/psaux/psstack.h|  1 +
 src/sfnt/woff2tags.c   |  2 +-
 src/sfnt/woff2tags.h   |  1 +
 10 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/include/freetype/config/ftconfig.h b/include/freetype/config/ftconfig.h
index d59f29323..b464e0b78 100644
--- a/include/freetype/config/ftconfig.h
+++ b/include/freetype/config/ftconfig.h
@@ -45,9 +45,6 @@
 #include 
 #include 
 
-FT_END_HEADER
-
-
 #endif /* FTCONFIG_H_ */
 
 
diff --git a/include/freetype/config/ftheader.h b/include/freetype/config/ftheader.h
index b028ece9c..28b5cc60c 100644
--- a/include/freetype/config/ftheader.h
+++ b/include/freetype/config/ftheader.h
@@ -30,10 +30,12 @@
   /*encapsulated in an `extern "C" { .. }` block when included from a  */
   /*C++ compiler.  */
   /*   */
-#ifdef __cplusplus
-#define FT_BEGIN_HEADER  extern "C" {
-#else
-#define FT_BEGIN_HEADER  /* nothing */
+#ifndef FT_BEGIN_HEADER
+#  ifdef __cplusplus
+#define FT_BEGIN_HEADER  extern "C" {
+#  else
+#  define FT_BEGIN_HEADER  /* nothing */
+#  endif
 #endif
 
 
@@ -48,10 +50,12 @@
   /*encapsulated in an `extern "C" { .. }` block when included from a  */
   /*C++ compiler.  */
   /*   */
-#ifdef __cplusplus
-#define FT_END_HEADER  }
-#else
-#define FT_END_HEADER  /* nothing */
+#ifndef FT_END_HEADER
+#  ifdef __cplusplus
+#define FT_END_HEADER  }
+#  else
+#   define FT_END_HEADER  /* nothing */
+#  endif
 #endif
 
 
diff --git a/src/cache/ftccache.h b/src/cache/ftccache.h
index 2996ee808..11698bb0e 100644
--- a/src/cache/ftccache.h
+++ b/src/cache/ftccache.h
@@ -19,7 +19,7 @@
 #ifndef FTCCACHE_H_
 #define FTCCACHE_H_
 
-
+#include 
 #include "ftcmru.h"
 
 FT_BEGIN_HEADER
diff --git a/src/cache/ftcmru.h b/src/cache/ftcmru.h
index e7c2a8fad..ac4f9b126 100644
--- a/src/cache/ftcmru.h
+++ b/src/cache/ftcmru.h
@@ -45,6 +45,7 @@
 
 
 #include 
+#include 
 
 #ifdef FREETYPE_H
 #error "freetype.h of FreeType 1 has been loaded!"
diff --git a/src/pcf/pcfutil.h b/src/pcf/pcfutil.h
index be986e756..a197c1559 100644
--- a/src/pcf/pcfutil.h
+++ b/src/pcf/pcfutil.h
@@ -31,7 +31,7 @@ THE SOFTWARE.
 
 #include 
 #include FT_CONFIG_CONFIG_H
-
+#include 
 
 FT_BEGIN_HEADER
 
diff --git a/src/psaux/pserror.h b/src/psaux/pserror.h
index eb0a865e2..5738853fa 100644
--- a/src/psaux/pserror.h
+++ b/src/psaux/pserror.h
@@ -50,6 +50,7 @@
 
 
 #include 
+#include 
 #include "psft.h"
 
 
diff --git a/src/psaux/psft.h b/src/psaux/psft.h
index 902983ed7..3da454e60 100644
--- a/src/psaux/psft.h
+++ b/src/psaux/psft.h
@@ -40,9 +40,9 @@
 #define PSFT_H_
 
 
+#include 
 #include "pstypes.h"
 
-
   /* TODO: disable asserts for now */
 #define CF2_NDEBUG
 
diff 

Re: [patch] Simplify ftconfig.h

[David Turner]

Le lun. 6 juil. 2020 à 11:58, Werner LEMBERG  a écrit :

>
> > Werner, please don't commit something if you think there are still
> > problems in it, that's what code reviews are,
>
> Normally, I do that.  However, I've already invested a lot of time in
> writing ChangeLog entries...
>
> Would you consider dropping the ChangeLog entries. It is far simpler to
rely on the git history for this, and just enforcing that commiter provide
meaningful commit message should be enough?
Also, whenever you reformat some of the patches that are sent to you, the
original author has to resolve the conflicts manually, or drop its own
branch, which is not always practical (e.g. when there are other
work-in-progress commits/branches on top of the one that was originally
submitted). Would you consider using clang-format to automate the
formatting task? I think we can get pretty close to the FreeType formatting
standard with a Clang style sheet. It won't be 100% the same, but close
enough to avoid repetitive work.


> See attached patch for a fix.
>
> Applied, thanks.  Note, however, that there are still issues with
> `make multi CC=c++` (I'm using g++ 7.5.0):
>
> Yes, here's another patch that tries to fix this. Sorry about that.
Also Ben Wagner noticed me that some third-party code is using FT_UNUSED(),
so I've moved it back to public-macros.h to avoid breaking this.




>   c++ -ansi -pedantic \
>   -Ifreetype2.compiled [...] \
>   freetype2/src/base/ftsystem.c
>   In file included from freetype2/include/freetype/config/ftconfig.h:45:0,
>from freetype2/src/base/ftsystem.c:29:
>   freetype2/include/freetype/config/public-macros.h:83:61: error:
> expected unqualified-id before string constant
>#define FT_EXPORT( x )  FT_PUBLIC_FUNCTION_ATTRIBUTE extern "C" x
>^
>   freetype2/include/freetype/fterrors.h:281:3: note:
> in expansion of macro ‘FT_EXPORT’
>  FT_EXPORT( const char* )
>  ^
>
> > Sorry about that.  We need a better way to automatically check our
> > builds.  [...]  I'll work on a proper rebuild-check script first
> > though...
>
> I don't worry about that right now, and please don't invest too much
> time here.  This is something after a switch to a new build system
> IMHO.
>
>
> Werner
>
From 0cfacffe05ae6eeffe2df0d0663fa4666a8b6afc Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Mon, 6 Jul 2020 10:56:36 +0200
Subject: [build] Fix multi and C++ builds.

The following builds were failing due to previous changes:

  make multi
  make multi CC="c++"
  make CC="c++"

This patch fixes the issues, which were missing includes to
get the right macro definitions in multi-build mode.

Also, FT_UNUSED() is actually used by third-party code, so
move it back to  to avoid
breaking it.
---
 include/freetype/config/public-macros.h | 16 +---
 include/freetype/internal/compiler-macros.h | 19 ---
 src/cache/ftccback.h|  2 ++
 src/lzw/ftzopen.h   |  3 +++
 4 files changed, 22 insertions(+), 18 deletions(-)

diff --git a/include/freetype/config/public-macros.h b/include/freetype/config/public-macros.h
index b1fa0f2b3..5cc3236ed 100644
--- a/include/freetype/config/public-macros.h
+++ b/include/freetype/config/public-macros.h
@@ -78,13 +78,23 @@ FT_BEGIN_HEADER
  *
  * FT_EXPORT( FT_Bool )  FT_Object_Method( FT_Object obj, ... );
  *
+ * NOTE: This requires that all FT_EXPORT() uses are inside FT_BEGIN_HEADER ..
+ * FT_END_HEADER blocks. This guarantees that the functions are exported with
+ * C linkage, even when the header is included by a C++ source file.
  */
-#ifdef __cplusplus
-#define FT_EXPORT( x )  FT_PUBLIC_FUNCTION_ATTRIBUTE extern "C" x
-#else
 #define FT_EXPORT( x )  FT_PUBLIC_FUNCTION_ATTRIBUTE extern x
+
+  /* `FT_UNUSED` indicates that a given parameter is not used --   */
+  /* this is only used to get rid of unpleasant compiler warnings. */
+  /*   */
+  /* Technically, this was not meant to be part of the public API, */
+  /* but some third-party code depends on it.  */
+  /*   */
+#ifndef FT_UNUSED
+#define FT_UNUSED( arg )  ( (arg) = (arg) )
 #endif
 
+
 FT_END_HEADER
 
 #endif  /* FREETYPE_CONFIG_PUBLIC_MACROS_H_ */
diff --git a/include/freetype/internal/compiler-macros.h b/include/freetype/internal/compiler-macros.h
index 1f432bca5..b62c0777b 100644
--- a/include/freetype/internal/compiler-macros.h
+++ b/include/freetype/internal/compiler-macros.h
@@ -27,12 +27,6 @@ FT_BEGIN_HEADER
 #  if defined( _COMPILER_VERSION ) && ( _COMPILER_VER

Re: [patch] Simplify ftconfig.h

[David Turner]

Here's a patch to add a .clang-format style file to the directory. Note
that this doesn't reformat the sources, but see the instructions in the
commit message to do that.
I dinf the results quite close to what we have. Please take a look and let
me know your opinon on the results.

Apart from that, there are several ways to enforce rules, for example using
git hooks that will run cheks before a submit or a push.
Other options are using a code review tool so that each patch is vetted
properly before being submitted, but that's more related to the discussion
about moving to gitlab/github.

Le mar. 7 juil. 2020 à 07:09, Werner LEMBERG  a écrit :

>
> >> However, I've already invested a lot of time in writing ChangeLog
> >> entries...
> >
> > Would you consider dropping the ChangeLog entries.
>
> Basically, I don't object to that.  However, experience has shown that
> people tend to write very sloppy git commit messages in general.  The
> ChangeLog format enforces you to describe changes in a standardized
> way that I consider very helpful.
>
> > It is far simpler to rely on the git history for this, and just
> > enforcing that committer provide meaningful commit messages should
> > be enough?
>
> If we can do what Emacs does – namely git commit messages in ChangeLog
> style – I'm all for dropping direct ChangeLog entries.
>
> > Also, whenever you reformat some of the patches that are sent to
> > you, the original author has to resolve the conflicts manually, or
> > drop its own branch, which is not always practical (e.g. when there
> > are other work-in-progress commits/branches on top of the one that
> > was originally submitted).
>
> This is admittedly a problem.
>
> > Would you consider using clang-format to automate the formatting
> > task? I think we can get pretty close to the FreeType formatting
> > standard with a Clang style sheet.  It won't be 100% the same, but
> > close enough to avoid repetitive work.
>
> If you can manage to write that, please do!  Automatic formatting has
> definitely benefits.  Honestly, I suggest that we get completely rid
> of the special FreeType formatting.  For consistency I'm enforcing it
> on all pieces of code, but virtually all contributors have
> difficulties to follow the (unwritten) rules.  Something like
>
>   int main(int argc,
>char **argv)
>   {
> FT_Error error;
> FT_Library library;
> FT_Face face;
> int i;
>
>
> error = FT_Init_FreeType(&library);
> if (error)
> {
>   foobar();
>   die("FT_Init_FreeType failed");
> }
>
> if (argc != 2)
>   die("no font file argument given");
>
> ...
>
> looks nice IMHO – and is quite standard, AFAICS.  Of course,
> vertical alignment like
>
> FT_Error   error;
> FT_Library library;
> FT_Faceface;
> inti;
>
> is quite nice, too, but I doubt that it can be really handled
> automatically.
>
> Whatever you come up with, please check whether our API documentation
> can be built correctly.  Additionally, such a change should be
> introduced right after a release.
>
> > here's another patch that tries to fix this.  Sorry about that.
> > Also Ben Wagner noticed me that some third-party code is using
> > FT_UNUSED(), so I've moved it back to public-macros.h to avoid
> > breaking this.
>
> Thanks, applied (with minor additions).
>
>
> Werner
>
From efa7fc4dcc0fe2b4a15cec1b04f45a71b99435cd Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Fri, 1 May 2020 15:37:56 +0200
Subject: [build] Add .clang-format file

This file can be used to reformat FreeType sources and commits
using one of these methods:

- Direct formatting of a whole file:

clang-format -i path/to/file

  For example, to reformat all sources at once:

echo builds/unix/ftconfig.h.in $(git ls-files *.[hc]) | xargs clang-format -i

- Only reformat the changed lines in the current work directoy:

git clang-format

The style settings in this file are very close to the FreeType
formatting style, with the following exceptions which are not supported
here:

- Mminimal 2-space margin on each non-empty line.
  (no left margin instead).

- 2 empty lines between variable declarations and statements in C blocks.
  (only 1 is kept).

{
  int  x = ...;

  foo(x);
}

  becomes

{
  int x = ...;

  foo(x);
}

- Aignment of declarations uses 2 spaces to separate types and variable
  names (only 1 space is kept).

 int  x;=>   int x;
 int  y; int y;

- The start used for output parameters in function signature should be
  near the variable name (

Re: new compiler warnings in freetype 2.10.2 32-bit

[David Turner]

A better answer is to actually get rid of strcpy() / strcat() / sprintf()
because there will always be compilers complaining about them.

Here's a patch that does that for freetype2-demos, please take a look.

Le jeu. 23 juil. 2020 à 13:16, Werner LEMBERG  a écrit :

> > There seems to be a new warning in 2.10.2 (compared to 2.10.1) when
> > compiling for 32-bit: [...]
>
> Fixed in git, thanks.
>
> > Also have had a bunch of strncat related warning (probably gcc 1
> specific, or some compiler switch specific) in ft2-demos, for a while:
> >
> > ===
> > inlined from 'RunIns' at src/ttdebug.c:2105:11:
> > /usr/include/bits/string_fortified.h:136:10: warning:
> > '__builtin___strncat_chk' output may be truncated copying 31 bytes
> > from a string of length 31 [-Wstringop-truncation]
>
> (The problematic calls of strncat are in function `Cur_U_Line'.)
>
> Hmm.  The answer to
>
>
> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice
>
> recommends to switch off the warning if the code does exactly ...
>
>
> Werner
>
>
From dc5dae42212453f9a7850f201ad82c39e041e698 Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Sun, 17 May 2020 21:37:09 +0200
Subject: [build] Remove strncat / strcpy() / sprintf() from sources.

This removes all uses of these potentially unsafe functions from
the sources, mostly to avoid dealing with overzealous
compiler warnings, and preventing buffer overflow issues.

This is done through several steps:

+ common.h: Add ft_strdup() to implement a proper strdup()
  function that also works on Windows.

+ strbuf.h: New header and associated source file, providing
  a trivial data type and functions to safely perform formatted
  string concatenation on a fixed-size buffer, while ensuring
  the result is always properly zero-terminated.

  Usage is pretty simple, and documented in the header.

+ Update the other sources to use ft_debug(), stdbuf_xxx()
  and snprintf() instead of sprintf() in order to get rid of
  any potential for buffer overflow / unterminated strings.
---
 Makefile   |   2 +
 src/common.c   |  22 +++-
 src/common.h   |   9 +++-
 src/ftbench.c  |  32 ++--
 src/ftcommon.c | 133 +++---
 src/ftcommon.h |  34 
 src/ftdiff.c   |  22 
 src/ftdump.c   |   4 +-
 src/ftgamma.c  |   4 +-
 src/ftgrid.c   |  39 --
 src/ftmulti.c  |  68 
 src/ftsbit.c   |   2 +-
 src/ftstring.c |   9 ++--
 src/ftview.c   |  88 +++
 src/strbuf.c   | 139 +
 src/strbuf.h   | 117 +
 src/ttdebug.c  | 131 ++
 17 files changed, 600 insertions(+), 255 deletions(-)
 create mode 100644 src/strbuf.c
 create mode 100644 src/strbuf.h

diff --git a/Makefile b/Makefile
index e6ad0af..851c4f7 100644
--- a/Makefile
+++ b/Makefile
@@ -333,9 +333,11 @@ else
   # Rules for compiling object files for text-only demos.
   #
   $(OBJ_DIR_2)/common.$(SO): $(SRC_DIR)/common.c
+  $(OBJ_DIR_2)/strbuf.$(SO): $(SRC_DIR)/strbuf.c
   $(OBJ_DIR_2)/output.$(SO): $(SRC_DIR)/output.c
   $(OBJ_DIR_2)/mlgetopt.$(SO): $(SRC_DIR)/mlgetopt.c
   COMMON_OBJ := $(OBJ_DIR_2)/common.$(SO) \
+$(OBJ_DIR_2)/strbuf.$(SO) \
 $(OBJ_DIR_2)/output.$(SO) \
 $(OBJ_DIR_2)/mlgetopt.$(SO)
 
diff --git a/src/common.c b/src/common.c
index 1960165..3eed8ef 100644
--- a/src/common.c
+++ b/src/common.c
@@ -5,7 +5,7 @@
 #include 
 #include 
 #include 
-
+#include 
 
   char*
   ft_basename( const char*  name )
@@ -36,6 +36,25 @@
   }
 
 
+  char*
+  ft_strdup( const char* str )
+  {
+char*   result;
+size_t  len;
+
+
+if ( !str )
+  return NULL;
+
+len= strlen( str );
+result = (char*)malloc( len + 1 );
+if (result)
+  memcpy( result, str, len + 1);
+
+return result;
+  }
+
+
   void
   Panic( const char*  fmt,
  ... )
@@ -105,5 +124,4 @@
 return -1;
   }
 
-
 /* End */
diff --git a/src/common.h b/src/common.h
index afa5f70..0cf4fea 100644
--- a/src/common.h
+++ b/src/common.h
@@ -1,7 +1,6 @@
 #ifndef COMMON_H_
 #define COMMON_H_
 
-
 #ifdef __cplusplus
   extern "C" {
 #endif
@@ -26,6 +25,14 @@
   utf8_next( const char**  pcursor,
  const char*   end );
 
+  /*
+   * Implement strdup() which is POSIX, but not C89 or even C11, and
+   * Microsoft insists on renaming it _strdup() instead. Platform
+   * auto-detection is complicated, so just provide a re-implementation.
+   */
+  extern char*
+  ft_strdup( const char* name );
+
 #ifdef __cplusplus
   }
 #endif
diff --git a/src/ftbench.c b/src/ftbench.c
index 58a7741..28b3d70 100644
--- a/src/ftbench.c
+++ b/src/ftbench.c
@@ -835

Re: [patch] Simplify ftconfig.h

[David Turner]

Le jeu. 23 juil. 2020 à 13:19, Werner LEMBERG  a écrit :

>
> Hello David,
>
>
> > Here's a patch to add a .clang-format style file to the directory.
>
> Thanks.  I've slightly improved it, but I think there is still room
> for more fixes.


Good, can you share your updated version? We may not get 100% of what we
want, but the benefits of everyone using the same formatting style are far
greater imho.


> Note that newer `clang-format` binaries have
> additional options; we thus have to specify which version has to be
>
used.
>

Yes, very true. I'm currently using clang-format version 9

>
> Werner
>

Re: new compiler warnings in freetype 2.10.2 32-bit

[David Turner]

Le ven. 24 juil. 2020 à 05:58, Vincent Torri  a
écrit :

> hello
>
> some comments:
>
> strcasecmp does not exist when compiling with Visual Studio (_stricmp
> does though and is doing the same job). mingw-w64 use a #define for
> that.Why not adding ft_strcasecmp like ft_strdup ?
>
> note that using strdup with Visual Studio and passing
> _CRT_NONSTDC_NO_DEPRECATE removes the warning.
>
> I think that in this case, it is actually simpler to re-implement the
function rather than trying to fight the compiler and build system with the
right set options :-)
Very fortunately, this is not part of a critical performance loop,
otherwise, we would do things differently.


> Vincent Torri
>
> On Fri, Jul 24, 2020 at 5:02 AM David Turner  wrote:
> >
> > A better answer is to actually get rid of strcpy() / strcat() /
> sprintf() because there will always be compilers complaining about them.
> >
> > Here's a patch that does that for freetype2-demos, please take a look.
> >
> > Le jeu. 23 juil. 2020 à 13:16, Werner LEMBERG  a écrit :
> >>
> >> > There seems to be a new warning in 2.10.2 (compared to 2.10.1) when
> >> > compiling for 32-bit: [...]
> >>
> >> Fixed in git, thanks.
> >>
> >> > Also have had a bunch of strncat related warning (probably gcc 1
> specific, or some compiler switch specific) in ft2-demos, for a while:
> >> >
> >> > ===
> >> > inlined from 'RunIns' at src/ttdebug.c:2105:11:
> >> > /usr/include/bits/string_fortified.h:136:10: warning:
> >> > '__builtin___strncat_chk' output may be truncated copying 31 bytes
> >> > from a string of length 31 [-Wstringop-truncation]
> >>
> >> (The problematic calls of strncat are in function `Cur_U_Line'.)
> >>
> >> Hmm.  The answer to
> >>
> >>
> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice
> >>
> >> recommends to switch off the warning if the code does exactly ...
> >>
> >>
> >> Werner
> >>
>

Re: about the meson build systel

[David Turner]

Hello Vincent,

+cc freetype-devel

Yes, I'm working on a local branch and I've sent an experimental patch to
the mailing list some weeks ago. Here's a more recent version rebased on
top of latest changes.

There is a list of TODO() at the end of the meson.build file if you're
curious. Next step will be a proper "meson dist" that does the right thing.
Then introduce regression/unit-testing.

Hope this helps,

- David


Le ven. 24 juil. 2020 à 06:26, Vincent Torri  a
écrit :

> hello
>
> if i'm not mistaken, you said that you would add meson as build
> system. Have you begun this work ? If yes, is it available so i can
> try it ?
>
> thank you
>
> Vincent Torri
>
From 63b49d6dd47df4f90cd08bc41e7ce9524dfe926d Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Sun, 17 May 2020 18:45:41 +0200
Subject: [build] Add Meson build project files.

This adds a few files to build the FreeType 2 library
with the Meson build system:

- meson.build: top-level Meson build file for the library.

- meson_options.txt: user-selectable options for the build.
  These can be printed with 'meson configure', and selected
  as 'meson setup' or 'meson --reconfigure' time with
  -D=.

- builds/meson/ft{config,option}.h.in: template versions
  of ftconfig.h and ftoption.h to be used by the Meson build.
  These are processed by Meson, which will turn #mesondefine
  statements into #define / #undef depending on build
  configuration.

Library size comparison for stripped libfreetype.so generated
by all three build systems:

  - Default build (autotools + libtool): 712 KiB
  - CMake build: 812 KiB
  - Meson build: 896 KiB
---
 builds/meson/ftconfig.h.in |   52 ++
 builds/meson/ftoption.h.in | 1000 
 meson.build|  228 
 meson_options.txt  |6 +
 4 files changed, 1286 insertions(+)
 create mode 100644 builds/meson/ftconfig.h.in
 create mode 100644 builds/meson/ftoption.h.in
 create mode 100644 meson.build
 create mode 100644 meson_options.txt

diff --git a/builds/meson/ftconfig.h.in b/builds/meson/ftconfig.h.in
new file mode 100644
index 0..1b9026070
--- /dev/null
+++ b/builds/meson/ftconfig.h.in
@@ -0,0 +1,52 @@
+/
+ *
+ * ftconfig.h.in
+ *
+ *   UNIX-specific configuration file (specification only).
+ *
+ * Copyright (C) 1996-2020 by
+ * David Turner, Robert Wilhelm, and Werner Lemberg.
+ *
+ * This file is part of the FreeType project, and may only be used,
+ * modified, and distributed under the terms of the FreeType project
+ * license, LICENSE.TXT.  By continuing to use, modify, or distribute
+ * this file you indicate that you have read the license and
+ * understand and accept it fully.
+ *
+ */
+
+
+  /**
+   *
+   * This header file contains a number of macro definitions that are used by
+   * the rest of the engine.  Most of the macros here are automatically
+   * determined at compile time, and you should not need to change it to port
+   * FreeType, except to compile the library with a non-ANSI compiler.
+   *
+   * Note however that if some specific modifications are needed, we advise
+   * you to place a modified copy in your build directory.
+   *
+   * The build directory is usually `builds/`, and contains
+   * system-specific files that are always included first when building the
+   * library.
+   *
+   */
+
+#ifndef FTCONFIG_H_
+#define FTCONFIG_H_
+
+#include 
+#include FT_CONFIG_OPTIONS_H
+#include FT_CONFIG_STANDARD_LIBRARY_H
+
+#mesondefine HAVE_UNISTD_H
+#mesondefine HAVE_FCNTL_H
+
+#include 
+#include 
+#include 
+
+#endif /* FTCONFIG_H_ */
+
+
+/* END */
diff --git a/builds/meson/ftoption.h.in b/builds/meson/ftoption.h.in
new file mode 100644
index 0..913a6a6d1
--- /dev/null
+++ b/builds/meson/ftoption.h.in
@@ -0,0 +1,1000 @@
+/
+ *
+ * ftoption.h
+ *
+ *   User-selectable configuration macros (specification only).
+ *
+ * Copyright (C) 1996-2020 by
+ * David Turner, Robert Wilhelm, and Werner Lemberg.
+ *
+ * This file is part of the FreeType project, and may only be used,
+ * modified, and distributed under the terms of the FreeType project
+ * license, LICENSE.TXT.  By continuing to use, modify, or distribute
+ * this file you indicate that you have read the license and
+ * understand and accept it fully.
+ *
+ */
+
+
+#ifndef FTOPTION_H_
+#define FTOPTION_H_
+
+
+#include 
+
+
+FT_BEGIN_HEADER
+
+  /**
+   *
+   *USER-SELECTABLE CONFIGURATION MACROS
+   *
+   * This file contains the default configuration macro definitions for a
+   * standard build of the FreeType library.

Re: about the meson build systel

[David Turner]

Hello Vincent,

Sorry, was on vacation and pretty busy, but back now. On the topic of the
Meson build, here's my latest update. This version has many improvements:

- Proper pkg-config freetype2.pc generation and installation.
- Fixed shared library install suffix to match libtool-generated one
(number computed from the version_info in build/unix/configure.raw).
- Auto-generation of ftmodule.h and list of base extensions, based on
modules.cfg
- Generation of reference documentation (with "docs" target, but only
inside the build directory).

The last remaining todo is the ability to create a distribution package,
though that might be handled by an independent script as well, since it
needs to run "autogen.sh" in a temporary directory.

Can you tell me about the Windows compilation failure? mmap() should not be
an issue due to the checks in the build.meson file which should use
src/base/ftsystem.c for Windows.
I've setup a Window virtual machine and will start testing with it soon.

Regards

- David


Le mar. 18 août 2020 à 21:11, Vincent Torri  a
écrit :

> Hello David
>
> any news on the meson build system ?
>
> regards
>
> Vincent Torri
>
From 0035aef6df4d09924f987033228e56f32bd30166 Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Sun, 17 May 2020 18:45:41 +0200
Subject: [build] Add Meson build project files.

This adds a few files to build the FreeType 2 library
with the Meson build system:

- meson.build: top-level Meson build file for the library.

- meson_options.txt: user-selectable options for the build.
  These can be printed with 'meson configure', and selected
  as 'meson setup' or 'meson --reconfigure' time with
  -D=.

- builds/meson/ft{config,option}.h.in: template versions
  of ftconfig.h and ftoption.h to be used by the Meson build.
  These are processed by Meson, which will turn #mesondefine
  statements into #define / #undef depending on build
  configuration.

- scripts/extract_freetype_version.py: A script invoked by
  meson.build to extract the FreeType version number from
  

- scripts/extract_libtool_version.py: A script invoked by
  meson.build to extract the libtool revision_info from
  builds/unix/configure.raw and generate the corresponding
  shared library suffix.

- scripts/generate_reference_docs.py: A script invoked
  by meson.build to generate the FreeType 2 reference
  documentation (using the docwriter / mkdocs packages
  which must be installed previously).

Example usage:

  # Configure Meson build to generate release binaries comparable to
  # to the ones from the autotools/make build system.
  meson setup build-meson --prefix=/ --buildtype=release --optimization=2 --strip

  # Build and install to /tmp/aa/, this includes a pkg-config file.
  DESTDIR=/tmp/aa ninja -C build-meson install

  # Generate documentation under build-meson/docs
  ninja -C build-meson docs

Library size comparison for stripped libfreetype.so generated
by all three build systems:

  - Default build (autotools + libtool): 712 KiB
  - CMake build (RelWithDebInfo):712 KiB
  - Meson build: 784 KiB
---
 builds/meson/ftconfig.h.in  |   52 ++
 builds/meson/ftoption.h.in  | 1000 +++
 meson.build |  334 +
 meson_options.txt   |6 +
 scripts/extract_freetype_version.py |   94 +++
 scripts/extract_libtool_version.py  |   87 +++
 scripts/generate_reference_docs.py  |   58 ++
 scripts/parse_modules_cfg.py|  127 
 8 files changed, 1758 insertions(+)
 create mode 100644 builds/meson/ftconfig.h.in
 create mode 100644 builds/meson/ftoption.h.in
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 scripts/extract_freetype_version.py
 create mode 100644 scripts/extract_libtool_version.py
 create mode 100644 scripts/generate_reference_docs.py
 create mode 100644 scripts/parse_modules_cfg.py

diff --git a/builds/meson/ftconfig.h.in b/builds/meson/ftconfig.h.in
new file mode 100644
index 0..1b9026070
--- /dev/null
+++ b/builds/meson/ftconfig.h.in
@@ -0,0 +1,52 @@
+/
+ *
+ * ftconfig.h.in
+ *
+ *   UNIX-specific configuration file (specification only).
+ *
+ * Copyright (C) 1996-2020 by
+ * David Turner, Robert Wilhelm, and Werner Lemberg.
+ *
+ * This file is part of the FreeType project, and may only be used,
+ * modified, and distributed under the terms of the FreeType project
+ * license, LICENSE.TXT.  By continuing to use, modify, or distribute
+ * this file you indicate that you have read the license and
+ * understand and accept it fully.
+ *
+ */
+
+
+  /**
+   *
+   * This header file contains a number of macro definitions that are used by
+   * the rest of the engine.  Most of the macros here are aut

Re: about the meson build systel

[David Turner]

Hi Alexei,

Le lun. 24 août 2020 à 17:27, Alexei Podtelezhnikov  a
écrit :

> Hi David,
>
> Other build systems 'sed' to the main copy of ftoption.h, which is
> then installed and provides a record of compiled features. Werner
> convinced me that it is a good thing to have. It will be a nightmare
> to maintain them if each build system has its own version while lose
> track of compiled features. It has a lot of important documentation to
> keep in sync too. Would you please use 'sed' directly?
>
> An excellent point, thanks for pointing this out. Here's a new version of
the patch that does just that with a helper script.
I'd like to extend this scheme to more configuration variables in the
future, but after we complete this build transition.

- David

Thank you,
> Alexei
>
>
>
> On Mon, Aug 24, 2020 at 10:55 AM David Turner  wrote:
> >
> > Hello Vincent,
> >
> > Sorry, was on vacation and pretty busy, but back now. On the topic of
> the Meson build, here's my latest update. This version has many
> improvements:
> >
> > - Proper pkg-config freetype2.pc generation and installation.
> > - Fixed shared library install suffix to match libtool-generated one
> (number computed from the version_info in build/unix/configure.raw).
> > - Auto-generation of ftmodule.h and list of base extensions, based on
> modules.cfg
> > - Generation of reference documentation (with "docs" target, but only
> inside the build directory).
> >
> > The last remaining todo is the ability to create a distribution package,
> though that might be handled by an independent script as well, since it
> needs to run "autogen.sh" in a temporary directory.
> >
> > Can you tell me about the Windows compilation failure? mmap() should not
> be an issue due to the checks in the build.meson file which should use
> src/base/ftsystem.c for Windows.
> > I've setup a Window virtual machine and will start testing with it soon.
> >
> > Regards
> >
> > - David
> >
> >
> > Le mar. 18 août 2020 à 21:11, Vincent Torri  a
> écrit :
> >>
> >> Hello David
> >>
> >> any news on the meson build system ?
> >>
> >> regards
> >>
> >> Vincent Torri
>
>
>
> --
> Alexei A. Podtelezhnikov, PhD
>
From 047bb6fe02e82cfac3ae53db8137cadc2ca8a3eb Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Sun, 17 May 2020 18:45:41 +0200
Subject: [build] Add Meson build project files.

This adds a few files to build the FreeType 2 library
with the Meson build system:

- meson.build: top-level Meson build file for the library.

- meson_options.txt: user-selectable options for the build.
  These can be printed with 'meson configure', and selected
  as 'meson setup' or 'meson --reconfigure' time with
  -D=.

- builds/meson/ftconfig.h.in: template versions of
  ftconfig.h to be used by the Meson build. It is processed
  by Meson, which will turn #mesondefine statements into
  #define / #undef depending on build configuration.

- scripts/process_ftoption_h.py: A script invoked by
  meson.build to process the original ftoption.h and
  enable or disabled configuration macro variables based
  on the available dependencies. This is similar to what
  other build systems are using (i.e. Meson configure_file()
  is not used here).

- scripts/extract_freetype_version.py: A script invoked by
  meson.build to extract the FreeType version number from
  

- scripts/extract_libtool_version.py: A script invoked by
  meson.build to extract the libtool revision_info from
  builds/unix/configure.raw and generate the corresponding
  shared library suffix.

- scripts/generate_reference_docs.py: A script invoked
  by meson.build to generate the FreeType 2 reference
  documentation (using the docwriter / mkdocs packages
  which must be installed previously).

Example usage:

  # Configure Meson build to generate release binaries comparable to
  # to the ones from the autotools/make build system.
  meson setup build-meson --prefix=/ --buildtype=release --optimization=2 --strip

  # Build and install to /tmp/aa/, this includes a pkg-config file.
  DESTDIR=/tmp/aa ninja -C build-meson install

  # Generate documentation under build-meson/docs
  ninja -C build-meson docs

Library size comparison for stripped libfreetype.so generated
by all three build systems:

  - Default build (autotools + libtool): 712 KiB
  - CMake build (RelWithDebInfo):712 KiB
  - Meson build: 784 KiB
---
 builds/meson/ftconfig.h.in  |  52 +
 meson.build | 325 
 meson_options.txt   |   6 +
 scripts/extract_freetype_version.py |  94 
 script

Re: about the meson build systel

[David Turner]

Le lun. 24 août 2020 à 22:34, Werner LEMBERG  a écrit :

>
> Hello David,
>
>
> > - builds/meson/ftconfig.h.in: template versions of
> >   ftconfig.h to be used by the Meson build. It is processed
> >   by Meson, which will turn #mesondefine statements into
> >   #define / #undef depending on build configuration.
>
> having a meson-specific `ftconfig.h.in` file is not ideal.  I think we
> should avoid that.
>
>
Please change that.  A simple solution could be to always create
> `ftconfig.h` from a template even for a `make devel` or an autoconf
> build.
>
> I was just trying to reproduce what we're currently doing with builds/unix/
ftconfig.h.in. I agree this is far from ideal though.

I propose to get rid of this template entirely for Meson, by defining
HAVE_UNISTD_H and HAVE_FCNTL_H
as simple compiler arguments when building the library. There is really
little reason for these to appear in ftconfig.h anyway.

For the builds/unix/ftconfig.h.in case, there is also
FT_USE_AUTOCONF_SIZEOF_TYPES, whose utility currently escapes me
(i.e. FreeType's auto-detection of SIZEOF_INT and SIZEOF_LONG should be
largely sufficient, at least for any C89 compiler).
I didn't want to touch that, but we should consider removing these
entirely, unless there is a practical benefit to it
(since I suspect it is here for historical reasons). Any opinion on this?
I'd be nice to get rid of this template as well.


> Will check the rest of your code soon.
>
> > Library size comparison for stripped libfreetype.so generated
> > by all three build systems:
> >
> >   - Default build (autotools + libtool): 712 KiB
> >   - CMake build (RelWithDebInfo):712 KiB
> >   - Meson build: 784 KiB
>
> Can this be improved for meson?
>
> I think it's possible. I've been looking at it. The compiled objects are
exactly the same, but the Meson build will link
/usr/lib/x86_64-linux-gnu/libbz2.a
/usr/lib/x86_64-linux-gnu/libbz2.so.1.0.4 (both of them), while the CMake
build will only use the shared library version!
And my libbz2.a is about 80 KiB which fits the difference. Looks like we're
statically linked libz2.a by mistake here. Let me try to fix it.


> Werner
>

Re: about the meson build systel

[David Turner]

Actually, the size problem was that otvalid/gxvalid were always compiled
into the library.
I've improved meson.build to parse modules.cfg to get the list of all main
and auxiliary modules, to replicate what the Make-based build does.

Now the default build is 712 KiB for all build systems on my machine (Linux
x64 Kubuntu 19.10)

(NOTE: I'm really not a fan of modules.cfg and hope to get rid of it in the
future, but for now, it's better to keep things this way for consistency).

I also got rid of the builds/meson/ directory entirely. The unmodified
ftconfig.h is now used, with HAVE_UNISTD_H and HAVE_FCNTL_H added as
compile-time macros instead.


Le lun. 24 août 2020 à 23:27, David Turner  a écrit :

>
>
> Le lun. 24 août 2020 à 22:34, Werner LEMBERG  a écrit :
>
>>
>> Hello David,
>>
>>
>> > - builds/meson/ftconfig.h.in: template versions of
>> >   ftconfig.h to be used by the Meson build. It is processed
>> >   by Meson, which will turn #mesondefine statements into
>> >   #define / #undef depending on build configuration.
>>
>> having a meson-specific `ftconfig.h.in` file is not ideal.  I think we
>> should avoid that.
>>
>>
> Please change that.  A simple solution could be to always create
>> `ftconfig.h` from a template even for a `make devel` or an autoconf
>> build.
>>
>> I was just trying to reproduce what we're currently doing with
> builds/unix/ftconfig.h.in. I agree this is far from ideal though.
>
> I propose to get rid of this template entirely for Meson, by defining
> HAVE_UNISTD_H and HAVE_FCNTL_H
> as simple compiler arguments when building the library. There is really
> little reason for these to appear in ftconfig.h anyway.
>
> For the builds/unix/ftconfig.h.in case, there is also
> FT_USE_AUTOCONF_SIZEOF_TYPES, whose utility currently escapes me
> (i.e. FreeType's auto-detection of SIZEOF_INT and SIZEOF_LONG should be
> largely sufficient, at least for any C89 compiler).
> I didn't want to touch that, but we should consider removing these
> entirely, unless there is a practical benefit to it
> (since I suspect it is here for historical reasons). Any opinion on this?
> I'd be nice to get rid of this template as well.
>
>
>> Will check the rest of your code soon.
>>
>> > Library size comparison for stripped libfreetype.so generated
>> > by all three build systems:
>> >
>> >   - Default build (autotools + libtool): 712 KiB
>> >   - CMake build (RelWithDebInfo):712 KiB
>> >   - Meson build: 784 KiB
>>
>> Can this be improved for meson?
>>
>> I think it's possible. I've been looking at it. The compiled objects are
> exactly the same, but the Meson build will link
> /usr/lib/x86_64-linux-gnu/libbz2.a
> /usr/lib/x86_64-linux-gnu/libbz2.so.1.0.4 (both of them), while the CMake
> build will only use the shared library version!
> And my libbz2.a is about 80 KiB which fits the difference. Looks like
> we're statically linked libz2.a by mistake here. Let me try to fix it.
>
>
>> Werner
>>
>
From fa873def5c2162d5c5209ffaf0676fea5467288b Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Sun, 17 May 2020 18:45:41 +0200
Subject: [build] Add Meson build project files.

This adds a few files to build the FreeType 2 library
with the Meson build system:

- meson.build: top-level Meson build file for the library.

- meson_options.txt: user-selectable options for the build.
  These can be printed with 'meson configure', and selected
  as 'meson setup' or 'meson --reconfigure' time with
  -D=.

- scripts/parse_modules_cfg.py: A script invoked by
  meson.build to parse modules.cfg and extract important
  information out of it (i.e. the list of modules).

- scripts/process_ftoption_h.py: A script invoked by
  meson.build to process the original ftoption.h and
  enable or disabled configuration macro variables based
  on the available dependencies. This is similar to what
  other build systems are using (i.e. Meson configure_file()
  is not used here).

- scripts/extract_freetype_version.py: A script invoked by
  meson.build to extract the FreeType version number from
  

- scripts/extract_libtool_version.py: A script invoked by
  meson.build to extract the libtool revision_info from
  builds/unix/configure.raw and generate the corresponding
  shared library suffix.

- scripts/generate_reference_docs.py: A script invoked
  by meson.build to generate the FreeType 2 reference
  documentation (using the docwriter / mkdocs packages
  which must be installed previously).

Example usage:

  # Configure Meson build to generate release binaries comparable to
  # to the ones from the autotools/ma

Re: compressed streams

[David Turner]

Le jeu. 17 sept. 2020 à 14:01, Werner LEMBERG  a écrit :

>
> > These are some horrible numbers that essentially test FT_Load_Glyph
> > from compressed unifont.pcf.gz in reverse order: [...]
> >
> > real0m6.062s
> >
> > The same string forward is much faster: [...]
> >
> > real0m0.486s
>
> Ouch.
>
> > Is it well known that rewinding the compressed stream is so
> > prohibitively expensive?  Or, is this a bug?
>
> I don't know, sorry.  The basic question is, I guess, whether we are
> correctly using the gzip interface ...
>
> We do, there is no "rewinding the compressed stream", we have to restart
from the first byte of the file everytime we need to go back in the file.
We just didn't implement some sort of caching or state checkpointing in the
gzip decoder because this kind of font is legacy and has better
alternatives now (see https://packages.debian.org/fr/sid/xfonts-unifont vs
https://packages.debian.org/fr/sid/fonts-unifont for Debian)..

But in case one would really want to support this, it is possible to
improve random access in gzip stream by essentially storing the state of
the deflate decoder at various points of the input file. For a practical
example, see:
https://github.com/madler/zlib/blob/2fa463bacfff79181df1a5270fb67cc679a53e71/examples/zran.c

So in theory, something like that could be added. It's just seems a lot of
complexity for little practical benefits imho.

- David


>
> Werner
>
>

Re: cmake patch

[David Turner]

Le jeu. 17 sept. 2020 à 15:42, Alexei Podtelezhnikov  a
écrit :

> > Patch attached for avoid adding lib prefix when compiling with mingw and
> also letting to use FT_CONFIG_OPTION_ERROR_STRINGS from cmake command line.
>
> The lib prefix is your personal aversion.


It depends. There is value for the CMake build to generate the same-named
library as the regular GNU Make-based one for example. And the former does
generate something called "freetype.dll" or "freetype.lib"
This is not limited to Mingw but to all Win32 builds, so I would be in
favor to change the default for this platform. However, I don't know if
this is going to disrupt developers (we never officially supported the
CMake build as far as I know, so it may not matter though).
Thoughts?


> Would this work for the second wish?
> cmake -D PUBLIC=FT_CONFIG_OPTION_ERROR_STRINGS or something
>
> I'd rather see this feature added as an option than a special case in the
CMakeLists.txt file. E.g. FT_WITH_ERROR_STRINGS for example (similar to
FT_WITH_XXX options currently supported).
After all, there is nothing specific to Mingw here.

- David

Meson build, continued

[David Turner]

Hello

Here's my latest version of the Meson build support files for FreeType 2.
It works!
Compared to the previous versions, there are several improvements:

- The generated binaries are now the same size as the ones from the GNU
Make and CMake builds.

- The installed shared libraries have the proper libtool-compatible suffix,
and the generated pkg-config file is now using the correct FreeType
version, paths and other settings.

- The "docs" target will generate the documentation properly, except that
this will go into $BUILD_DIR/docs/ instead of $SRC_DIR/docs/, since Meson
doesn't support modifying the source tree (a good thing in my opinion).

I'd like to see this submitted to the tree, and I'll keep updating it as
needed. See the commit message for instructions on how to build and install
with Meson.

There is also a second patch that adds a new
scripts/make_distribution_archives.py script. it essentially does the same
thing as "make dist", but doesn't rely on GNU Make / CMake / Meson in any
way. I think it's a better way to generate our distribution archives and a
good way to transition to a different build system overall.

Let me know what you think about these.

- Digit

PS: This introduces several python scripts, I have been using the "yapf"
tool to format them. If you know of a better python reformatter, let me
know.
From 45017badeade312778b7e0107873e9649ff52e34 Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Sun, 17 May 2020 18:45:41 +0200
Subject: [build] Add Meson build project files.

This adds a few files to build the FreeType 2 library
with the Meson build system:

- meson.build: top-level Meson build file for the library.

- meson_options.txt: user-selectable options for the build.
  These can be printed with 'meson configure', and selected
  as 'meson setup' or 'meson --reconfigure' time with
  -D=.

- scripts/parse_modules_cfg.py: A script invoked by
  meson.build to parse modules.cfg and extract important
  information out of it (i.e. the list of modules).

- scripts/process_ftoption_h.py: A script invoked by
  meson.build to process the original ftoption.h and
  enable or disabled configuration macro variables based
  on the available dependencies. This is similar to what
  other build systems are using (i.e. Meson configure_file()
  is not used here).

- scripts/extract_freetype_version.py: A script invoked by
  meson.build to extract the FreeType version number from
  

- scripts/extract_libtool_version.py: A script invoked by
  meson.build to extract the libtool revision_info from
  builds/unix/configure.raw and generate the corresponding
  shared library suffix.

- scripts/generate_reference_docs.py: A script invoked
  by meson.build to generate the FreeType 2 reference
  documentation (using the docwriter / mkdocs packages
  which must be installed previously).

Example usage:

  # Configure Meson build to generate release binaries comparable to
  # to the ones from the autotools/make build system.
  meson setup build-meson --prefix=/ --buildtype=debugoptimized --strip -Db_ndebug=true

  # Build and install to /tmp/aa/, this includes a pkg-config file.
  DESTDIR=/tmp/aa ninja -C build-meson install

  # Generate documentation under build-meson/docs
  ninja -C build-meson docs

Library size comparison for stripped libfreetype.so generated
by all three build systems:

  - Default build (autotools + libtool): 712 KiB
  - CMake build (RelWithDebInfo):712 KiB
  - Meson build: 712 KiB
---
 builds/unix/ftsystem.c  |   2 +-
 meson.build | 346 
 meson_options.txt   |   6 +
 scripts/extract_freetype_version.py | 101 
 scripts/extract_libtool_version.py  |  96 
 scripts/generate_reference_docs.py  |  63 +
 scripts/parse_modules_cfg.py| 141 
 scripts/process_ftoption_h.py   |  97 
 8 files changed, 851 insertions(+), 1 deletion(-)
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 scripts/extract_freetype_version.py
 create mode 100644 scripts/extract_libtool_version.py
 create mode 100644 scripts/generate_reference_docs.py
 create mode 100644 scripts/parse_modules_cfg.py
 create mode 100644 scripts/process_ftoption_h.py

diff --git a/builds/unix/ftsystem.c b/builds/unix/ftsystem.c
index 8437a6689..b4d71d40e 100644
--- a/builds/unix/ftsystem.c
+++ b/builds/unix/ftsystem.c
@@ -18,7 +18,7 @@
 
 #include 
   /* we use our special ftconfig.h file, not the standard one */
-#include 
+#include FT_CONFIG_CONFIG_H
 #include 
 #include 
 #include 
diff --git a/meson.build b/meson.build
new file mode 100644
index 0..1d8f2672c
--- /dev/null
+++ b/meson.build
@@ -0,0 +1,346 @@
+# Meson project file for FreeType 2
+
+project('freetype2', 'c', default_options: ['default_library=

Re: compressed streams

[David Turner]

Le ven. 18 sept. 2020 à 14:18, Alexei Podtelezhnikov  a
écrit :

>
>
> On Fri, Sep 18, 2020 at 7:18 AM David Turner  wrote:
>
>> Le jeu. 17 sept. 2020 à 14:01, Werner LEMBERG  a écrit :
>>
>>> > These are some horrible numbers that essentially test FT_Load_Glyph
>>> > from compressed unifont.pcf.gz in reverse order: [...]
>>>
>>> We do, there is no "rewinding the compressed stream", we have to restart
>> from the first byte of the file everytime we need to go back in the file.
>>
> [...]
>> So in theory, something like that could be added. It's just seems a lot
>> of complexity for little practical benefits imho.
>>
>
> Is this also true for pcf.Z and pcf.bz2? I would like to warn about this
> in the docs.
>
> Yes, absolutely! Historically, these font files are legacy from X11 and
no-one sane should be using these (there are TrueType equivalents for all
of these as far as understand).

Re: Meson build, continued

[David Turner]

All right, here's the same set of patches with Black applied. The
differences are minor, except for the use of double-quotes instead of
single ones (I don't care personally).
I'll let Werner choose which set is better :-)



Le ven. 18 sept. 2020 à 14:54, Nikolaus Waxweiler  a
écrit :

> PS: This introduces several python scripts, I have been using the "yapf"
>> tool to format them. If you know of a better python reformatter, let me
>> know.
>>
>
> Black It's the best
>
>>
From 8dcb5c0789a8065947eb66d08ceae730b6afae87 Mon Sep 17 00:00:00 2001
From: David Turner 
Date: Tue, 25 Aug 2020 20:52:32 +0200
Subject: [build] Add scripts/make_distribution_archives.py

This standalone Python script should be equivalent to running
"make dist" with the Make-based build system, with the following
minor differences:

- Since 'make distclean' doesn't always cleanup objs/ properly,
  the 'make dist' archives may contain some stale binaries like
  objs/.libs/libfreetype.so.6 or others.

- The config.guess and config.sub files are not update, unless
  one uses the --gnu-config-dir=DIR option to specify were they
  are located.

- Some bits of the auto-generated reference documentation may
  appear in slightly different order, probably due to issues
  related to mkdocs and docwriter.

Usage example:

  scripts/make_distribution_archives.py /tmp/freetype2-dist

Will create files the following files under /tmp/freetype2-dist:

  freetype-.tar.gz
  freetype-.tar.xz
  ft.zip
---
 scripts/make_distribution_archives.py | 188 ++
 1 file changed, 188 insertions(+)
 create mode 100755 scripts/make_distribution_archives.py

diff --git a/scripts/make_distribution_archives.py b/scripts/make_distribution_archives.py
new file mode 100755
index 0..cf2bb544f
--- /dev/null
+++ b/scripts/make_distribution_archives.py
@@ -0,0 +1,188 @@
+#!/usr/bin/env python3
+"""Generate distribution archives for a given FreeType 2 release."""
+
+from __future__ import print_function
+
+import argparse
+import atexit
+import os
+import shutil
+import subprocess
+import sys
+import tempfile
+
+_SCRIPT_DIR = os.path.dirname(__file__)
+_TOP_DIR = os.path.abspath(os.path.join(_SCRIPT_DIR, ".."))
+
+
+def get_cmd_output(cmd, cwd=None):
+"""Run a command and return its output as a string."""
+if cwd is not None:
+out = subprocess.check_output(cmd, cwd=cwd)
+else:
+out = subprocess.check_output(cmd)
+return out.decode("utf-8").rstrip()
+
+
+def is_git_dir_clean(git_dir):
+"""Return True iff |git_dir| is a git directory in clean state."""
+out = get_cmd_output(["git", "status", "--porcelain"], cwd=git_dir)
+return len(out) == 0
+
+
+def main():
+parser = argparse.ArgumentParser(description=__doc__)
+
+parser.add_argument("--source_dir", default=_TOP_DIR, help="Source directory path.")
+
+parser.add_argument(
+"--version",
+help="Specify alternate FreeType version (it is otherwise extracted from "
+"current sources by default).",
+)
+
+parser.add_argument(
+"--gnu-config-dir",
+help=(
+"Path of input directory containing recent `config.guess` and "
+"`config.sub` files from GNU config."
+),
+)
+
+parser.add_argument(
+"--build-dir",
+help="Specify build directory. Only used for debugging this script.",
+)
+
+parser.add_argument(
+"--ignore-clean-check",
+action="store_true",
+help="Do not check for a clean source git repository. Only used for "
+"debugging this script.",
+)
+
+parser.add_argument("output_dir", help="Output directory for generated archives.")
+
+args = parser.parse_args()
+
+git_dir = args.source_dir if args.source_dir else _TOP_DIR
+if not args.ignore_clean_check and not is_git_dir_clean(git_dir):
+sys.stderr.write(
+"ERROR: Your git repository is not in a clean state: %s\n" % git_dir
+)
+return 1
+
+if args.version:
+version = args.version
+else:
+# Extract FreeType version from sources.
+version = get_cmd_output(
+[
+sys.executable,
+os.path.join(_SCRIPT_DIR, "extract_freetype_version.py"),
+os.path.join(_TOP_DIR, "include", "freetype", "freetype.h"),
+]
+)
+
+# Determine the build directory. This will be a temporary file that is
+# cleaned up on script exit by default, unless --bu

Re: Meson build, continued

[David Turner]

Le ven. 18 sept. 2020 à 16:22, Alexei Podtelezhnikov  a
écrit :

> Let's not clog the src folder please
>
> src/base/amiga (not src/amiga)
> src/base/unix (not src/unix)
>
> What about using a _.c suffix, as in:

src/base/ftsystem_amiga.c
src/base/ftsystem_win32.c
etc..

We are no longer limited to 8.3 filenames, and I find this approach makes
it easy to spot source files which have platform-specific variants.


> > don't you think that all those (source) files should be in src/ ? I
>> > would find these more logical. Maybe in subdirectories of src (like
>> > src/unix src/mac src/windows etc...)
>
>

Re: freetype.org domain

[David Turner]

Hello Daniel,

As Werner said I an the contact and holder for the freetype.org domain, but
feel free to send emails to freetype-devel@ directly to discuss DNS issues.
We don't really have a need to move to X.org, or to other organizations at
the moment, and this has worked pretty well for us.

Best regards

- David

W

Le mar. 8 févr. 2022 à 12:49, Werner LEMBERG  a écrit :

>
> Hello Daniel,
>
>
> >> I'm from the X.org board of directors, and we're going through all
> >> the domains that freedesktop.org infrastructure is hosting.  One of
> >> them is freetype.org, and we got a few questions:
> >>
> >> - who's the current contact and holder?  In case we need that for
> >>   moving things around in the DNS, or other reasons.  Feel free to
> >>   drop to board@ only if you dont want to discuss this in private.
> >>
> >> - also, is there any interest in moving to X.org?  I don't expect
> >>   this to be the case here, but for the domains that are part of
> >>   the fd.o/x.org core mission we're trying to consolidate them and
> >>   clear up ownership, so while I go around might as well ask.
> >>
> >> If you know a better place to ask these, please reply and add them.
> >
> > Just a quick ping, plus adding -devel since it looks like this
> > hasn't made it to archives.
>
> Indeed, I haven't seen your original message, sorry for that.
>
> The owner of the 'freetype.org' domain is David Turner
> ; I have already forwarded your message to him so
> that he can respond.
>
>
> Werner
>
>

Re: Add support for FT_Face cloning

[David Turner]

I have specific worries about what is being proposed here:

   - First, the proposed merge requests adds a ton of conditional code
   paths that are impossible to properly review now or even maintain over
   time. Since there is no proper distinction in the source code between what
   is supposed to be shareable+readonly and exclusive+mutable, There is no way
   by looking at the code to determine the *correctness* of the change,
   this will make improving library internals even more difficult in the
   future. It is very likely that this feature is gonna break in subtle ways
   that are very hard to detect beforehand. Given the scope of the library's
   API, I don't think it is possible to come up with an extensive regression
   test that covers every possibility. I am convinced this will not be
   maintainable over time. Sorry.


   - The locking requirements do not only apply to the input stream but to
   any data that is loaded or created on demand. A lot of these have been
   removed to make the library "more thread-safe" (it really isn't). And since
   the FreeType API was designed to use mutable state very intentionally (this
   saves a lot of memory compared to the use of immutable data structures,
   which was important for embedded systems). There is no clear way for a
   client to determine whether a given API will mutate the state, so the only
   safe option for a client is to lock on every API call.


   - Finally, calling these instances "clones" or "copies" is misleading. A
   best they should be called "dependent faces" or "child faces", but the fact
   that they complicate the lifecycle management of many objects is a problem
   in itself.

Just like for multi-thread usage, the only correct way to deal with a
mutable API is to either use locking of a single instance before doing any
mutable operation (be it loading something, or changing some settings), or
to create several FT_Face instances instead. This keeps an already
complicated API manageable without introducing new failure modes.

However, it should be possible to implement a real "cloning" facility that
could be used for safe multi-threaded and variable-fonts usage. As long as
all read-only sharing is hidden from the client, it can be introduced
progressively into the source tree.
What I mean more precisely:

   - An FT_Clone_Face() API that takes an input FT_Face instance and
   returns a new instance that has its own lifecycle (except that they will be
   children of the same FT_Library, and use the same FT_Memory allocator).
   - For the input stream, a way to either clone it, or share it safely
   between instances is needed, and should be provided as an argument to the
   function in some way. We could change the stream implementation used
   internally by the library to make this easier, or we could require the
   client to use FT_Open_Face() with a user-provided shareable stream for
   FT_Clone_Face() to work.
   - The initial implementation would simply re-open the face with the new
   stream, inefficient but completely safe. But this opens the door to
   identifying read-only data in the source face that can be copied directly
   to the clone, saving all the work required to load/validate/compute it.
   - Note that I wrote "copy" above, because for efficient and safe
   read-only sharing, atomic reference counting is required, which is not part
   of C99, hence not portable. However, it can be introduced as a separate
   step by defining the right abstractions (types and macros to operate on
   them). Essentially, we need the equivalent of std::shared_ptr<>, or the
   intrusive versions of it where the ref-count is at the start of the shared
   object, but in C99 instead. For platforms that do not support threads, just
   do non-atomic refcounts.
   - The most important part is being able to progressively increase the
   efficiency of the cloning process in a way that adds read-only sharing in
   an explicit way that is easy to control at review time, or when changing
   the library's internals.







Le ven. 4 févr. 2022 à 17:02, Werner LEMBERG  a écrit :

>
> > This proposal aims to take the best of both approaches by
> > introducing a new function, `FT_Clone_Face`.  [...]
>
> Excellent summary, much appreciated, thanks!
>
> What we are mainly interested in is whether other users would going to
> use the proposed API as advertised.  If yes, please say so.  Otherwise
> it would be great if you could discuss problematic issues with
> Tayyab's approach.
>
>
> Werner
>
>

Re: serving compressed images

[David Turner]

Le jeu. 10 févr. 2022 à 05:32, Alexei Podtelezhnikov  a
écrit :

> Hi All,
>
> As Werner is working on improving the SBIX table support
> (https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/139),
> a topic of compressed images came up. Right now, FreeType depends on
> libpng to uncompress PNG, but SBIX can have TIFF and JPEG. So I was
> wondering if we should even bother uncompressing those. FreeType could
> just serve compressed data. With SBIX, FreeType could still match the
> best strike to the requested size but then just deliver
> FT_GLYPH_FORMAT_IMAGE with a tag, some minimal metadata, and raw bytes
> under FT_GlyphSlot->other.
>
> This would be quite similar to the SVG plans currently slated for the
> next release, i.e., we delegate uncompressing and rendering to a
> client.
>
> Is there interest in such a feature?
>
> I agree that I don't see much use for JPEG and TIFF decoding in the
library itself,
It might be convenient for a client to provide an optional function to
decode those with its decoding library of choice, and have FreeType return
the bitmap data obtained so far, since this would simplify code paths.
As usual, it is important to avoid introducing too much complexity in the
API or implementation related to pixel color formats, data layouts, and
memory allocation / release.

At first, just returning the raw bytes is a perfectly valid option.


> Thanks,
> Alexei
>
>

Re: [ft-devel] consistency of ftoutln.c and ftbitmap.c

[David Turner]

Chia I Wu a écrit :
Hi all,
I am trying to make ftbitmap.c the same thing to FT_Bitmap as ftoutln.c
is to FT_Outline, but there's one problem. FT_Outline has "flags" and
yet FT_Bitmap don't. I plan to add "flags" to FT_Bitmap and removes
FT_GLYPH_OWN_BITMAP from FT_GlyphSlot_InternalRec. Will this break
anything?
Yes, modifying a public structure that can be allocated by the user
generally means breaking any application that uses the library.
Do NOT do this.
- David Turner
- The FreeType Project  (www.freetype.org)
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Export services?

[David Turner]

Hi everyone,

"services" are an _implementation_ detail of FreeType 2. They're not
strictly necessary since you could provide the same thing with a lot
of #ifdef in a monolithic engine. I just find them more convenient
to structure the engine.

the "wrapper" functions are here to protect the users of the service's
implementation details. They have various advantages:

- they expose a "clean" API that doesn't depend on internals of
 the font engine. Allowing us to redesign services when needed

- services can be used either internally or to implement a public
 API.

in other words, exposing services publicly has many problems:

- it forces us to expose more internals of the font engine, which
 means less possibilities for improvements in the future. And
 it's not like we've not been burned by this already
 (i.e. FT_OPTIMIZE_MEMORY breaks rogue libraries)

- it forces us to add a way to distinguish between "internal"
 and "public" services.

And I don't see how they could make the engine "more powerful".

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)




Chia-I Wu a écrit :


Hi,

There are some functions which are wrappers to services.  Then why not
simply export the services to clients?

The idea is, we let modules decide which services, among those they
provide, to export.  For a exported service, it should provide headers,
not depending on internal headers, to describe the interface.  Of course
error-checking should be done with more care in this case.  To make
finding a serviou ce faster, we can use integers as service id, instead of
strings.

These are what I can think of now.  Surely there are more things we
should pay attention to when exporting services, but it also means
freetype can get more powerful.

 

services are an _implementation_ detail of FreeType 2, yand masking them 
from the user

is a good thing, because it allows us to



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] About customization of freetype for BDF

[David Turner]

Hi Werner,



 src/raster/raster.c -- monochrome rasterizer

 


This one is not needed for BDF, which isn't a vector format.


 optional:
 src/cache/ftcache.c -- cache sub-system (in beta)
 src/gzip/ftgzip.c   -- support for compressed fonts (.gz)
 src/lzw/ftlzw.c -- support for compressed fonts (.Z)

 

By the way, the BDF driver starts by allocating a 64 Kb buffer before 
reading a single
byte from the font file, and the LZW reader allocates up-front a 400Kb 
buffer for
decompression purposes (yes, you've read that correctly !!). Some day, 
I'm going

to rewrite this crap...

Dont' know if this is going to fly for embedded systems :-)

For small footprint environments, I'd recommend using a different font 
format.
BDF font files are very large, take a lot of time to parse, and the 
current driver

uses gobs of memory to load the font file.

You'd better try PCF or WinFNT instead if all you need is a bitmap font 
format.

It will be much much lighter for your CPU and RAM.

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Segfault with otf and face_index == -1

[David Turner]

Hello,

thanks, I've commited a fix, which is to never call FT_New_GlyphSlot and 
FT_New_Size

within FT_Open_Face when face_index is < 0.

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)


Ville Syrjälä a écrit :


Hello,

When FT_New_Face() is called for an otf font with face_index == -1 
freetype segfaults.


The backtrace looks like this:
#0  0xb557a46c in cff_slot_init (slot=0x8057070) at cffobjs.c:304
#1  0xb55601f8 in ft_glyphslot_init (slot=0x8057070) at ftobjs.c:225
#2  0xb5560550 in FT_New_GlyphSlot (face=0x8056ca0, aslot=0xbfffdda8) at 
ftobjs.c:362
#3  0xb5561f84 in FT_Open_Face (library=0x8050b18, args=0xbfffde00, 
face_index=-1, aface=0xbfffde4c) at ftobjs.c:1685
#4  0xb5561039 in FT_New_Face (library=0x8050b18, pathname=0xb34b

And it segfaults here:
 FT_LOCAL_DEF( FT_Error )
 cff_slot_init( FT_GlyphSlot  slot )
 {
   CFF_Face  face = (CFF_Face)slot->face;
   CFF_Font  font = (CFF_FontRec *)face->extra.data;
->   PSHinter_Service  pshinter = (PSHinter_Service)font->pshinter;

The problem is that with face_index == -1 cff_face_init() returns before 
face->extra.data and cff->pshinter are set.


No patch since I'm not sure what the proper fix would be...

 





___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] more FT_INTERNAL removal

[David Turner]

Thanks Matthias,

I believe that I had already sent a similar patch to Keith Packard.
Anyway, I'd like to update the FreeType web site to put a list of
patches online.

Werner, how do you do that ? I couldn't connect properly with
ssh/scp.

Regards,

- David


Matthias Clasen a écrit :


I have written a patch to make fontconfig no longer use FT_INTERNAL
headers, by copying the ftglue code found in Pango. The patch is at
https://bugs.freedesktop.org/show_bug.cgi?id=4779


Matthias



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
 





___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] FreeType compatibility with C++ managed extensions

[David Turner]

Hi Graham,

an identifier like "generic" is part of the public API and is already used
by third-party libraries (e.g. Pango). There is thus a _very_ slim chance
that we're going to change it. On the other hand, "internal" is not supposed
to be used by clients, so it could be changed.

There might a solution by using some ugly processors tricks, with a small
price to pay for managed-C++ users which should use one or two distinct
identifiers (e.g. "generik" instead of "generic")

Do you have a complete list of problematic keywords ?

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)


Graham Asher a écrit :


Dear FreeTypers,

I had some second thoughts about making FreeType run under C++ managed
extensions.

You have to compile everything as C++, not C. That causes compatibility
problems. To quote Microsoft
(http://msdn2.microsoft.com/en-us/library/ms173265): "The C++ type-safety
rules are strict, so type conversions must be made explicit with casts. For
example, malloc returns a void pointer, but can be assigned to a pointer to
any type in C with a cast:" ... and "Identifiers used in C code that happen
to be keywords in C++ (such as virtual, new, delete, bool, true, false,
etc.) must be renamed. This can generally be done with simple
search-and-replace operations.".

This alone makes my original idea impractical :-(

So my original impression that all I had to do was change identifiers in
header files #included by C++ was incorrect.

Therefore I withdraw my proposal. (It may still be possible to use FreeType
in what Microsoft call a 'mixed assembly' - part managed C++ and part
unmanaged C/C++ - the unmanaged part would be FreeType - but the header
files would still cause a problem to any managed code that needed to call
FreeType functions.)

Best regards,

Graham Asher




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
 





___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Segfault with otf and face_index == -1

[David Turner]

Hi Again,

no, this is on purpose. If you call FT_New_Face with face_index < 0, it
should return an empty FT_Face object to indicate that the format is 
supported

(otherwise, an error is returned).

Moreover, the face->num_faces field can be used to determine the number
of faces within the font file.

After that, the caller must destroy the FT_Face normally with FT_Done_Face

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)


Ville Syrjälä a écrit :


On Tue, Oct 18, 2005 at 12:58:41AM +0300, Ville Syrjälä wrote:
 


On Mon, Oct 17, 2005 at 11:18:35PM +0200, David Turner wrote:
   


Hello,

thanks, I've commited a fix, which is to never call FT_New_GlyphSlot and 
FT_New_Size

within FT_Open_Face when face_index is < 0.

Hope this helps,
 


It works. Thanks.
   



It looks like the current code will leak memory though. AFAICS it needs 
something like this:


--- ftobjs.c.orig   2005-10-18 01:20:51.0 +0300
+++ ftobjs.c2005-10-18 01:20:38.0 +0300
@@ -1751,8 +1751,11 @@
  internal->transform_delta.y = 0;
}

-if ( aface )
+if ( face_index >= 0 )
  *aface = face;
+else
+  FT_Done_Face( face );
+
goto Exit;

  Fail:

 





___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Freetype CVS & fontconfig

[David Turner]

Hello,

FT_Free was *never* public. You should upgrade your fontconfig to a more
recent version, since it must include the necessary patch to get rid of all
FT2 internals dependencies.

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)


Ismail Donmez a écrit :


Hi all,

After I installed Freetype2 from CVS, fontconfig started giving undefined 
reference to FT_Free so I tried to recompile fontconfig but it gave the same 
error while compiling.


Is this expected i.e FT_Free is no longer public now?

Regards,
ismail


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
 





___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] current cvs on suse 10

[David Turner]

You can't use Qt3 ( didn't check Qt but afaik its the same ) with freetype2 
from cvs because it uses internal freetype functions which are not exported 
now.


 

But it's possible to provide a patch that only relies on public APIs and 
structures to do the
same thing. That's what we've done for the Pango patch, and something 
similar can be

back-ported to Qt 3 as well.

Unfortunately, I don't have the time to do that myself :-(

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)


Regards,
ismail


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
 





___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] ft-smooth for 2.1.10?

[David Turner]

Hi,

bulia byak a écrit :

>Sorry for being obnoxious... but, is this code (rendering similar to
>2.1.9 with David Chester's patch) now in CVS, by any chance?
>
>Thanks!
>
>  
>
WARNING: INSTALLING THE CURRENT CVS WILL PROBABLY BREAK YOUR SYSTEM

Sort of, the LIGHT hinting mode has been modified to duplicate its
behaviour, but:

- it's not the default (you need to select "light" hinting in the font
preferences dialog,
  or tweaking your fonts.conf file)

- it doesn't force the auto-hinter on all font formats, like David
Chester's patch.
  I'll try to see in the future

I've been able to test it on my desktop with a set of horrible linker
tweaks that event I
don't fully understand, but the rendering changes work well. Curiously,
it looks a lot better
on a desktop than in ftview :-)

I'm now only focusing on getting all the correct bits and pieces to be
able to install
the current sources on a machine without breaking everything. This will
most certainly
require upgrading your versions of GLib, Pango, FontConfig, libXft and a
few others.

Also, some deprecated cache APIs are probably going to come back since
there are
a lot of packages that already depend on them, and that shouldn't imply
problems
in the internals.

More on this later,

- David Turner
- The FreeType Project  (www.freetype.org)


>On 11/18/05, Turner, David <[EMAIL PROTECTED]> wrote:
>  
>
>>>ME TOO. David, I've been using your patch for a long time and I love
>>>it. Personally I just cannot understand how someone can so badly break
>>>the kerning and character shapes for some marginal gain in crispness.
>>>But, EVEN if this is not made the default, I don't see why it's not
>>>included even as an option!
>>>
>>>In case the FT developers keep being unflexible on this issue, David,
>>>can you please update your patch so it works with 2.1.10?
>>>
>>>  
>>>
>>To be honest, I was unaware of this patch, or simply completely forgot
>>about it when it's been presented.
>>
>>It's not like we're not trying to improve the engine's rendering. We
>>have integrated David Chester's improvements, but this needed a mostly
>>complete rewrite of his code, because a quick hack is not always the
>>best way to implement a feature.
>>
>>The same is true for the current patch. It's much shorter though,
>>so it should be easy to integrate.
>>
>>Also, notice that some people complain because the LIGHT hinting
>>mode creates color fringes in LCD-decimated mode, so strong hinting
>>will still be required for some users, at least.
>>
>>
>>Thanks,
>>
>>- David Turner
>>- The FreeType Project  (www.freetype.org)
>>
>>
>>
>>
>>>--
>>>bulia byak
>>>Inkscape. Draw Freely.
>>>http://www.inkscape.org
>>>
>>>
>>>___
>>>Freetype-devel mailing list
>>>Freetype-devel@nongnu.org
>>>http://lists.nongnu.org/mailman/listinfo/freetype-devel
>>>
>>>  
>>>
>>***
>>Information contained in this email message is confidential and may be 
>>privileged, and is intended only for use of the individual or entity named 
>>above. If the reader of this message is not the intended recipient, or the 
>>employee or agent responsible to deliver it to the intended recipient, you 
>>are hereby notified that any dissemination, distribution or copying of this 
>>communication is strictly prohibited. If you have received this communication 
>>in error, please immediately notify the [EMAIL PROTECTED] and destroy the 
>>original message.
>>***
>>
>>
>>
>>
>
>
>--
>bulia byak
>Inkscape. Draw Freely.
>http://www.inkscape.org
>
>
>___
>Freetype-devel mailing list
>Freetype-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/freetype-devel
>  
>



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] ft-smooth for 2.1.10?

[David Turner]

Hi,

Le samedi 24 décembre 2005 à 12:35 -0400, bulia byak a écrit :
> On 12/20/05, Ismail Donmez <[EMAIL PROTECTED]> wrote:
> > Well you will need unreleased Qt,fontconfig etc else you won't be able to
> > compile anything that links to freetype.
> 
> Unfortunately this is a bit more than I can afford at the moment... so
> I guess I'll have to wait. Meanwhile I wondered if I can ask the
> developers a few questions:
> 
> - When the new version is out, do I get it right that this new mode
> will not be the default?
> 
The new version is more or less ready. We're now trying to provide
as many patches to rogue client libraries and programs. See:

http://turnerdavid.neuf.fr/freetype/freetype-2.2.0-safe-install.html
http://turnerdavid.neuf.fr/freetype/rogue-patches.html

until this list of patches is sufficiently complete, there will be no
2.2
release to prevent creating too much problems for unsuspecting users.

my biggest gripe at the moment is XFree86 :-)

> - What will be reqiuired to enable it in the new version - a
> recompile, or something less drastic would suffice?
> 
if you're calling the font engine directly, use the FT_LOAD_TARGET_LIGHT
value to suggest the "light" hinting mode. You won't need to recompile
your
code if you already do, since we only changed some internal parts of the
algorithm.

for Gnome users, launch the font properties dialog (a.k.a.
gnome-font-properties)
and select the "better shapes" option in the first page. Or, in the
advanced page,
select "light hinting".

by the way, there is no difference between "light" and "medium" hinting
in this
panel. These two options are there for historical reasons and should be
merged
into a single one.

I don't know about KDE, since I don't use it, but I suspect something
similar.

notice that for this to work properly, you'll also need a recent version
of libXft
installed on your system (some older versions didn't select the FreeType
hinting
algorithm correctly)

> - Will some kind soul please share a screenshot showing this rendering
> mode with CVS freetype?
> 
Sure ;-)

http://turnerdavid.neuf.fr/freetype/screenshots/evolution-default.png
http://turnerdavid.neuf.fr/freetype/screenshots/evolution-light.png
http://turnerdavid.neuf.fr/freetype/screenshots/anjuta-default.png
http://turnerdavid.neuf.fr/freetype/screenshots/anjuta-light.png

happy new year,

- David Turner
- The FreeType Project  (www.freetype.org)

> Thanks!
> 
> --
> bulia byak
> Inkscape. Draw Freely.
> http://www.inkscape.org
> 
> 
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/freetype-devel



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] LIGHT hinting enhancement back-ported to FreeType 2.1.10

[David Turner]

hello,

what you see is normal, since the LIGHT hinting mode also *forces*
auto-hinting (after all, "light" hinting doesn't mean anything to the
bytecode
interpreter)

to solve your problem, simply update your fonts.conf rules to set "full"
hinting for Arial and other fonts you want to see handled by the bytecode
interpreter

Apart from that, Firefox, as well as a few other applications (and even
Gnome widgets !!) don't properly respond to changes in the fonts
preferences dialog, you can however restart them after your change, and
everything should work

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)


GhePeU a écrit :

>Hello, 
>
>I just tryed freetype 2.1.10 with this patch. The rendering is much
>better than with "clean" freetype, but now my fontconfig rules aren't
>applied anymore.
>
>I usually compile freetype with the bytecode interpreter, then I enable
>the auto-hinter in /etc/fonts/local.conf with:
>
>
>true
>
>
>and finally I switch to the bytecode interpreter for some fonts only:
>
>
>Arial
>false
>
>
>Now, when I set the LIGHT/MEDIUM hinting with the gnome utility these
>settings are ignored, while when I choose FULL hinting they are observed
>only by some applications (for instance, gnome-terminal) and ignored by
>others (firefox 1.5).
>
>However, the render quality has improved, at least to my eyes.
>
>Giacomo Perale
>
>
>
>
>___
>Freetype-devel mailing list
>Freetype-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/freetype-devel
>  
>



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] is it possible to retrieve whole kerning table?

[David Turner]

Hello,

you could try FT_Load_Sfnt_Table to retrieve the "kern" table,
then parse it yourself to build wathever structure you need from it

Hope this helps,

- David


Piotr Pawłow a écrit :

>Hello,
>
>I am trying to figure out how to implement WIN32 GetKerningPairs[1] function 
>in Wine. Unfortunately, I can't find a similar function in freetype API. 
>There is FT_Get_Kerning, but in order to build a whole table I would need to 
>know all the kerning pairs in a font, or brute-force check all 
>combinations :)
>
>Any idea how to do it?
>
>[1] http://msdn.microsoft.com/library/en-us/gdi/fontext_969f.asp
>
>  
>



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] when does the next version of freetype release?

[david turner]

Chia-I Wu a écrit :

  On Tue, Jan 17, 2006 at 06:22:45PM +0100, Werner LEMBERG wrote:
  
  

  I want to know when does the next version (ver 2.2.0?)
of freetype release?
  

Hopefully within a month or so.

  
  Will it be released with FT_OPTIMIZE_MEMORY defined?
  

Yes, d.e.f.i.n.i.t.e.l.y !!

  And will the major .so version be bumpped up?

  

Nope, because this would create problems as Owen Taylor pointed out,
since through indirect linking, a given program might find itself
dependent
on both libfreetype6 and libfreetype7, which could cause major problems
depending on the code paths being used.

Instead you'll have to patch rogue clients to get a working system.
More information at:

http://turnerdavid.neuf.fr/freetype/freetype-2.2.0-safe-install.html
http://turnerdavid.neuf.fr/freetype/rogue-patches.html

Hope this helps,

- David




***Information contained in this email message is confidential and may be privileged, and is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message.*** 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] web page for the forthcoming 2.2.0 release

[david turner]

Hi Werner and all,


Perhaps we shall *rename* the library to, say, `libft2', instead of
`libfreetype', together with a new API prefix `FT2_' instead of `FT_'.
This would avoid the whole mess.

  
Simply changing the library name is not going to change a lot of things 
due to the way dynamic
linking works with ELF, it's simply equivalent to changing the so 
version number.


Now, if we talk about a new API prefix, we're essentially asking that 
*all* clients that use FreeType
be rewritten to use it, or they'll be stuck with 2.1.10 which we don't 
want to maintain anymore.


However, the percentage of "rogue" clients (i.e. the one that are going 
to break due to the new install) is,
much smaller, and easier to spot if you have access to their sources 
(since simple grepping is sufficient)


Another option is to use a new API prefix internally, but provide 
backwards compatibility macros like:


#define  FT_New_Face FT2_New_Face

so that clients can be recompiled without modifications. The macros 
*should* be disabled when building
the library, to that the corresponding object files only contain FT2_ 
functions. This will avoid any bad

ELF magic to happen (though it may make debugging fun :-)

However, this will *not* prevent programs from being linked to both 
libfreetype.so.6 and, say, libft2.so.1 or
wathever. Even though the probabilities of crashes will be reduced, it 
might produce unexpected results.


And it will *still* break rogue clients that are compiled against the 
new version. Which is why I'm wondering
if it will solve anything at all ? Sure, you can use your package 
manager to refuse to install libfreetype.so.6 and
libfreetype.so.7 together, but you won't be able to install 
libfreetype.so.7 until all rogue clients are patched

anyway.

In other words, the big deal are the rogue clients, not all programs 
that use FreeType. We need to spot these,

and provide patches before making a public release.

Another option is to have ./configure refuse to install freetype 2.2.0 
if a previous release of the library is
detected on the system; that is, unless you use a super-duper parameter 
like --please-destroy-my-desktop

that only the cautious will care to use.

Any comments ?

- David Turner
- The FreeType Project  (www.freetype.org)


Werner


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

  


***
Information contained in this email message is confidential and may be 
privileged, and is intended only for use of the individual or entity named 
above. If the reader of this message is not the intended recipient, or the 
employee or agent responsible to deliver it to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the [EMAIL PROTECTED] and destroy the 
original message.
*** 




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox)

[david turner]

Hello Drew,

thanks a *lot* for this e-mail. Here's what I've understood of the 
situation:


- first of all, the fact that the code includes "t42types.h" means that the
 original developer assumed that Xprint was using the version of FreeType
 embedded within the X server, since this header has _never_ been installed
 by our configure scripts in any version of FreeType. the code can only be
 compiled with the FreeType sources available from the include path.

 If this assumptions holds true (i.e. Xprint basically uses its own 
copy of FreeType
 instead of the one installed on the system), it is at least safe from 
the 2.2 install

 problems we described recently. Good to know.

- there is a public field named "bbox" in the FT_Face structure that 
receives
 the global font bounding box in EM units. This is slightly different 
from the

 so-called Type 1 "font_bbox" values that are accessed by the code, which
 are all expressed in 16.16 fixed point values.

 this is not surprising: since the Type 1 spec states that coordinates 
can be
 decimal, not necessarily integer, we parse all of them as 16.16 fixed 
point

 numbers (which are large enough to contain all coordinate values found in
 real-life fonts). However, we convert them to integers where appropriate.

 For example, the face->bbox fields are populated by code that is found
 here in the CVS sources:

 src/type1/t1objs.c (403):
 root->bbox.xMin =   type1->font_bbox.xMin >> 16;
 root->bbox.yMin =   type1->font_bbox.yMin >> 16;
 root->bbox.xMax = ( type1->font_bbox.xMax + 0xU ) >> 16;
 root->bbox.yMax = ( type1->font_bbox.yMax + 0xU ) >> 16;
 
 src/cid/cidobjs.c (415):

 cidface->bbox.xMin =   cid->font_bbox.xMin >> 16;
 cidface->bbox.yMin =   cid->font_bbox.yMin >> 16;
 cidface->bbox.xMax = ( cid->font_bbox.xMax + 0xU ) >> 16;
 cidface->bbox.yMax = ( cid->font_bbox.yMax + 0xU ) >> 16;

 src/type42/t42objs.c (290):
 /* Ignore info in FontInfo dictionary and use the info from the  */
 /* loaded TTF font.  The PostScript interpreter also ignores it. */
 root->bbox = face->ttf_face->bbox;

As you can see, we simply truncate/ceil the 16.16 values to integers for 
the Type 1

and CID formats, and use the integer ones provided by the TTF container for
Type42 (and the comment suggests that this is the correct way to do it).

The Xprint code uses the internals to reach the original 16.16 values, 
and it
also ignores the ones provided by the TrueType container in the case of 
Type42

(which is probably wrong, if we're to believe the comment).

Now, it all depends wether Xprint needs the original exact values or not.

A/ in one hand, we can imagine it could use the face->bbox fields, multiply
 them by 65536 to obtain "equivalent" values. This may create a slightly
 larger bounding box *if* the original values were decimal, instead of
 integers.

 First of all, I don't think that this will be the majority of cases. 
Second, I'm

 not even certain that this would have any impact on Xprint's output.

B/ on the other hand, we can also imagine that Xprint wants the *absolutely*
 exact values, without truncating/rounding. Then, we can provide you with
 a small high-level API that implements this "feature" in a clean way. For
 example by getting the Type42 values from the TrueType container
 as well :-)

 This code would depend on a newer version of FreeType though.

I don't know enough about Xprint to determine which solution is correct,
but I suspect that A/ is simple and largely sufficient for your needs.

I hope you'll find this information useful. Please let us know of any change
or patch you'd be able to provide, we'd be happy to add it to our list.

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)


Drew Parsons a écrit :

Dear FreeType developers,

I am involved with Xprint, an X11 extension enabling printing using the
X protocol [1].

Xprint uses FreeType2, but unfortunately its postscript driver uses the
internal freetype headers.  You've written very clearly [2] that this
should not be done, and I would to take up your kind offer to work with
us to patch the problem.

The incriminating code is found in Xprint/ps/psout_ftpstype3.c.  It can
be found in X.org's new modular system at
http://cvs.freedesktop.org/xorg/xserver/xorg/Xprint/ps/psout_ftpstype3.c?view=markup
However the freetype support is not yet switched on in the modular
build, so if you need to compile it yourself you might find the old
monolithic builds [3] ready for use.

The internal headers are referenced in psout_ftpstype3.c around l.58:

#define USE_FT_INTERNALS 1
#ifdef USE_FT_INTERNALS
#include FT_INTERNAL_TYPE1_TYPES_H
#include "t42ty

Re: [ft-devel] web page for the forthcoming 2.2.0 release

[david turner]

Victor Luchits a écrit :

  -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

  
  
Perhaps we shall *rename* the library to, say, `libft2', instead of
`libfreetype', together with a new API prefix `FT2_' instead of `FT_'.
This would avoid the whole mess.

  
  
Yeah, that and to keep binary compatibility a stub library could be
written as a replacement for an old libfreetype.so, which would just
dlopen the new .so and call appropriate functions. This is an ugly
solution but *should* work until a better solution is found.

What do you think?

  

I don't think you understand the problem. 2.2.0 is binary
compatible with previous versions,
_except_ for a few rogue clients which access its internals directly:


  by calling some internal functions which are not available
anymore.
  by peeking/poking at internal fields of public FreeType objects,
and some of them have changed considerably
  


this cannot be fixed with a simple stub library, or we would have done
it already.

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)


  - --
Best regards,
 Victor Luchitsmailto:[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD1BENdRaO3lCd98MRAnQ+AKDP9x2HlKQAsj3xZc9JZKltJSZ9VwCeKDCF
seml/TMLEIKJFcbAPNP2yu0=
=7q35
-END PGP SIGNATURE-


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

  


***Information contained in this email message is confidential and may be privileged, and is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message.*** 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] web page for the forthcoming 2.2.0 release

[david turner]

  
Another option is to have ./configure refuse to install freetype
2.2.0 if a previous release of the library is detected on the
system; that is, unless you use a super-duper parameter like
--please-destroy-my-desktop that only the cautious will care to use.

  
  
I second this.  A big warning should be emitted if an older FreeType
DLL and/or header files are found.  How to do this sensibly is beyond
my knowledge.

  

we don't need to cover all cases, I think the following should be
enough:

- check that a freetype-config script is available from current PATH
- check also the availabilty through pkg-config as well
- check that the prefix is set to /usr or /usr/local (maybe
/usr/X11/lib as well)

Any takers ?

- David


  
Werner

  


***Information contained in this email message is confidential and may be privileged, and is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message.*** 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox)

[david turner]

Hi Drew,



I think your option A would probably be safe.  But if you do think
providing the API would be generally useful, then let me know when it's
implemented, I could upgrade the Xprint to use it in the future.

  
I don't think it is useful for ordinary users of the library. The 
programs that need the *exact*
values tend to be the one that are capable of parsing the Postscript 
anyway, so they don't
rely on something like FreeType that tries to provide a unified 
interface instead, masking

as much nasty things as possible.

Yes, it's probably better for Xprint users not to necessarily have to
force them to upgrade their version of Freetype, I think. So working
around the cooordinate conversion is probably best for now.

  

I think so

Let me see if I have the idea right.  I would simply want to replace
FT_Get_PS_Font_BBox( ) to look something like:

static FT_BBox *
FT_Get_PS_Font_BBox( FT_Face face )
{
  const char *driver_name;
  FT_BBox*font_bbox = malloc(sizeof( FT_BBox ) );

  if ( face )
  {
font_bbox->xMin = face->bbox.xMin * 65536;
font_bbox->yMin = face->bbox.yMin * 65536;
font_bbox->xMax = face->bbox.xMax * 65536;
font_bbox->yMax = face->bbox.yMax * 65536;
 }
return font_bbox;
}

Is that the general idea? 

  
Yes, it is, but you'll have the problem of knowing when freeing the 
allocated structure
(and handling out-of-memory conditions as well properly within the 
function and its

caller as well, tsss, tsss :-)


xMax and yMax also added 0xU ("root->bbox.xMax =
( type1->font_bbox.xMax + 0xU ) >> 16;" instead of just
"root->bbox.xMin =   type1->font_bbox.xMin  >> 16;"), so is simply
multiplying by 65536 really all I need to do?

  
yes, the operation is equivalent to a ceil-rounding, i.e. it will round 
2.0 to 2 and 2.1 to 3
when you receive the integer values, you've already lost the fractional 
part anyway, so
simply multiplying by 65536 converts the integers to the same 16.16 
fixed point values.



Actually, mallocing the font_bbox like this will be a nuisance since I'd
have to be careful to deallocate afterwards.  I might therefore prefer
to use "face->bbox.xMin * 65536" directly in
PSType3_generateOutlineFont:

 else
  {
fprintf(out, "/FontBBox [%d %d %d %d] def\n",
 (int)ti->ttface->bbox->xMin * 65536,
 (int)ti->ttface->bbox->yMin * 65536,
 (int)ti->ttface->bbox->xMax * 65536,
 (int)ti->ttface->bbox->yMax * 65536);
  }

instead of 


 else
  {
FT_BBox *font_bbox = FT_Get_PS_Font_BBox(ti->ttface);
fprintf(out, "/FontBBox [%d %d %d %d] def\n",
 (int)font_bbox->xMin,
 (int)font_bbox->yMin,
 (int)font_bbox->xMax,
 (int)font_bbox->yMax);
  }


I suspect I can remove the (int) cast here too, since the face->bbox
values are already integers, would that be correct?

  

the values are longs. Apart from that, you're correct !

But wait, there is more: the original code is buggy !!
it should really look like the following instead:

   FT_BBox *font_bbox = FT_Get_PS_Font_BBox(ti->ttface);
   fprintf(out, "/FontBBox [%f %f %f %f] def\n",
font_bbox->xMin/65536.0,
font_bbox->yMin/65536.0,
font_bbox->xMax/65536.0,
font_bbox->yMax/65536.0);

that's because, according to the Type 1 spec, the values of  /FontBBox 
are normally expressed
in outline coordinates, as "regular" numbers. the original code produces 
values that are too large

by a factor of 2**16 !!

the consequence of this is that:

- this code generates bogus values for /FontBBox already (they're huuuge)
 and it seems that this has never been spotted before. In other words, it
 probably isn't important at all.

- thus we can use the public face->bbox fields instead, since any loss of
 accuracy due to the integer truncation is far below the radar of anything
 important.

So, the correct, non-buggy code would be:

else
 {
   fprintf(out, "/FontBBox [%ld %ld %ld %ld] def\n",
        ti->ttface->bbox->xMin,
ti->ttface->bbox->yMin * 65536,
ti->ttface->bbox->xMax * 65536,
ti->ttface->bbox->yMax * 65536);
 }

and should be compatible with any release of FT2.

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)

PS: It's sort of funny to see that the original developer went to great 
lengths
 (peeking within the library internals) to get the values it 
needed, without

 being able to use them correctly. Oh well :o)


Thanks for the tips,

Drew


  

Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox)

[david turner]

  
Curious.  I wonder if this explains why Xprint's postscript output files
are so badly up the creek (displaying too large under gv)...
(https://bugs.freedesktop.org/show_bug.cgi?id=5574)


  

It might be related, though it's not certain. I can't tell, really.

  
  
  
So, the correct, non-buggy code would be:

 else
  {
fprintf(out, "/FontBBox [%ld %ld %ld %ld] def\n",
 ti->ttface->bbox->xMin,

  
^^
Is this a typo?  Did you mean
 ti->ttface->bbox->xMin * 65536,
  ??

  
  
 ti->ttface->bbox->yMin * 65536,
 ti->ttface->bbox->xMax * 65536,
 ti->ttface->bbox->yMax * 65536);
  }


  
  
  

No, you don't need to multiply by 65535. the values in ttface->bbox
are already in
outline coordinates, you simply output them as integers into the
Postscript/Type1 stream.

this is consistent with PSType3_createOutlineGlyphs which also outputs
glyph points
in outline coordinates.

  Actually, this particular codepath doesn't appear to be used regularly.
The output files seem to be mostly going through ttf2pt1 instead, which
might be why the problem hasn't been clearly reported. I'll have to
check all the various font bbox usages, I guess.

  
  Hey, don't diss him! Before he got on to it Xprt didn't run at all!
Actually, he was aware of the problem, with the freetype internals, if
not the size misuse:
https://bugs.freedesktop.org/show_bug.cgi?id=603

  

Oh, I'm not dissing anyone, believe me. I'm just finding some irony
between the efforts involved
and the end result. that's all, nothing more.

And believe me, I would have called him a moron if that's what I
thought (which I don't)

Cheers,

- David Turner
- The FreeType Project  (www.freetype.org)



  Thanks,

Drew

  


***Information contained in this email message is confidential and may be privileged, and is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message.*** 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox)

[David Turner]

Drew Parsons a écrit :

>OK. In that case you mean the 65536 needs to removed from the other 3
>coords. That is I want:
>
> else
>  {
>fprintf(out, "/FontBBox [%ld %ld %ld %ld] def\n",
> ti->ttface->bbox->xMin,
> ti->ttface->bbox->yMin,
> ti->ttface->bbox->xMax,
> ti->ttface->bbox->yMax);
>  }
>
>Correct?
>
>  
>
Correct

>That's fine :)  We haven't heard from him for a long time now, so I
>wanted to say something encouraging in his favour.
>
>I'll be able to apply your patch in the next day or two, but I'm not
>sure of a good way to test it.  Do you know of a reliable way to force
>firefox, say, (which prints to Xprint) to select a type 3 font via
>freetype, in such a way that ti->ttheader remains undefined, where ti is
>a struct ft2info (ttheader is read from FT_Get_Sfnt_Table) ?  Well I
>guess I can explicitly set the ttheader to null for testing purposes,
>but I'm not sure about invoking the type 3 font.
>
>  
>
I guess the simpler way is to use a Type 1 font to display the web page
(ttheader will be undefined).

Hope this helps,

- David

>Drew
>
>
>___
>Freetype-devel mailing list
>Freetype-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/freetype-devel
>  
>



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] Re: [ft] Optimizing FT_Init_FreeType

[David Turner]

Atif Gulzar a écrit :

>Is it possible to optimize FT_Init_FreeType to load FT_Library only
>for TrueType fonts? Or it makes no difference?
>
>  
>
What do you mean by "optimizing".

A/ Do you want to make the function faster ?

B/ Do you want to reduce the size of the library, by only compiling
selected modules to support only the TrueType format ?

I doubt that A/ would be interesting.
As for B/, you'll need to change your freetype/config/ftmodule.h to
match the modules you want to include. Look at INSTALL.ANY
in the "docs" folder.

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)

>--
>Best Regards,
>Atif
>
>
>___
>Freetype mailing list
>Freetype@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/freetype
>  
>



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] internal.h

[david turner]

Hi all,

I've just commited a much simpler fix:

  - we define FT2_BUILD_LIBRARY when compiling the library
  - config/ftheader.h only includes the internals when FT2_BUILD_LIBRARY
    is defined.

I've only modified the Make and Jam build systems, anyone would
volunteer
for the other project files ?

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)


Werner LEMBERG a écrit :

  
I was under the impression that the public inclusion of the
internals header folder was a mistake.

If that's the case, then why does freetype/config/ftheader.h include
 ?

  
  
We haven't yet done the transition.

  
  
Do you plan on removing line 632 from ftheader.h,

  
  
Yes, everything related to `internal' should be removed.

Any takers to fix this?  It basically means to do the following.

  . Provide a file, say, ft2.h which defines and includes
FT_INTERNAL_INTERNAL_H, and which also includes ftbuild.h.

  . Fix all source and header files to include ft2.h instead of
ft2build.h.


Werner


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

  


***Information contained in this email message is confidential and may be privileged, and is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message.*** 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] internal.h

[david turner]

Werner LEMBERG a écrit :

  
I've just commited a much simpler fix:

  - we define FT2_BUILD_LIBRARY when compiling the library
  - config/ftheader.h only includes the internals when
FT2_BUILD_LIBRARY is defined.

  
  
This was my first idea too, but I don't think this is the optimal
solution -- now the user still sees a hint that there is an `internal'
directory somewhere (but not installed).  I prefer to avoid this
completely.  I still think that using a separate file which won't get
installed is better for building FreeType itself.


  

Werner, we're not trying to find "optimal" solution at this point. I
don't think that a "hint"
is going to be a problem. Moreover, changing all other files is such a
big work I'm not
willing to do it (too few benefits for the effort).

If you really want to, do it, but please don't waste too much time on
this. 

Cheers,

- David


  Werner

  


***Information contained in this email message is confidential and may be privileged, and is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message.*** 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] More crashes on ARM

[David Turner]

Ahh,

your version of FontConfig is accessing internal fields of FreeType,
and you probably have a version of FreeType installed on your system
that is more recent than the one fontconfig was compiled with.

this also explains the parameter insanity.

try installing fontconfig-2.3.93 or higher, this should fix the problem

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)


Frank Meerkoetter a écrit :

>Hi,
>
>i'm encountering other problems than allready reported with freetype
>on ARM.
>
>A segfault happens in this function:
>
>FT_CALLBACK_DEF( FT_Error )
>  TT_Access_Glyph_Frame( TT_Loader  loader,
> FT_UIntglyph_index,
> FT_ULong   offset,
> FT_UIntbyte_count )
>  {
>FT_Error   error;
>FT_Stream  stream = loader->stream;
>
>/* for non-debug mode */
>FT_UNUSED( glyph_index );
>
>
>FT_TRACE5(( "Glyph %ld\n", glyph_index ));
>
>/* the following line sets the `error' variable through macros! */
>if ( FT_STREAM_SEEK( offset ) || FT_FRAME_ENTER( byte_count ) )
>  return error;
>
>return TT_Err_Ok;
>  }
>
>which is called from (a fontconfig function):
>
>static FT_Error
>GetScriptTags(FT_Face face, FT_ULong tabletag, FT_ULong **stags, FT_UShort
>*script_count)
>{
>[...]
>if ( !stream )
>   return TT_Err_Invalid_Face_Handle;
>
>if (( error = tt_face->goto_table( tt_face, tabletag, stream, 0 ) ))  <
>   return error;
>
>#0  TT_Access_Glyph_Frame (loader=0x40b1219c, glyph_index=264832,
>offset=319872, byte_count=1196445523) at ttgload.c:215
>#1  0x40aec9c0 in GetScriptTags (face=0x4e180, tabletag=1196445523,
>stags=0xbefff830, script_count=0xbefff82c) at fcfreetype.c:2747
>#2  0x40aecd90 in FcFontCapabilities (face=0x4e180) at fcfreetype.c:2835
>#3  0x40ae9d58 in FcFreeTypeQuery (
>file=0x4ae20 "/usr/share/fonts/FreeMonoBoldOblique.ttf", id=0,
>blanks=0x4fec8, count=0xbefff980) at fcfreetype.c:1411
>
>The strange thing is that the parameters seem to be screwed up:
>
>(dgb) frame 1
>#1  0x40aec9c0 in GetScriptTags (face=0x4e180, tabletag=1196445523,
>stags=0xbefff830, script_count=0xbefff82c) at fcfreetype.c:2747
>2747if (( error = tt_face->goto_table( tt_face, tabletag, stream, 0 ) 
>))
>(gdb) p tt_face
>$11 = (TT_Face) 0x4e180
>(gdb) p tabletag
>$12 = 1196445523
>(gdb) p stream
>$13 = (FT_Stream) 0x50188
>(gdb) frame 0
>#0  TT_Access_Glyph_Frame (loader=0x40b1219c, glyph_index=264832,
>offset=319872, byte_count=1196445523) at ttgload.c:215
>215 if ( check && face->postscript.isFixedPitch )
>
>I'm using this gcc:
>arm-linux-gcc --v
>Reading specs from
>/usr/local/uClibc-DaVinci/lib/gcc/arm-linux-uclibc/3.4.3/specs
>Configured with:
>/home/frank/avos_tmp/avx/buildroot/toolchain_build_arm_nofpu/gcc-3.4.3/configure
>--prefix=/usr/local/uClibc-DaVinci --build=i386-pc-linux-gnu
>--host=i386-pc-linux-gnu --target=arm-linux-uclibc --enable-languages=c,c++
>--enable-shared --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld
>--disable-nls --enable-threads --disable-multilib --with-float=soft
>--with-cpu=arm926ejs --enable-cxx-flags=-mcpu=arm926ejs : (reconfigured)
>/home/frank/avos_tmp/avx/buildroot/toolchain_build_arm_nofpu/gcc-3.4.3/configure
>--prefix=/usr/local/uClibc-DaVinci --build=i386-pc-linux-gnu
>--host=i386-pc-linux-gnu --target=arm-linux-uclibc --enable-languages=c,c++
>--enable-shared --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld
>--disable-nls --enable-threads --disable-multilib --with-float=soft
>--with-cpu=arm926ejs --enable-cxx-flags=-mcpu=arm926ejs
>Thread model: posix
>gcc version 3.4.3
>
>All optimizers are disabled.
>
>Any ideas?
>
>Regards,
>  Frank
>
>
>
>___
>Freetype-devel mailing list
>Freetype-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/freetype-devel
>  
>



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] More crashes on ARM

[david turner]

Frank Meerkoetter a écrit :

Quoting david turner <[EMAIL PROTECTED]>:

Hello,


the "cmap->clazz" value is definitely wrong, and there is no way the
charmap was built
with it. In other words, the field has been rewritten after creation of
the charmap !!

Can you re-run the program but set a watch on the fields's memory
address ? This would
help us spot the problem.



FT_CMAP is than used to cast a part of the FT_Face structure
into a FT_CMAP structure (1).


nope, the cast is correct, because the FT_CharMap type is a _pointer_ to a
FT_CharMapRec structure, likewise an FT_CMap is a pointer to a FT_CMapRec
structure, which itself is declared with something like:

 typedef struct FT_CMapRec_
 {
FT_CharMapRec   cmap;
FT_CMap_Classclazz;

 } FT_CMapRec, *FT_CMap;

think about FT_CharMapRec as an abstract "object class", and FT_CMapRec 
as a derived
"class". Clients of the library don't need to know the details of a 
FT_CMapRec, they'll

only be able to read the root fields from the FT_CharMapRec.

By the way, the FT_CMap objects are created in src/base/ftobjs.c 
(FT_CMap_New).


Can you put a watchpoint on the cmap's "clazz" field to detect where it 
is over-written ?

Really, it should give us meaningful information.

Regards,

- David


FT_Get_Next_Char( FT_Face   face,
FT_ULong  charcode,
FT_UInt  *agindex )
  {
FT_ULong  result = 0;
FT_UInt   gindex = 0;


if ( face && face->charmap )
{
  FT_UInt32  code = (FT_UInt32)charcode;
  FT_CMapcmap = FT_CMAP( face->charmap );  // (1)


  gindex = cmap->clazz->char_next( cmap, &code );
  result = ( gindex == 0 ) ? 0 : code;
}

if ( agindex )
  *agindex = gindex;

return result;
  }

(gdb) p *cmap
$32 = {charmap = {face = 0x4bb90, encoding = FT_ENCODING_UNICODE,
platform_id = 0, encoding_id = 3}, clazz = 0x3}

My guess is that clazz should point to 0x505b8 (aka. driver).
Is this correct?

Regards,
  Frank





***
Information contained in this email message is confidential and may be 
privileged, and is intended only for use of the individual or entity named 
above. If the reader of this message is not the intended recipient, or the 
employee or agent responsible to deliver it to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the [EMAIL PROTECTED] and destroy the 
original message.
*** 




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] More crashes on ARM

[david turner]

Sorry, I should have been more accurate.

You should set the watchpoint just after the creation of the FT_CMap
object (this happens in FT_CMap_New in src/base/ftobjs.c). there is
code like this:

   if ( !FT_ALLOC( cmap, clazz->size ) )
   {
 cmap->charmap = *charmap;
 cmap->clazz   = clazz;

 if ( clazz->init )
 {
   error = clazz->init( cmap, init_data );
   if ( error )
 goto Fail;
 }

 /* add it to our list of charmaps */

you should set the watchpoint after the "cmap->clazz = clazz" statement.
So it should be:

- first set a breakpoint at the "cmap->clazz = clazz" statement
 (line 2598 of current CVS)

- when the breakpoint is reached, add a watchpoint to the
 memory location of the 'clazz' field, i.e.:

p &cmap->clazz
0x6734efd4  (or some other value)
watch *(char*)0x6734efd4   (replace with previous value)
c

- repeat each time the first breakpoint is reached (there may be
 several charmaps in the font)

the watchpoint should trigger whenever the memory location is
updated. Note that the watchpoint should make things run very
slowly on some platforms.

Hope this helps,

- David

  



Frank Meerkoetter a écrit :

Quoting david turner <[EMAIL PROTECTED]>:

Hi,


Can you put a watchpoint on the cmap's "clazz" field to detect where it
is over-written ?
Really, it should give us meaningful information.


I'm not sure if i understand correctly what you wan't me to do.
The crash happens directly after cmap becomes available.

FT_EXPORT_DEF( FT_ULong )
  FT_Get_Next_Char( FT_Face   face,
FT_ULong  charcode,
FT_UInt  *agindex )
  {
 [...]
  FT_UInt32  code = (FT_UInt32)charcode;
  FT_CMapcmap = FT_CMAP( face->charmap );   // <---


  gindex = cmap->clazz->char_next( cmap, &code );   // <--- crash
  result = ( gindex == 0 ) ? 0 : code;
}
 [...]
  }

I tried it anyways but had no success.

Breakpoint 2, FT_Get_Next_Char (face=0x4bb90, charcode=0, 
agindex=0xbefff748)

at ftobjs.c:2426
2426FT_ULong  result = 0;
Current language:  auto; currently c
(gdb) n
2427FT_UInt   gindex = 0;
(gdb) n
2430if ( face && face->charmap )
(gdb) n
2432  FT_UInt32  code = (FT_UInt32)charcode;
(gdb) n
2433  FT_CMapcmap = FT_CMAP( face->charmap );
(gdb) n
2436  gindex = cmap->clazz->char_next( cmap, &code );
(gdb) watch cmap->clazz
Watchpoint 3: cmap->clazz
(gdb) c
Continuing.
0x in ?? ()
Cannot access memory at address 0x0


Regards,
   Frank





***
Information contained in this email message is confidential and may be 
privileged, and is intended only for use of the individual or entity named 
above. If the reader of this message is not the intended recipient, or the 
employee or agent responsible to deliver it to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the [EMAIL PROTECTED] and destroy the 
original message.
*** 




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] More crashes on ARM

[david turner]

Hello Frank,

Frank Meerkoetter a écrit :

Hi,

  
(gdb) frame 1

#1  0x409eb304 in FT_Get_Next_Char (face=0x4bb90, charcode=0,
agindex=0xbefff738) at ftobjs.c:2436
2436  gindex = cmap->clazz->char_next( cmap, &code );
(gdb) l
2431{
2432  FT_UInt32  code = (FT_UInt32)charcode;
2433  FT_CMapcmap = FT_CMAP( face->charmap );

(gdb) p *cmap
$10 = {charmap = {face = 0x4bb90, encoding = FT_ENCODING_UNICODE,
platform_id = 0, encoding_id = 3}, clazz = 0x3}
(gdb) p *cmap->clazz
$11 = {size = 0, init = 0, done = 0, char_index = 0, char_next = 0}

Ok, so the cmap->clazz->char_next() function pointer is null.
Any ideas why this could be the case?

  
the "cmap->clazz" value is definitely wrong, and there is no way the 
charmap was built
with it. In other words, the field has been rewritten after creation of 
the charmap !!


Can you re-run the program but set a watch on the fields's memory 
address ? This would

help us spot the problem.

Thanks in advance,

- David



TIA,
  Frank



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

  


***
Information contained in this email message is confidential and may be 
privileged, and is intended only for use of the individual or entity named 
above. If the reader of this message is not the intended recipient, or the 
employee or agent responsible to deliver it to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the [EMAIL PROTECTED] and destroy the 
original message.
*** 




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] How can I do to make the font a little thin?

[david turner]

Hello,

Werner LEMBERG a écrit :

  

  I use simsun.ttf(宋體)，the upper is the image which use FreeType
2.0.9,and the lower is which I want to get.
  

You can pass a negative strength value to the FT_Outline_Embolden.

  
  
Does this work reliably, this is, does it respect a minimum thickness?
Negative values might be worth mentioning then.


  

Just like for positive thickness, it certainly doesn't work reliably
past a certain threshold that heavily depends
on the glyph being processed.

Keep in mind that the emboldening/thinning algorithm doesn't change the
number of points in the glyph, so
certain corner cases like very acute angles or intersections are not
going to be handled properly anyway.

Apart from that, it should work ok for very small negative values, i.e.
values that are much smaller than the
average stem/stroke width within the glyph.

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)



  Werner
  
  

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
  


***Information contained in this email message is confidential and may be privileged, and is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message.*** 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] autofit CJK module

[david turner]

Hello Chia-I Wu,

Even though I hadn't have the time to look at the code, all I can say is 
that I'm very impressed :-)

Congratulations !!

- David

Chia-I Wu a écrit :

Hi all,

I've just committed autofit CJK module.  It is based on akito's autohint
patch.

Here's some screenshots...

with hinting disabled (some people might like this best):
http://homepage.ntu.edu.tw/~b88401031/ming-no-hint.png

with normal hinting:
http://homepage.ntu.edu.tw/~b88401031/ming-normal.png

with light hinting:
http://homepage.ntu.edu.tw/~b88401031/ming-light.png

with CJK module disabled:
http://homepage.ntu.edu.tw/~b88401031/ming-latin.png

The CJK module is currently in experimental stage and is disabled by
default.  If you are interested in helping or want to have a try on it,
it can enabled by #define AF_MOD_CJK in src/autofit/afcjk.c.

  


***
Information contained in this email message is confidential and may be 
privileged, and is intended only for use of the individual or entity named 
above. If the reader of this message is not the intended recipient, or the 
employee or agent responsible to deliver it to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the [EMAIL PROTECTED] and destroy the 
original message.
*** 




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] porting freetype to Texas DSP C55x

[david turner]

Peter M a écrit :

  
  
  
  I
have successfully compiled the freetype 2.1.8 engine on Code Composer
2.21 but I expiriance some memory problems. 
  The problem
seems to be with the malloc, free, realloc  functions.To solve the
issues there must be used the TI specific 
  functions:
   
  -
  Syntax:   addr = MEM_alloc(segid, size,
align);
   
  Parameters:    Int    segid;  /* memory segment identifier */ 
  
      Uns size;    /* block size in MADUs */  
      Uns align;   /* block alignment */
   
  Return
Value: Void    *addr;  /* address of allocated block of memory */
  -
  Syntax:   status = MEM_free(segid, addr,
size);
   
  Parameters:    Int    segid;  /* memory segment identifier */ 
  
      Ptr   addr;   /* block address pointer */  
      Uns size;    /* block length in MADUs*/
   
  Return
Value:     Bool status; /* TRUE if successful */
  -
  Syntax:   MEM_redefine(segid, base, length);
  Parameters:    Int    segid;  /* segment to redefine */  
      Ptr   base;   /* base address of new block */ 
  
      Uns length; /* length (in MADUs) of new block */
   
  Return
Value: Void
  -
   
   
  My
questions are:
  - Doze someone use freetype on a Texas c55x platform?

I really don't know.

  
  
  - How match RAM dose it use?

It really depends on the font being used, some configuration options,
and even
the version of the font engine you're using. Better test it yourself.


  
  - How to rewrite or change the memory object to make it
work?
   

for an embedded system, the easiest way is to modify the file
src/base/ftsystem.c
you should be able to use the "user" field of the FT_Memory object to
store your
segment id. the work would be to:

- change "ft_alloc", "ft_realloc" and "ft_free" to use the TI functions
- change "FT_New_Memory" to allocate the initial FT_Memory object
  either statically, or with the TI functions as well.

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)


  
   
  Tanks
in advance 
   Peter
  

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
  


***Information contained in this email message is confidential and may be privileged, and is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message.*** 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] On the impact of installing the next FreeType release on a typical Unix distribution

[david turner]

Hello everyone,

I'd like to re-activate the debate regarding how we're going to 
install/name the

next FreeType release in order to avoid some of the ugly problems discussed
previously.

As far as I have understood:

* Installing the next release as "libfreetype6.so" is going to break any 
rogue client.
 Even if we provide patches for the most important ones, correct 
installation remains
 probably problematic for a typical user. and we don't control what has 
been compiled/

 installed locally anyway.

* Installing the next release as "libfreetype7.so" is not going to solve 
the problem either,

 because:

 - some programs are going to be linked with both libfreetype6 and 
libfreetype7


 - due to the way ELF dynamic linking works, erratic code paths will be 
taken,

   resulting in incorrect behaviour or even crashes

 - some of this can be avoided if we avoid same-named functions in 
libfreetype6

   and libfreetype7 (e.g. using the "FT3_" prefix, instead of "FT_"),
   but there are still cases where a program obtains a FT_Face object
   through libfreetype7, then call an internal function in libfreetype6,
   later resulting in a crash.

I am a Linux user too, and believe that this behaviour is simply 
*unacceptable*.

We thus need a different way to solve this. Given that rogue clients do:

- call internal functions from libfreetype6 that were mistakenly exposed
  by our build system until now

- also peek/poke directly at internal fields of some FreeType objects


we must, and only can, ensure *binary* compatibility by the following:

 - first of all, install the next release as libfreetype6. RIGHT !!

 - provide the previous internal functions, or some *stubs*, in the
   new libfreetype6 library (but not from the installed headers !)

 - ensuring that the internal layout of FreeType objects in the new
   libfreetype6 is *compatible* with the ones in the old libfreetype6
   (at least recent releases, since these have changed already without
   too much problems).

Note that our goal is to prevent *crashes* from already installed 
applications
and libraries, *not* to ensure 100% correct behaviour. In other words, 
it is ok to
"cheat" by ignoring some request made through these "exposed" internal 
functions

(e.g. returning a not-implemented-error), or fill internal fields with bogus
values. it will depend on context and relative importance of each point.

And of course, the internal headers will _not_ be installed anymore, 
which means

that the source code of any rogue client shall be updated anyway.

to achieve this, we must:

- immediately freeze development on the current code base

- perform a massive diff between the content of "include/freetype/internal"
 between the 2.1.10 release and the current CVS, and study how we can stub
 each type, field and function defined here.

- do the required modifications, encapsulating each of the "old" internals
 in a configuration macro (e.g. FT_CONFIG_OPTION_OLD_INTERNALS)

- test, test, test, on existing installations. Preferabbly ones with old 
releases

 of fontconfig/libXft/Pango/Qt/etc...

- release something stable as early as possible.


Any comments ?

- David Turner
- The FreeType Project  (www.freetype.org)

***
Information contained in this email message is confidential and may be 
privileged, and is intended only for use of the individual or entity named 
above. If the reader of this message is not the intended recipient, or the 
employee or agent responsible to deliver it to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the [EMAIL PROTECTED] and destroy the 
original message.
*** 




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] internal differences between 2.1.10 and current CVS

[david turner]

Hello again,

following my recent message regarding internals and the safe installation
of the next FreeType release, I've performed the "big diff" to see what 
should

be taken care of.

See the details at the end of this message. It seems that this is going 
to be
rather easy, except for the changes in SFNT_ServiceRec which were quite 
drastic,

and which are very likely to be used by rogue clients.

Another point that is not listed, is that all functions that are listed as
FT_BASE are no longer exported by our build system.

I'll try to start fixing things tonight in the CVS. In the meantime, I'd be
happy to read your concerns and ideas.

Regards,

- David


differences from the headers of FreeType 2.1.10 to current CVS.
All paths are relative to include/freetype:

cache/ftccache.h:
 'ftc_node_destroy' was renamed to 'FTC_Node_Destroy'

cache/ftheader.h:
  FT_GX_VALIDATE_H was added
 
config/ftoption.h:

  TT_CONFIG_OPTION_BDF added
  AF_CONFIG_OPTION_CJK added
  FT_OPTIMIZE_MEMORY added
  FT_STRICT_ALIASING added

config/ftstdlib.h:
 ft_memchr added

freetype.h:
 FT_FACE_FLAG_HINTER added
 FT_Size_Request_Type, FT_Size_Request, FT_Request_Size, FT_Select_Size 
added

 FT_Get_Track_Kerning added

internal/ftcalc.h:
 FT_Sqrt32 removed

internal/ftdebug.h:
 FT_Trace_Get_Count, FT_Trace_Get_Name, FT_Message and FT_Panic were
 FT_EXPORT() and are now FT_BASE() and thus no longer exported

internal/ftdriver.h:
 FT_Size_ResetPointsFunc and FT_Size_ResetPixelsFunc are replaced
 by FT_Size_RequestFunc and FT_Size_SelectFunc, which have different
 signatures and usage. This impacts some fields in FT_Driver_ClassRec,
 namely:

   'set_char_sizes'  => 'request_size'
   'set_pixel_sizes' => 'select_size'

 the layout of other fields is untouched

internal/ftgloader.h:
 new macros were introduced, no impact on rogue clients

internal/ftmemory.h:
 the signature of FT_Alloc, FT_QAlloc, FT_Realloc, FT_QRealloc
 and FT_Free is changed when FT_STRICT_ALIASING is defined in
 config/ftoption.h !

 best solution: rename the functions (e.g. ft_mem_alloc, ft_mem_qalloc, 
etc..)

 and provide stubs with the old names (e.g. "FT_Alloc", "FT_QAlloc") that
 implement the old signature

internal/ftobjs.h:
 two new fields at the start of FT_Face_InternalRec, named
 'max_points' and 'max_contours'

 obvious solution: move them to the end of the structure

 FT_New_Memory was FT_EXPORT and is now FT_BASE, i.e. no longer
 exported

 same for FT_Done_Memory !

internal/ftstream.h:
 FT_Stream_Open was FT_EXPORT and is now FT_BASE

internal/psaux.h:
 PSAux_ServiceRec has a new field added in its middle, named
 'afm_parser_funcs'.

 obvious solution: move it to the end of the structure

internal/services/svpscmap.h:
 IMPORTANT NOTE: The probability that a rogue client uses this header
 file is _extremely_ low !!

 the 'unicode' field of PS_UniMap changed from FT_UInt to FT_UInt32
 (shouldn't be a problem on Unix)

 PS_UnicodesRec has a new starting field => since this is a
 FT_CMapRec, is it possible to move it to the end of the structure
 safely ??

 PS_Unicodes_InitFunc changed its signature -> impact on the
 'unicodes_init' field of PsCMaps service structure

internal/sfnt.h:
 **VERY BAD**

 changes here have been extremely drastic, more details will follow
 but we need to be very careful. The types defined here are *very*
 likely to be used by rogue clients

 **MORE DETAILS LATER**
  
  
internal/t1types.h:

 the 'unicode_map' field of T1_FaceRec was a pointer, and is now
 a structure, moving all fields below it.

 => revert the field to a pointer, even if it is to a structure
located to the end of T1_FaceRec instead

internal/tttypes.h:
 a new field named 'max_components' was added in the middle of
 TT_FaceRec => move it to the end of the structure

 when FT_OPTIMIZE_MEMORY is defined, this adds new fields within
 the structure => move them to the end as well

 same for TT_CONFIG_OPTION_BDF and 'bdf' field

 
 




***
Information contained in this email message is confidential and may be 
privileged, and is intended only for use of the individual or entity named 
above. If the reader of this message is not the intended recipient, or the 
employee or agent responsible to deliver it to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the [EMAIL PROTECTED] and destroy the 
original message.
*** 




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] On the impact of installing the next FreeType release on a typical Unix distribution

[david turner]

Ilya Konstantinov a écrit :

   but there are still cases where a program obtains a FT_Face object
   through libfreetype7, then call an internal function in libfreetype6, 
You're talking about libraries which accept/offer FreeType structures 
in their public APIs, e.g. (just an example -- I never checked) Pango 
exposes a PangoFont's underlying FT_Face via public API function  such as:

FT_Face* pango_font_get_freetype_face(PangoFont* font)
?
Exactly, but I was really thinking about FontConfig here. Note also that 
this is a perfectly acceptable thing to do.


Regards,

- David

***
Information contained in this email message is confidential and may be 
privileged, and is intended only for use of the individual or entity named 
above. If the reader of this message is not the intended recipient, or the 
employee or agent responsible to deliver it to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the [EMAIL PROTECTED] and destroy the 
original message.
*** 




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] On the impact of installing the next FreeType release on a typical Unix distribution

[David Turner]

Hi Werner,

Werner LEMBERG a écrit :

>Sounds good.  We should mention in the docs that these steps are
>performed only *once*, and that we are not going to maintain those
>hacks.
>
>  
>
I think that we'll need to maintain them for quite some time, between 6
and 18 months,
to ensure that everybody upgrades their programs adequately. After that,
we'll probably
disable them by default, but provide a "--enable-old-internals"
configure option, just in
case.

in other words, the hacks are going to stay in the sources for a very
long time :-)

- David Turner
- The FreeType Project  (www.freetype.org)

>Werner
>
>
>___
>Freetype-devel mailing list
>Freetype-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/freetype-devel
>  
>



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] internal differences between 2.1.10 and current CVS

[david turner]

Werner LEMBERG a écrit :

following my recent message regarding internals and the safe
installation of the next FreeType release, I've performed the "big
diff" to see what should be taken care of.  [...]



Thanks for the list.  Due to lack of time I won't actively implement
something.  Chia-Yi and David, please do it!  As usual, I'll try to
revise the patches afterwards.


Werner

  
Don't worry, I've been hacking on the code quite a lot last night, I 
hope to commit something stable
tonight as well. We'll then need testers with "old" distributions (e.g. 
Debian Woody) to see if everything

works correctly.

Regards,

- David

***
Information contained in this email message is confidential and may be 
privileged, and is intended only for use of the individual or entity named 
above. If the reader of this message is not the intended recipient, or the 
employee or agent responsible to deliver it to the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this communication 
in error, please immediately notify the [EMAIL PROTECTED] and destroy the 
original message.
*** 




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel