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: 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: 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: 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: 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 --build-dir=DIR is used,
+# in which case we 

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

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=both'])
+
+#
+# Rules to compile the FreeType 2 library itself
+#
+
+# Apparently mes

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

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

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 
 scripts/extract_libtool_version.py  |  87 
 scripts/generate_referen

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 automatically
+   * determined at com

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.  There are three ways to use
+   * this file to build 

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: [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]

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,27 +835,27 @@
 
 /* we ex

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();
> 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 (always near the type).

void foo(int* input_ptr, i

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_VERSION >= 730 )
 #pragma set woff 3505
 #  en

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 --git a/src/psaux/psstack.h b/src/psaux/

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]

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_CHECKING([whether cpp computation of bit length in ftco

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: 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 most of the Makefiles / Jamfiles / CMakefiles from a single
&g

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 = [(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: [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_INIT([FreeType], [@VERSION

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"
 _ACEOF
 echo >> 

[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 
 #define FT_UINT_MAX  UINT_MAX
 #defi

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
>

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=shuffle_epi32=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: 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: [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: [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]

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: 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=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: 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=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: [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: [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_VALIDATE_H
 
   /* the following four header files shou

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

[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

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

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

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

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: [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,  );
 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" : ""));
+

[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,  );
 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, file_index;
 unsigned int  id;
 char  filename[1

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
>

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: [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 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: 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=project=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=CMAKE_CXX_STANDARD=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 the embedded world. While we probably no longer
> care
> > > about developers using DOS and OS/2 s

[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
+# is currently supported 

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
> source of truth (exact format to be defined), at least t

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
>

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: [ft-devel] loss of precision in FT_Outline_Decompose

[David Turner]

2013/7/16 Luiz Henrique de Figueiredo l...@impa.br

 At two places in FT_Outline_Decompose there is a division by 2 that
 loses one bit of precision. A client walking manually through the
 contours of a glyph and mapping the control points to floats by
 dividing by 64 and then doing any required midpoint calculation for
 conics will get different results than one calling
 FT_Outline_Decompose.

 That is not very surprising, fixed-point and floating-point algorithms do
not generate the exact same results in the general case :-)


 I was doing some tests generating outlines of fonts and come upon this
 because the .eps I generated were slightly different but gave
 apparently the same image.

 Is this loss of precision a problem or will it never be seen in an image?

 It's a slight loss of precision for the sake of performance. As pointed
out by Werner, the actual outline coordinates are scaled by either 64 or
1024, depending on context, to ensure this is not noticeable.


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

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

[ft-devel] (no subject)

[David Turner]

Hello,

Here's a small set of patches that slightly improve the performance of
FreeType when compiled for ARM and x86_64 with GCC. I also checked that it
doesn't negatively affect x86 performance.

On ARM, loading glyphs is about 3% faster, and rendering gray bitmaps is 6%
faster.
On x86_64, loading glyphs is 6% faster, and rendering gray bitmaps is 2.5%
faster.

The optimizations were found by inspecting the generated machine code in
hot spots.

Let me know if you find any issue.

- David

PS: Everything measured with:

./ftbench -p -t 5 -s 14 -f 0008 Arial.ttf

(0008 is FT_LOAD_NO_BITMAP)

ARM:


CFLAGS=-O2 -fomit-frame-pointer -march=armv7-a -mthumb ./configure
--disable-shared --without-zlib --without-png --without-bzip2
--host=arm-linux-androideabi

Before:
  Load  34.287 us/op
  Load_Advances (Normal)34.317 us/op
  Load_Advances (Fast)  0.176 us/op
  Render23.544 us/op
  Get_Glyph 6.661 us/op
  Get_CBox  1.957 us/op
  Get_Char_Index0.261 us/op
  Iterate CMap  121.696 us/op
  New_Face  115.143 us/op
  Embolden  1.428 us/op
  Get_BBox  3.313 us/op

After:
  Load  33.358 us/op
  Load_Advances (Normal)33.330 us/op
  Load_Advances (Fast)  0.176 us/op
  Render22.079 us/op
  Get_Glyph 6.494 us/op
  Get_CBox  1.937 us/op
  Get_Char_Index0.232 us/op
  Iterate CMap  120.793 us/op
  New_Face  115.759 us/op
  Embolden  1.450 us/op
  Get_BBox  3.384 us/op

x86_64:
===

CFLAGS=-O2 -fomit-frame-pointer ./configure --disable-shared
--without-zlib --without-png --without-bzip2

Before:
  Load  4.890 us/op
  Load_Advances (Normal)4.849 us/op
  Load_Advances (Fast)  0.027 us/op
  Render2.813 us/op
  Get_Glyph 0.473 us/op
  Get_CBox  0.076 us/op
  Get_Char_Index0.024 us/op
  Iterate CMap  13.982 us/op
  New_Face  12.341 us/op
  Embolden  0.027 us/op
  Get_BBox  0.303 us/op

After:
  Load  4.617 us/op
  Load_Advances (Normal)4.537 us/op
  Load_Advances (Fast)  0.028 us/op
  Render2.743 us/op
  Get_Glyph 0.441 us/op
  Get_CBox  0.076 us/op
  Get_Char_Index0.023 us/op
  Iterate CMap  13.508 us/op
  New_Face  12.298 us/op
  Embolden  0.027 us/op
  Get_BBox  0.296 us/op

x86:


CFLAGS=-O2 -fomit-frame-pointer -m32 LDFLAGS=-m32 ./configure
--disable-shared --without-zlib --without-png --without-bzip2

Before:
  Load  4.973 us/op
  Load_Advances (Normal)4.910 us/op
  Load_Advances (Fast)  0.023 us/op
  Render3.140 us/op
  Get_Glyph 0.641 us/op
  Get_CBox  0.243 us/op
  Get_Char_Index0.027 us/op
  Iterate CMap  15.303 us/op
  New_Face  13.041 us/op
  Embolden  0.167 us/op
  Get_BBox  0.527 us/op

After:
  Load  4.930 us/op
  Load_Advances (Normal)4.895 us/op
  Load_Advances (Fast)  0.023 us/op
  Render3.131 us/op
  Get_Glyph 0.620 us/op
  Get_CBox  0.237 us/op
  Get_Char_Index0.027 us/op
  Iterate CMap  15.051 us/op
  New_Face  13.133 us/op
  Embolden  0.163 us/op
  Get_BBox  0.524 us/op


0001-arm-Enable-FT_MulFix_arm-for-thumb2-compilation.patch
Description: Binary data


0002-x86_64-Optimize-FT_MulFix-for-x86_64-GCC-builds.patch
Description: Binary data


0003-arm-x86-x86_64-Optimized-TT_MulFix14-TT_DivFix14.patch
Description: Binary data


0004-arm-Improve-gray-rasterizer-performance.patch
Description: Binary data
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] ttfautohint - render issue with composites on OSX CHrome

[David Turner]

2013/3/27 Werner LEMBERG w...@gnu.org


  It's an issue when ttfautohint is using dummy glyphs as a workaround
  for hinting composite glyphs.  Untill know it was assumed that it
  was a problem free workaround.  My report shows that it seems to be
  creating problems on OSX Chrome.  Of course it could be a bug caused
  by something that OSX Chrome specifically does different to other
  browsers, and i will report it there too.

 Chrome uses FreeType, right?  In case this is true, I really wonder
 what's going on...

 Chrome doesn't necessarily use FreeType, it depends on the platform. More
specifically, it uses the Skia library that has several 'font host'
implementations depending on the platform it runs on. On OS X, I believe it
uses platform-specific APIs to render text / glyphs.


  How can i best help you with this? i have a mac and use Chrome :-/

 Thanks for your offer.  I think we need assistance from the Chrome
 developers.  Is there a bug report already for this issue?


 Werner

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

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

Re: [ft-devel] heads-up: TrueType height computation has been fixed

[David Turner]

2013/1/23 Werner LEMBERG w...@gnu.org


 Folks,


 just a heads-up which might influence applications: I've just fixed a
 bug in the TrueType handler to correctly compute the `height' value of
 the `FT_Face' structure.  Up to now, the following was done:

   ascender_int = round(ascender_26.6);
   descender_int = round(descender_26.6);
   height_int = round(height_26.6);

 This has been replaced with

   ascender_int = round(ascender_26.6);
   descender_int = round(descender_26.6);
   height_int = ascender_int - descender_int;


This seems to assume that height_26.6 was always ascender_26.6 + -
descender_26.6. I'm not sure this is always true. IIRC, there are fonts
where the line height is actually different from ascender - descender, they
would be affected by this patch in surprising ways.

Unless I'm missing something (which is entirely possible, and I've not
looked at the patch details yet).

If that so, maybe add some code to deal with this, e.g.:

  if (height_26.6 == ascender_26.6 - descender_26.6) {
height_int = ascender_int - descender_int;
  } else {
// something else, to be defined :-)
  }



 to be in sync with Windows.

 I wonder whether we should do the same for non-TrueType fonts.  I think
 yes, but please comment!


 Werner

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

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

[ft-devel] Fix for C++ compilation

[David Turner]

My recent patch to reformat the subpixel code broke C++ compilation, sorry
about that.

However, here's a fix

It turns out that C++ doesn't allow you to declare (and not define) a
static constant.

- David


0001-Fix-C-compilation.patch
Description: Binary data
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Testing PIC mode code (Re: Fixes for some compile and link errors when using FT_CONFIG_OPTION_PIC)

[David Turner]

Forgot to reply on-list, sorry

2012/2/1 David Turner da...@freetype.org



 2012/1/28 suzuki toshiya mpsuz...@hiroshima-u.ac.jp


 Also I've checked ANSI C (C89) spec draft, available on:
 http://flash-gordon.me.uk/ansi.c.txt
 In the description of sizeof operator, I could not find explicit
 permission to pass the variable (not the type) to sizeof operator,


 The sizeof operator can take a unary expression as its argument, which
 includes simple variable designators.
 The only constraint is that the expression must have a known type at
 compile time, so sizeof varname is completely legal.
 The parenthesis are only needed for sizeof (typename)


 but I could find examples doing such:

 extern void *alloc();
 double *dp = alloc(sizeof *dp);

 or

 sizeof array / sizeof array[0]

 I think prohibiting the first example and rewriting it as
 double* dp = alloc(sizeof(double)); does not make the maintainability
 worse,


 It does make maintainability worse because it prevents handy macros like
 FT_NEW or FT_NEW_ARRAY from working properly.
 Besides, it's not forbidden in any way by the standard.


 but prohibiting the second example will make the maintainability
 worse. The second example is refused by BREW official compiler?

 The second example is refused because the first sizeof operator gets the
 expression array / sizeof array[0] which isn't valid.
 It should work if written as:

 (sizeof array)/(sizeof array[0])
 or
 sizeof(array)/sizeof(array[0])


 I think the second example is quite widely used, and some consideration
 is needed.

 I understand that many companies in embedded system market are selling
 stubborn SDKs whose compilers are not conforming to C89 and the companies
 had already lost how to maintain their SDKs, but I don't know appropriate
  well-defined subset of C89 to modify FreeType2 to fit it.

 Regards,
 mpsuzuki





  Regarding testing of the PIC mode, yes you can test it on Linux even
  though PIC isn't normally required there. The linker that has issues
  with strings and array initializations like in ftobjs.c is for the Brew
  platform.
 
  Thanks. I heard that BREW's official SDK is based on ARM RVCT
  compiler in Microsoft Visual C++ IDE. I don't have MSVC IDE,
  but I will check if there is any free-charged version of RVCT
  compiler.
 
  Regards,
  mpsuzuki
 
  On Tue, 17 Jan 2012 07:54:40 +0100, suzuki toshiya
  mpsuz...@hiroshima-u.ac.jp wrote:
 
  During the overhaul for PIC build, I found that cache subsystem
  of FreeType2 is not ready for PIC build, thus the demo programs
  doing rasterization (e.g. ftview, ftbench) cannot be built.
  Thus I can check if the code is compilable, but cannot check
  if the code is working. Maybe most expected direction is the
  porting of the cache subsystem for PIC build (even if there is
  no real user of it on embedded system), but extending some demo
  programs for FreeType2 without cache subsystem would be easier
  first step.
 
  # I assume FreeType2 built in PIC mode will work in the operating
  # system that PIC mode is NOT required (e.g. Linux). If it's
  # misunderstanding, please let me know.
 
  Any comments?
 
  Regards,
  mpsuzuki
 
  suzuki toshiya wrote:
  Dear Erik,
 
  I have made some overhaul for PIC build, and, your patch to
  modify resource fork support for PIC build is applied with
  some coding style changing. Please check whether GIT head
  works on your platform.
 
  BTW,
 
  diff --git a/src/base/ftobjs.c b/src/base/ftobjs.c
  index 1a5a327..fc687f5 100644
  --- a/src/base/ftobjs.c
  +++ b/src/base/ftobjs.c
  @@ -4533,7 +4533,9 @@
*/
   {
 FT_UInt  m, n;
  -  const char*  driver_name[] = { type42, NULL };
  +  const char*  driver_name[2];
  + driver_name[0] = type42;
  + driver_name[1] = NULL;
 
 
 for ( m = 0;
 
  is not committed yet, because I want to know which linker complains
  about such initialization. If possible, please let me know 1 example
  to be documented in ChangeLog. I'm not saying there should not be
  such linker, just I want to know 1 example, for good documentation.
  Sorry for troubling you.
 
  Regards,
  mpsuzuki
 
  suzuki toshiya wrote:
  Dear Erik,
 
  Sorry for your trouble and thank you for providing a patch,
  I will check it in this weekend. Please give me a few days.
 
  Regards,
  mpsuzuki
 
  Werner LEMBERG wrote:
  The commits in question are both dealing with compilation of
  'complex' structures and static globals.
  Thanks for the patch.  Toshiya-san, can you have a look and take
 care
  of it, please?
 
 
  Werner
 
 
 
  ___
  Freetype-devel mailing list
  Freetype-devel@nongnu.org
  https://lists.nongnu.org/mailman/listinfo/freetype-devel


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

Re: [ft-devel] Testing PIC mode code (Re: Fixes for some compile and link errors when using FT_CONFIG_OPTION_PIC)

[David Turner]

2012/1/17 Erik Dahlstrom e...@opera.com

 Hi,
 after I submitted my first patches I found a bunch of other PIC issues. I
 see that you have fixed some of the same things I found too, mostly missing
 includes to the various error-headerfiles, and a bunch of unitialized
 variables for clazz and the various PIC modules, and pointer dereferences
 of the same.

 One example of that, there are plenty more:

 diff --git a/modules/libfreetype/include/**freetype/internal/ftdriver.h
 b/modules/libfreetype/include/**freetype/internal/ftdriver.h
 index bbb9ddd..333f908 100644
 --- a/modules/libfreetype/include/**freetype/internal/ftdriver.h
 +++ b/modules/libfreetype/include/**freetype/internal/ftdriver.h
 @@ -366,11 +366,11 @@ FT_BEGIN_HEADER
   FT_Create_Class_##class_( FT_Librarylibrary,
   \
 FT_Module_Class**  output_class )
\
   {
\
 -FT_Driver_Class  clazz;
\
 +FT_Driver_Class  clazz = NULL;
 \
 FT_Error error;
\
 FT_Memorymemory = library-memory;
   \

\
 -if ( FT_ALLOC( clazz, sizeof(*clazz) ) )
 \
 +if ( FT_ALLOC( clazz, sizeof(FT_Driver_ClassRec) ) )
 \
   return error;
\

\
 error = class_##_pic_init( library );
\

 I think It would be simpler to fix FT_ALLOC() to perform a dummy NULL
assignment on the first parameter for this specific compiler.



 If you prefer I can send another patch with those changes.

 Regarding testing of the PIC mode, yes you can test it on Linux even
 though PIC isn't normally required there. The linker that has issues with
 strings and array initializations like in ftobjs.c is for the Brew platform.



 On Tue, 17 Jan 2012 07:54:40 +0100, suzuki toshiya 
 mpsuz...@hiroshima-u.ac.jp wrote:

  During the overhaul for PIC build, I found that cache subsystem
 of FreeType2 is not ready for PIC build, thus the demo programs
 doing rasterization (e.g. ftview, ftbench) cannot be built.
 Thus I can check if the code is compilable, but cannot check
 if the code is working. Maybe most expected direction is the
 porting of the cache subsystem for PIC build (even if there is
 no real user of it on embedded system), but extending some demo
 programs for FreeType2 without cache subsystem would be easier
 first step.

 # I assume FreeType2 built in PIC mode will work in the operating
 # system that PIC mode is NOT required (e.g. Linux). If it's
 # misunderstanding, please let me know.

 Any comments?

 Regards,
 mpsuzuki

 suzuki toshiya wrote:

 Dear Erik,

 I have made some overhaul for PIC build, and, your patch to
 modify resource fork support for PIC build is applied with
 some coding style changing. Please check whether GIT head
 works on your platform.

 BTW,

 diff --git a/src/base/ftobjs.c b/src/base/ftobjs.c
 index 1a5a327..fc687f5 100644
 --- a/src/base/ftobjs.c
 +++ b/src/base/ftobjs.c
 @@ -4533,7 +4533,9 @@
  */
 {
   FT_UInt  m, n;
 -  const char*  driver_name[] = { type42, NULL };
 +  const char*  driver_name[2];
 + driver_name[0] = type42;
 + driver_name[1] = NULL;


   for ( m = 0;

 is not committed yet, because I want to know which linker complains
 about such initialization. If possible, please let me know 1 example
 to be documented in ChangeLog. I'm not saying there should not be
 such linker, just I want to know 1 example, for good documentation.
 Sorry for troubling you.

 Regards,
 mpsuzuki

 suzuki toshiya wrote:

 Dear Erik,

 Sorry for your trouble and thank you for providing a patch,
 I will check it in this weekend. Please give me a few days.

 Regards,
 mpsuzuki

 Werner LEMBERG wrote:

 The commits in question are both dealing with compilation of
 'complex' structures and static globals.

 Thanks for the patch.  Toshiya-san, can you have a look and take care
 of it, please?


Werner



 --
 Erik Dahlstrom, Core Technology Developer, Opera Software
 Co-Chair, W3C SVG Working Group
 Personal blog: http://my.opera.com/macdev_ed


 __**_
 Freetype-devel mailing list
 Freetype-devel@nongnu.org
 https://lists.nongnu.org/**mailman/listinfo/freetype-**develhttps://lists.nongnu.org/mailman/listinfo/freetype-devel

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

Re: [ft-devel] FreeType License and patents

[David Turner]

Hello Alexei,

On Thu, Jan 19, 2012 at 4:08 AM, Alexei Podtelezhnikov
apodt...@gmail.comwrote:

 On Fri, Jan 13, 2012 at 2:13 PM, Werner LEMBERG w...@gnu.org wrote:
   3. Grant of Patent License.
 
  

 Do freetype authors hold or have they filed for a patent? Don't you
 need it first before granting any patent license? This is one strange
 and curious discussion thread without a patent at hand. There is a
 difference between patent and copyright. Patent means royalties,
 copyright does not.


Patents mean a bit more than royalties, but let's not digress.

The point of a patent clause in the software license is *to protect users
and distributors* of the software, not authors.

More specifically, an Apache 2.0 -style clause only protects from
sub-marine patents being contributed to a project, and being asserted later.
(for example, after the company who submitted the related contribution went
through a change of ownership).

That doesn't protect from random third-parties who never contributed
anything from claiming infringement from patent they own, but *absolutely
nothing* can protect against that, even if you release your code under the
public domain.

But at least, when you see such a patent clause in the license, you have a
minimal guarantee that you won't get easily attacked in the future by the
original authors, independently on the way you use the software (which may
or may not align with their current or future personal/business goals).

That's the main reason why so many major open source licenses have added
them over time: Apache, GPL and MPL. Think about it, even the FSF thinks
they're a good thing.

That's why I think adding such a clause is a good thing for the project's
users.



 There is no need to change a license. I do not think so.

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

Re: [ft-devel] [ft] FreeType License and patents

[David Turner]

Hello,

Just to make it clear, I'm too in favor of adding an Apache2-like patent
clause to the license.
And for the sake of full-disclosure, my employer does releases quite a
large amount http://source.android.com of Apache-2 licensed code.

On Fri, Jan 13, 2012 at 8:34 PM, Eric Rannaud eric.rann...@gmail.comwrote:

 On Fri, Jan 13, 2012 at 11:16 AM, Dave Crossland d...@lab6.com wrote:
  On 13 January 2012 20:13, Werner LEMBERG w...@gnu.org wrote:
  I would like to add something similar, with the exception that code
  especially marked as patented within the FreeType source code is not
  covered.
 
  Comments?
 
  Why not just switch to Apache?

 Switching to Apache2 is an interesting possibility, but such a license
change means getting the approval of all contributors to the project. Given
FreeType's age, that might be challenging and/or time-consuming (e.g. what
are the chances that all email addresses in our copyright disclaimers are
still valid).

An easier approach would be to ask for all future contributions to be
covered by FreeType License 1.1, which would be equal to the actual one,
plus a patent clause. This allows us to keep the existing code just as-is
in case we don't have a contact or agreement with the original author of
some piece of code. Also makes explaining the change easier.

We can still continue to contact contributors to ask them their
opinion/agreement on switching their existing code to Apache 2 though, and
maybe later switch to it.


 Apache2 is not compatible with GPLv2 notably because of this
 particular patent clause (that's the general agreement anyway -- some
 see GPLv2 as already having an equivalent clause, albeit less
 explicit). Apache2 is compatible with GPLv3, however.


GPL is already not an issue since the original FreeType license is not
compatible either (due to the credit clause). That's why we dual-license
the library by the way. I don't see why anything would change with the
proposed license update.


 So you want to be careful adding that kind of exception, you may
 create a number of new license compatibility questions.

 If you want such a patent grant clause, you might as well have
 Freetype released under Apache2 and continue to make it available
 under GPLv2. At least license compatibility is then clear.

 However, by switching to Apache2, or by adding such a clause, you will
 likely make Freetype harder to use for some projects that may have
 liked the current license better. (e.g. OpenBSD: they don't like
 Apache2, and maybe would reject Freetype license + patent grant.)


I'm ok with OpenBSD rejecting an updated license (you can't please all
people in the world after all). I still can't find any official reason why
they're opposed to Apache2, but they can still use the existing FreeType
code and back-port security fixes manually if they want. They've been doing
it with Apache 1 for years and nobody's been greatly impacted by it as far
as I understand.

It might be a good thing to bump the library's minor version number for the
license change to make this back-tracking easier.

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

Re: [ft-devel] [ft] FreeType License and patents

[David Turner]

On Tue, Jan 17, 2012 at 3:53 PM, Dave Crossland d...@lab6.com wrote:


 But its GPLv2 only :-(

 Apache 2 is GPLv3 compatible.

 So I'd suggest either using Apache 2, or using FreeType License 1.1
 and GPLv2-or-later.


Apache 2 or GPLv2-or-later have the same problems: they require changing
the license of existing code, i.e. contacting all copyright holders for
permission, getting permissions from all of them or rewrite their
contribution from scratch.

I think it's easier/faster/simpler to start adding a new clause to cover
any future contribution. The resulting package in its entirety would be
covered by the 1.1 license, because the 1.0 one doesn't mandate
restrictions on what you can do with the rest of the code (unlike the GPL).

One option doesn't prevent the other, they just require different time
frames.


 --
 Cheers
 Dave

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

Re: [ft-devel] Determining Upper Bound of memory consumption for a system using FT cache subsystem

[David Turner]

I think you are misunderstood. The cache subsystem memory bounding only
accounts for the objects stored in the cache itself (i.e. glyph outlines,
bitmaps, charmaps), but not the FT_Face and FT_Size objects themselves.
Iirc, you can purge the latter if you want without purging the cache objects
themselves.

Trying to memory-bound the FT_Face and FT_Size objects themselves is pretty
impossible due to the nature of the font format we're trying to support.

Also, the memory bounding does not account for malloc-specific memory block
padding and other stuff like that, so even getting an absolutely correct
estimates of all the bytes consumed is impossible.

Hope this helps.

- David Turner

2010/3/10 Maggy Anastasia maggymaggyma...@gmail.com

 Dear FreeType Developers,

 I have a few questions regarding freetype memory consumption upper bound; I
 am using Freetyper version 2.3.7

 (1) static array: currently we know that all memory consumption by freetype
 is done through malloc calls and its variants. However, is there any other
 memory used in freetype, such as global arrays, which are used for memory
 allocation? If so, do they need any kind of configuration?

 (2) Is there a way for determining the upper bound of memory usage for
 freetype when cache is being used. I know that we can set the upper bound
 for cache nodes (glyph image, cmap, sbitchace, etc.), but is there a way to
 determine the memory consumption for FT_FACE and FT_SIZE? From what I have
 seen regarding this, we can only limit the number of FT_FACE and FT_SIZE;
 however, how to determine the memory requirements for a given number of
 allowable FT_FACE and FT_SIZE. I am using freetype for an embedded system at
 the moment, thus, memory is really a constraint, and it's very important for
 me to be able to determine the size of the heap.


 best regards

 Maggy Anastasia Suryanto

 ___
 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] Improvement of ft_ansi_stream_io

[David Turner]

Looks fine to me

- David

2009/6/19 Werner LEMBERG w...@gnu.org


 I got the following:

  There is not need to call ft_fseek() every time when execute
  ft_fread().  Here is the patch:
 
  ftsystem.c:
 
FT_CALLBACK_DEF( unsigned long )
ft_ansi_stream_io( FT_Stream   stream,
   unsigned long   offset,
   unsigned char*  buffer,
   unsigned long   count )
{
  FT_FILE*  file;
  file = STREAM_FILE( stream );
+if ( stream-pos != offset )
  ft_fseek( file, offset, SEEK_SET );
  return (unsigned long)ft_fread( buffer, 1, count, file );
}
 
  ftstream.c:
 
FT_BASE_DEF( FT_Error )
FT_Stream_Seek( FT_Stream  stream,
FT_ULong   pos )
{
  FT_Error  error = FT_Err_Ok;
-stream-pos = pos;
  if ( stream-read )
  {
if ( stream-read( stream, pos, 0, 0 ) )
{
  FT_ERROR(( FT_Stream_Seek: invalid i/o; pos = 0x%lx, size =
 0x%lx\n,
 pos, stream-size ));
  error = FT_Err_Invalid_Stream_Operation;
}
  }
  /* note that seeking to the first position after the file is valid */
  else if ( pos  stream-size )
  {
FT_ERROR(( FT_Stream_Seek: invalid i/o; pos = 0x%lx, size =
 0x%lx\n,
   pos, stream-size ));
error = FT_Err_Invalid_Stream_Operation;
  }
+if ( !error )
+  stream-pos = pos;
  return error;
}

 Can someone please check the validity of this patch?


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] FT_Init_FreeType allocating memory before I get a chance to set the allocators.

[David Turner]

As noted by other posters, FT_Init_Library is a convenience function. You
may want to use FT_New_Library instead to provide your own custom allocator.

2009/6/22 Werner LEMBERG w...@gnu.org


   both FT_New_Memory, and FT_New_Library (functions called within
   FT_Init_FreeType) are allocating memory, before I have a chance
   of setting the function pointers in FT_Memory..  To get around
   that I added an extra argument to the FT_Init_FreeType, which
   allows me to provide an FT_Memory structure, before any other
   freetype code is running.
 
  The `canonical' way is to replace ftsystem.c with something more
  appropriate for your target platform.  For example, you can copy
  the whole file, only replacing `FT_New_Memory' to fit your needs.
  I don't see an immediate need to add new API functions -- you have
  to convince me that the just outlined method doesn't work :-)
 
  Sure I could do that... but then what is the point of having the
  FT_Memory struct...it doesn't work as advertised, and in order to
  fix it you advise me to replace a file where I need to implement my
  own ft_alloc methods?

 Well, advise...  What I do is rather like taking a stab in the dark
 based on previous information :-)

  The changes I made, make the FT_Memory struct work at all times, not
  just after initialization, even in a DLL build  What you propose
  doesn't fix FT_Memory, but will fix my problem if I implement it in
  a way that adds a dependency on the system I have for allocating
  memory, which is an undesirable dependency, or if I just strip those
  methods from freetype, and implement them locally and have the
  linker sort it out.. (in which case a DLL build won't work anymore).
  both methods seem architectural wrong to me... but I guess I'm alone
  in that...

 I don't think so.  Your arguments sound convincing -- let's see what
 David says.

  Anyway, again I really just wanted to 'notify' you of this, if you
  don't believe the changes make sense then don't take it, I'm
  perfectly fine integrating my changes over top every time I upgrade,
  which I hardly do anyway I just ran into this again when I took
  the 2.3.9 upgrade, and though I might as well be decent and
  contribute back...

 Thanks for that!  Please always reply to the list too (even if you
 aren't subscribed).


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

[David Turner]

Welcome back tom :-)
In my opinion, reading the following is a definitive requirement for anyone
working with git:
http://eagain.net/articles/git-for-computer-scientists/

Git is very flexible, but the mental model one requires to maintain to use
it is much more demanding than traditional VCSes.

I also recomment the Git Community Book for new-comers:
http://book.git-scm.com/

Git has evolved historically from a low-level plumbing tool for real cowboy
developers to what it currently is; which is something with a very clunky
user interface where making a mistake is extremely easy, and reverting or
understanding what happened can be non trivial. Also, a lot of the git
tutorials available were written a long time ago and expose too much
low-level detail (imho) that will only embarass you. The Git Community Book
is really refreshing because it really deals with the most relevant things
for typical developers without dumbing down things.

Happy hacking.



2009/5/21 Tom Kacvinsky tkacvin...@mac.com

 Hi,

 I am looking at getting back into the FreeType project after a five or so
 year hiatus.  I see
 things have moved from cvs to git (skipped svn?)  Does anyone know of a
 good tutorial
 on git?

 Tom


 ___
 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] Re: Git and ChangeLogs

[David Turner]

2009/4/15 Werner LEMBERG w...@gnu.org



 Please no.  This is even more work.

 IMHO we should force everyone to commit *small* chunks, split into
 easily readable code fragments.  This would help more than anything
 else.


OK, then I think we should definitely make the ChangeLog format easier
to generate and edit in case of conflicts (I don't think it's painless to
merge),
which would mean:

- no TABs in the file. Period
- when giving the list of changed files, just use one file per line, without
a prefix like *
- it's pretty obvious when a line only consists in a file name, and it not a
description, so don't indent them specially
- use 4 spaces to indent the file-specific change description.
- except if there is ambiguity (i.e. when a single file was touched for two
distinct reasons, something which should be avoided more easily with git
than CVS), there is no need to list the functions/types/modified by a change
unless it touches the public API.


For example, replace:

2009-03-20  Werner Lemberg  w...@gnu.org

Fix Savannah bug #25923.

* src/cache/ftccmap.c (FTC_CMAP_HASH): Fix typo.

with:

2009-03-20  Werner Lemberg  w...@gnu.org

Fix #25923.

src/cache/ftccmap.c
Fix typo.

A more complicated example would be to replace:

2009-03-12  Werner Lemberg  w...@gnu.org

Fix some FreeType Coverity issues as reported for Ghostscript.

* src/base/ftobjs.c (FT_New_Face, FT_New_Memory_Face): Initialize
`args.stream' (#3874, #3875).
(open_face_PS_from_sfnt_stream): Improve error management (#3786).
* src/base/ftmm.c (ft_face_get_mm_service): Fix check of `aservice'
(#3870).
* src/base/ftstroke.c (ft_stroke_border_get_counts): Remove dead
code (#3790).
* src/base/ftrfork.c (raccess_guess_apple_generic): Check error
value of `FT_Stream_Skip' (#3784).

* src/type1/t1gload.c (T1_Load_Glyph): Check `size' before accessing
it (#3872)

* src/pcf/pcfdrivr.c (PCF_Glyph_Load): Check `face' before accessing
it (#3871).
* src/pcf/pcfread.c (pcf_get_metrics): Handle return value of
`pcf_get_metric' (#3789, #3782).
(pcf_get_properties): Use FT_STREAM_SKIP (#3783).

* src/cache/ftcmanag.c (FTC_Manager_RegisterCache): Fix check of
`acache' (#3797)

* src/cff/cffdrivr.c (cff_ps_get_font_info): Fix check of `cff'
(#3796).
* src/cff/cffgload.c (cff_decoder_prepare): Check `size' (#3795).
* src/cff/cffload.c (cff_index_get_pointers): Add comment (#3794).

* src/bdf/bdflib.c (_bdf_add_property): Check `fp-value.atom'
(#3793).
(_bdf_parse_start): Add comment (#3792).

* src/raster/ftraster.c (Finalize_Profile_Table): Check
`ras.fProfile' (#3791).

* src/sfnt/ttsbit.c (Load_SBit_Image): Use FT_STREAM_SKIP (#3785).

* src/gzip/ftgzip.c (ft_gzip_get_uncompressed_size): Properly ignore
seek error (#3781).

With:

2009-03-12  Werner Lemberg  w...@gnu.org

Fix some FreeType Coverity issues as reported for Ghostscript.

src/base/ftobjs.c
Initialize `args.stream' (FT_New_Face, FT_New_Memory_Face) (#3874,
#3875).
Improve error management (open_face_PS_from_sfnt_stream) (#3786).

src/base/ftmm.c
Fix check of `aservice', #3870.

src/base/ftstroke.c
Remove dead code (#3790).

src/base/ftrfork.c
Check error value of `FT_Stream_Skip' (#3784).

 src/type1/t1gload.c
Check `size' before accessing it (#3872)

 src/pcf/pcfdrivr.c
Check `face' before accessing it (#3871)

src/pcf/pcfread.c
Handle return value of `pcf_get_metric' (pcf_get_metrics) (#3789,
#3782).
Use FT_STREAM_SKIP (pcf_get_properties) (#3783).

src/cache/ftcmanag.c
Fix check of `acache' (#3797).

src/cff/cffdrivr.c
Fix check of `cff' (#3796).

src/cff/cffgload.c
Check `size' (#3795).

src/cff/cffload.c
Add comment (#3794).

src/bdf/bdflib.c
Check `fp-value.atom'  (_bdf_add_property) (#3793).
Add comment (_bdf_parse_start) (#3792).

src/raster/ftraster.c
Check `ras.fProfile' (#3791).

src/sfnt/ttsbit.c
Use FT_STREAM_SKIP (#3785).

src/gzip/ftgzip.c
Properly ignore seek error (#3781).

One goal of this format is to make it very easy generate from the output of
git diff --name-only or something similar.

In all cases, editing the current ChangeLog by hand is too tedious. The fact
that you spend a non-trivial amount of
your time reformating and complementing it doesn't encourage me, and
probably others, to do a better work here too :-)



Werner

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

Re: [ft-devel] Regarding Position-Independent-Code, modules, etc..

[David Turner]

2009/4/14 Dmitry Timoshkov dmi...@codeweavers.com

 Oran Agra o...@monfort.co.il wrote:

  Waiting to see your suggested solution.


 I'd once again suggest to stop making FreeType code ugly and force
 broken platforms to upgrade their compiler toolchain instead.


Actually, I'm trying to make the code easier to maintain and comprehend.

There are already quite a few wacky things in the way we currently manage
modules/drivers/renderers/services, and we could certainly make the
internals
simpler and easier to manage in various ways.

Even the build system could be slightly improved to require much less
verbosity,
from a higher-level description of modules, their dependencies and other
stuff.




 Especially since it's been stated that not all code was/will be
 converted. There is no need to do the compiler/linker job in
 the source code.


Yes, the PIC support is problematic because if we want to change internals
in a
significant way, we'll need to modify all these crazy macros as well.
Converting
the rest of the source code is a huge task, and I now don't think there is a
simple way
to do that simply relying on the C pre-processor.

I think that if we don't find a convenient meta-programming approach to
generate
the PIC support code, we should simply scratch it from the main branch. We
can
still put it in a separate branch for the people who depend on it, where
they'll be
free to update it and integrate mainline fixes as they see fit.

- David



 --
 Dmitry.

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

[ft-devel] Re: Git and ChangeLogs

[David Turner]

I think this is what we want. Updating ChangeLog is already quite time
consuming and I already experienced
a few frustrating merge conflict with it when pulling upstream into my own
branches (these happen very easily
when you updated a file that has been modified in the pulled upstream).

On the other hand, our ChangeLog is generally more verbose and useful than
the commit messages themselves,
and often is corrected to better reflect the changes, why they were made,
etc..

With git this is simply not possible to update the log like this unless you
want to change the upstream tree in
ways that break remote branches nastily.

So I guess we probably need to find a middle ground, i.e. generate an
automatic ChangeLog from git log and
use a different file to document the changes (one that would not necessarily
need the list of all files modified,
etc..). We already have docs/CHANGES.TXT, but this is only used to document
high-level changes that affect
client developers.

Maybe we need another file like docs/INTERNAL-CHANGES.TXT ?

2009/3/25 Huw Davies h.davi...@physics.ox.ac.uk

 On Wed, Mar 25, 2009 at 03:37:13PM +0100, David Turner wrote:
  I also tried to apply your previous set of patches to the git repository,
  and it failed due to inconsistencies with the ChangeLog file. Can I ask
 you
  to provide a second set of patches from a more recent commit ?

 For what it's worth, in Wine we don't submit patches that include a
 ChangeLog diff.  The ChangeLog is updated automatically (from git log)
 every time the maintainer makes a release.  This way we avoid
 conflicts like the above.

 Huw.

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

[ft-devel] Regarding Position-Independent-Code, modules, etc..

[David Turner]

Hello,

just to let you know that I have recently tried to cleanup a bit the recent
Position-Independent-Code
that was contributed to the FreeType sources. While this works is really
nice, I believe it represents
a vast challenge in terms of maintanability for the people who don't care
about PIC. Moreover, not
all modules have been converted to PIC-compatible wrappers and
deifnitions, and doing so is going
to be very demanding.

I've started doing PIC-related changes on my own branch, which I just
uploaded to the git server
under the branch name david-pic-changes for you to look. My initial idea
was to use macros and
a heavy dose of pre-processing to simplify and reduce the PIC-related
declarations needed in the
source code.

However, even after modifying a few things, it's clear that the end result
is not tremendously more
maintanable. The code is definitely shorter, and easier to modify, but it is
also harder to comprehend.
It's essentially equivalent to what you can do with a set of crazy templates
in C++, and of course it's
also as difficult to debug when something isn't just right.

For this reason, I think we should try something more drastic to scale this
approach. I'm mainly thinking
about using a custom pre-processing tool (e.g. a custom Python script), that
would translate a very
simple and human-readable high-level description of each module and the
constant structures it requires,
into equivalent C code that could be compiled in PIC or non-PIC mode.

I'll try to post more about that when I have something working, but wanted
to let you know, in case
you have other ideas on the subject.

Regards

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

[ft-devel] Regarding Position-Independent-Code, modules, etc..

[David Turner]

Hello,

just to let you know that I have recently tried to cleanup a bit the recent
Position-Independent-Code
that was contributed to the FreeType sources. While this works is really
nice, I believe it represents
a vast challenge in terms of maintanability for the people who don't care
about PIC. Moreover, not
all modules have been converted to PIC-compatible wrappers and
deifnitions, and doing so is going
to be very demanding.

I've started doing PIC-related changes on my own branch, which I just
uploaded to the git server
under the branch name david-pic-changes for you to look. My initial idea
was to use macros and
a heavy dose of pre-processing to simplify and reduce the PIC-related
declarations needed in the
source code.

However, even after modifying a few things, it's clear that the end result
is not tremendously more
maintanable. The code is definitely shorter, and easier to modify, but it is
also harder to comprehend.
It's essentially equivalent to what you can do with a set of crazy templates
in C++, and of course it's
also as difficult to debug when something isn't just right.

For this reason, I think we should try something more drastic to scale this
approach. I'm mainly thinking
about using a custom pre-processing tool (e.g. a custom Python script), that
would translate a very
simple and human-readable high-level description of each module and the
constant structures it requires,
into equivalent C code that could be compiled in PIC or non-PIC mode.

I'll try to post more about that when I have something working, probably in
another server branch,
but wanted to let you know, in case you have other ideas on the subject.

Regards

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

Re: [ft-devel] Searching for an FT2 tester program

[David Turner]

2009/4/5 Oran Agra o...@monfort.co.il

 Hi,
 I've pushed the PIC changes into GIT (including moving the changes from the
 public headers to ftobjs.h).

 Please let me know if there are any problems.
 I've checked that it builds with the jam system (non PIC) with VS2005.
 And also that the PIC version builds with the custom build I'm using (ADS
 and RVCT for BREW).
 Also verified that ftview works on a simple font.


Thanks a lot Oran, this is really great work.



 I imagine some makefiles should be updated.
 And a lot of testing is needed.

 Btw, I've found a broken link in:
 http://freetype.sourceforge.net/developer.html#anongit
 The link to https://savannah.gnu.org/maintenance/UsingGit needs to be with
 http and not https.




 ___
 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] Searching for an FT2 tester program

[David Turner]

Thank you Oran, this looks better indeed. However, this is a patch against
your previous patch and a patch against the current git sources would be
better.

I also tried to apply your previous set of patches to the git repository,
and it failed due to inconsistencies with the ChangeLog file. Can I ask you
to provide a second set of patches from a more recent commit ?

I would also prefer if you do *not* modify public header files (e.g.
ftimage.h), the corresponding declarations you want to add could instead be
placed in internal/ftobjs.h

Apart from that, I'm still playing with the idea of using macros and other
tricks to do the same thing, though this still requires a bit more work.
The main idea is to use a single declaration like the following:

#define  FT_FOO_CLASS_DEFS \
   _SIZE_FIELD( FT_UInt,  size ) \
   _FIELD( FT_Foo_InitFunc,   init ) \
   _FIELD( FT_Foo_DoneFunc,   done ) \
   _FIELD( FT_Foo_ActionFunc, action ) \

then use it repeatedly, e.g. to declare the corresponding FT_CMap_Class
types:

/* declare FT_Foo_Class types */
#define  _CLASSNAME  FT_Foo_Class
#define  _CLASSDEFS  FT_FOO_CLASS_DEFS
#include FT_INTERNAL_CLASS_DECLARATION_H

which would generate the following code after pre-processing:

typedef const struct FT_Foo_ClassRec_*  FT_Foo_Class;

typedef struct FT_Foo_ClassRec_
{
  FT_UInt   size;
  FT_Foo_InitFunc   init;
  FT_Foo_DoneFunc   done;
  FT_Foo_ActionFunc action;
} FT_Foo_ClassRec;

then, to define a class in the code:

/* define 'foo_class' table */
#define_CLASSVARfoo_class
#define_CLASSNAME   FT_Foo_Class
#define_CLASSDEFS   FT_FOO_CLASS_DEFS
#define_INITPREFIX  foo_
#definefoo_done NULL
#include FT_INTERNAL_CLASS_DEFINITION_H

which in the non-PIC case would generate:

const FT_Foo_ClassRec   foo_class =
{
sizeof(FT_Foo_ClassRec),
foo_init,
NULL,
foo_action
};

(assuming foo_init and foo_action are already declared), but in the PIC case
would do instead something like:

static void _init_foo_class( FT_Foo_ClassRec*  clazz )
{
  clazz-size   = sizeof(FT_Foo_ClassRec),
  clazz-init   = foo_init;
  clazz-done   = NULL;
  clazz-action = foo_action;
}

After that, there are other complicated details so that _init_foo_class is
used appropriately,
i.e. it must be called at module initialization time in the PIC case only,
with a heap-allocated
structure passed as a parameter. However, this can also be performed with
macros.

I'm preparing a patch to show how this can work on the existing code base.
However this is
going to take a long time, so I would prefer if we could first submit your
changes, then slowly
migrate to this new scheme (we can do this piece by piece, fortunately).

There are also complications due to the fact that modules themselves are
defined through a
constant table (but again, we can work with this with macros), and the
challenge of derived classes,
but I believe we should be able to support these as well with the minimal
impact on duplication.

Regards


2009/3/22 Oran Agra o...@monfort.co.il

 Hi,
 Here's a patch that changes what David requested, I hope I got it right.
 Let me know if you have any other comments.
 Oran.

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

Re: [ft-devel] Searching for an FT2 tester program

[David Turner]

Hello,

thanks a lot for your work. Can you add some clarification to the ChangeLog
of the first patch that explain why it is needed ?

Regarding the second patch, the internal code uses the convention of naming
functions as:

object_method( Object*  o,  )

It would be nicer if you could keep the convention instead of prepending an
extra FT_Library parameter at the start of the
function. Indeed, you should instead store the FT_Library handle into the
CFF_Parser object and pass it to cff_parser_init,
then re-use it in subsequent functions. This will make the code much
clearer.

2009/3/18 Oran Agra o...@monfort.co.il

 I'm working in my local master branch so I guess 'git rebase' is not
 necessary.

 Attached are first two patches that are not related to PIC.
 Please tell me if the comments and git patches are ok.

 I'll add the documentation you requested.
 And I've verified that VS2005 and VS6 are compiling the PIC code including
 all the macros.


 ___
 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] Searching for an FT2 tester program

[David Turner]

Thanks you werner, I did read the second set of patches, and my comments
still stand.

Another major issue that I have with the code is that it is very error-prone
and very cumbersome
to have these 1000 macros for declaring and defining classes. I would really
prefer if we could
use a simpler scheme that, gasps, relies on the C pre-processor, but at
least would make our
life easy.

This is difficult to explain this without a real example, I'll try to cook
one up and post it there
shortly.

2009/3/20 Werner LEMBERG w...@gnu.org


  Can you add some clarification to the ChangeLog of the first patch
  that explain why it is needed ?
 
  Regarding the second patch, [...]

 David, these two patches are superseded by the suite of patches in

  http://lists.gnu.org/archive/html/freetype-devel/2009-03/msg00095.html

 Please comment these instead.  It makes his life easier :-)


Werner

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

Re: [ft-devel] Why my memory is not been freed?

[David Turner]

2009/3/7 Jun.Wang xjw...@sunmedia.com.cn


 I did the memory debug with a little modify.
 1. In FT_Done_FreeType( FT_Library  library ),  I disabled the line:
 FT_Done_Library( library ), so the memory report will disaply the current
 memory.


???



 2. I call FT_Done_FreeType() before FT_Done_Face(),


This is a bug in your program. After FT_Done_FreeType() is called, every
memory allocated
by the corresponding FT_Library should be released (with the exception of
FT_Glyph objects
allocated by the user, but you are responsible for free-ing them before
FT_Done_FreeType())

Calling FT_Done_Face() after that is probably asking for a lot of trouble
(i.e. waling dangling pointers
in the heap).



 and I getted the
 follws report:
//only load 1 character
FreeType Memory Dump: current=776564 max=776795 total=781508
 count=59
//load 35 diff characters
FreeType Memory Dump: current=777225 max=777579 total=783118
 count=59
//load 150K characters, there are some same characters
FreeType Memory Dump: current=779033 max=780079 total=34608360
 count=60

after the FT_Done_Face(g_FTFace), the current for above all are
 same:
FreeType Memory Dump: current=42697 max=777579 total=783118 count=21

It Looks while don't do FT_Done_Face(), the memory will increase
 with the loaded numbers

3. I do the load as follows:
   for(i = 0; i  Size; i++){
FT_Load_Glyph(g_FTFace, currChar[i],  FT_LOAD_RENDER);
bitmap = (g_FTFace-glyph-bitmap);
uiPixMode = g_FTFace-glyph-bitmap.pixel_mode;
bitmap_top = g_FTFace-glyph-bitmap_top;
bitmap_left = g_FTFace-glyph-bitmap_left;
bitmap_rows = bitmap-rows;
   darw(bitmap);
  }

 Is there function to free memory after every FT_Load_Glyph? If do
 FT_Done_Face() every time, then I need FT_New_Face every time also.

 My freetype2 lib is 2.2.1.

 Thanks for your reply.
 --
 View this message in context:
 http://www.nabble.com/Why-my-memory-is-not-been-freed--tp22383746p22383746.html
 Sent from the Freetype - Dev mailing list archive at Nabble.com.



 ___
 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] ABI breakage in 2.3.8 (bad bad bad !!)

[David Turner]

Hello,

I'm currently updating the Android FreeType sources to the latest CVS. In
doing so, I noticed something that unfortunately
escaped me before that: we added a new field to a publicly declared
structure, thus breaking the ABI.

More specifically, the declaration of PS_FontInfoRec in
include/freetype/t1tables.h is now:

typedef struct  PS_FontInfoRec_
  {
FT_String*  version;
FT_String*  notice;
FT_String*  full_name;
FT_String*  family_name;
FT_String*  weight;
FT_Long italic_angle;
FT_Bool is_fixed_pitch;
FT_Shortunderline_position;
FT_UShort   underline_thickness;

*/* since 2.3.8 */

FT_UShort   fs_type;
*
  } PS_FontInfoRec;

the problem is that this structure can be allocated by the user (either in
the heap or the stack), e.g. when calling
a function like FT_Get_PS_Font_Info declared as:

FT_EXPORT( FT_Error )
FT_Get_PS_Font_Info( FT_Face  face,
 PS_FontInfo  afont_info );

*This is very bad* !!.

It means that any client code that was built against 2.3.7 or older will now
experience a nice
silent stack or heap memory corruption whenever it calls this function in
2.3.8.

I suggest that we do the following instead:


   - remove the field from the definition
   - provide a new function to retrieve the corresponding information, as in
   FT_Get_PS_FsType() or whatever, that will not break the ABI
   - release 2.3.9 ASAP explaining why.

I really hope that there isn't any code that relies on this new field out
there.

Generalyl speaking, we should *NOT* add fields to public structures, except
a very few instances where we know that the
corresponding object should never be stack or heap allocated by the user
(FT_Face or FT_GlyphSlot for example). Even
in these cases, I'd really prefer that we discuss such changes on the
development mailing list before hand.

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

Re: ABI breakage in 2.3.8 (bad bad bad !!) -- FW: [ft-devel] Accessing FSType (Type 1 or CID)?

[David Turner]

Hi David,

that's ok, but I'm surprised this didn't get caught. The problem is even
worse than I thought because PS_FontInfoRec is
also used to define the fonts_infos in the PS_BlendRec structure (I don't
think we have any client code that accesses
this though).

I have submitted a fix to the CVS repository (which wasn't too trivial). The
Function FT_Get_FSType_Flags() has
been updated accordingly.

For the record, here's the ChangeLog entry:

Remove ABI-breaking field in public PS_InfoFontRec definition.
Instead, we define a new internal PS_FontExtraRec structure to
hold the additionnal field, then place it in various internal
positions of the corresponding FT_Face derived objects.

* include/freetype/t1tables.h (PS_FontInfoRec): Remove the
`fs_type' field from the public structure.

* include/freetype/internal/psaux.h (T1_FieldLocation),
include/freetype/internal/t1types.h (T1_FontRec, CID_FaceRec),
src/type1/t1load.c, src/type1/t1tokens.h,
src/cid/cidload.c, src/cid/cidtoken.h,
src/type42/t42parse.c: modify the various font parsers to store
the `fs_type' field in a different places, instead of the public
PS_FontInfoRec.

* include/freetype/internal/services/svpsinfo.h (PsInfo service),
src/base/ftfstype.c (FT_Get_FSType_Flags), src/cff/cffdrivr.c,
src/cid/cidriver.c, src/type1/t1driver.c, src/type42/t42drivr.c:
Modify the PsInfo service to add a GetExtra function, use it in
FT_Get_FSType_Flags() and modify the drivers accordingly.


2009/3/3 Bevan, David dbe...@emtex.com

  David,



 My apologies, but this *was* discussed on the development mailing list
 (see below).



 I would have used an alternative approach if I had been informed that
 adding a new field to the public structure was not permitted.



 David %^





 -Original Message-
 From: Werner LEMBERG [mailto:w...@gnu.org]
 Sent: 11 December 2008 17:18
 To: Bevan, David
 Cc: mpsuz...@hiroshima-u.ac.jp; Ghoshal, Ronen; Tu, Houjie;
 freetype-devel@nongnu.org
 Subject: Re: [ft-devel] Accessing FSType (Type 1 or CID)?





  If I understand correctly, a field needs adding to PS_FontInfoRec

  (which is part of the public interface; presumably this is OK) and

  FSType processed just like other fields, simply by defining in

  t1tokens.h.



 Yes, I think this should work without breaking backwards binary

 compatibility of the library.  In any case, the new field should be

 at the end of the structure.



 ...



 Werner

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

Re: [ft-devel] Problem cross-compiling freetype-2.3.8 for ARM

[David Turner]

2009/2/25 Jean-Claude Repetto jrepe...@free.fr

 David Turner a écrit :

 This has been recently fixed in the CVS repository, see this for details:

 http://git.freetype.org/?p=freetype2.git;a=commitdiff;h=7bb1c4ce1221edb3ed900666fee3eae790255820


 Hello,

 Thanks to mpsuzuki, Werner and David for your answers.

 It seems the problem came from a syntax error in the ARM assembly language.
 But I could compile successfully freetype-2.3.8 for the at4x0a version of
 the ARM processor, with this cross-compiler :
 
 http://www.tomtom.com/gpl/toolchain_at4x0a_gcc-4.2.1_glibc-2.6-20080202.tar.bz2
 

 Does it mean that assembly language is not used for this processor ?


Not necessarily, it depends on how pedantic your assembler really is, which
could come from the way the toolchain was configured or something else.
The best way to determine if the code is compiled or not is to add
deliberate #error FOO lines in it and see if this is reflected at build
time.



 Regards,

 Jean-Claude


 ___
 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] problems with CVS-git conversion

[David Turner]

2009/3/3 Werner LEMBERG w...@gnu.org


  Would it make sense to first convert to GIT then later change the commit
  messages there.

 I tried that, and it doesn't work properly.


Ah, can you tell me which problem exactly ? I could do the migration myself.
By the way, I started documenting it at the following:

http://digitsbraveblog.blogspot.com/



  I believe it's going to be much easier, and to be honest, I'm unsure
  that updating the original CVS messages is going to be very useful.

 In case I don't find a not-too-complicated solution I just run
 parsecvs and nothing else.  But currently I still try to find
 something :-)


Werner

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

Re: ABI breakage in 2.3.8 (bad bad bad !!) -- FW: [ft-devel] Accessing FSType (Type 1 or CID)?

[David Turner]

It'd be nice if we could remove the 2.3.8 packages from the Savannah server.
I'll try to do that.

2009/3/3 Werner LEMBERG w...@gnu.org


  I have submitted a fix to the CVS repository (which wasn't too
  trivial).

 Thanks.  I'll release a new FreeType version probably in a week or so.


Werner

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

Re: [ft-devel] Getting Module Pointer From a Module Function?

[David Turner]

Hi Mickey,


2009/1/22 Mickey Gabel mic...@monfort.co.il

 Is there a standard/good way to get the module pointer (not the module
 class, I am talking about FT_ModuleRec that contains the module's data).

 Case in point:

 I am working on af_face_globals_new() in autofit/afglobals.c which is part
 of the autofit module.
 Is there a way to get to the FT_AutofitterRec which is initialized during
 module init (AutoFitterRec is defined in autofit/afmodule.c) ?

 I could add the parameter explicitly, but is there a more standard way?


You could try calling FT_Get_Module( face-library, module name );

I'm surprised you'd want to do that though, what kind of
non-font-face-specific data would you like to store there ?

Are you trying to cache the result of global glyph analysis to speed up
things. I would recommend provide a way
for the library user to store it in its own cache, with callbacks to
lookup/add the data from the font engine. That
way the client could control exactly how much memory is consumed by this
scheme.

Regards

- David







 ___
 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] Switching to Git ?

[David Turner]

Hello everyone,

long time no see :-)

I'd like to know if Werner and others are interested in switching the
FreeType repository to git in the near future ?

I've been a heavy user of the tool since several months, and while there are
really a few bat-shit insane user-interface
issues with it (even in most recent releases), it beats CVS hands down in
nearly all respects.

I'm currently maintaining my own git repo with git-cvsimport, which works
pretty well, but would like the ability to directly
talk to the main server that way.

Nothing really of high priority, but I wanted at least to know your opinion
about it ?

Regards

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

Re: [ft-devel] Multi-threading question

[David Turner]

2009/2/23 Mike Moening mi...@reteksolutions.com

  In the 2.3.8 documentation it states that each thread should have its own
 FT_Library object.

 Currently we keep one FT_Library per FT_Face.
 We have a C++ wrapper object per font face which wraps these two together.

 We use FT_New_Memory_Face() to load the face into the object.
 Because the font files are rather large (several Megabytes) we leave the
 face open,
 so as not to re-load it every time we need to get metrics on a different
 glyph.

 Question:

 Can we safely use the stored FT_Face handle with other FT_Library
 instances?
 Assuming (per documentation suggestions) that we have a FT_Library per
 thread.

No you can't.

 The idea is to allow multiple threads to get glyph metrics by simultaneosly
 calling these methods:
 FT_Set_Char_Size()
 FT_Get_Char_Index()
 FT_Load_Glyph()

 Once we retreive the metrics we store each set of metrics in map hashed by
 glyph which is owned by the wrapper object.
 This map is protected by a lock of course.

 It seems to me, based on my understanding of the code, that there would be
 no way to allow each thread to access the metrics unless each thread calls 
 FT_New_Memory_Face()
 and has its own handle to the face.

Exactly.

 That seems sub-optimal.

The eye is in the beholder. Allowing what you want would make the design of
FreeType much more complicated and would also make it use more memory in all
cases.

And if your file is memory-mapped, you shouldn't have much performance
degradation from using several FT_Library/FT_Face in parallel anyway; and
each thread should go as fast as possible, without any potential for locking
or contention.

 I welcome suggestions on the fastest architecture to simulaneously retrieve
 font metrics with multiple threads.

 Thanks,

 Mike M.

 ___
 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] Switching to Git ?

[David Turner]

Tad !

An experimental git repository is now in place, see http://git.freetype.org

Note that:


   - this was created by taking a snapshot of the current CVS repository;
   running git-cvsimport on it then 'git-filter-branch --msg-filter' with the
   attached (basic) script to improve the commit messages a bit.

   (It's still not perfect, could be improved in the future)


   - read-only access :-)


   - there is *no* git = CVS bridge at the moment, I'm still trying to get
   the exact details on how to properly set this up. There is no point to
   provide write access until this is solved.


   - this runs on my home Zonbu box behind my DSL router; so don't expect
   any kind of scalability at the moment; it's really an experimental setup to
   show what's possible in a few hours.


   - gitosis / git-daemon / gitweb are nice, but oh my, they are so badly
   documented that it's hard to avoid many pitfalls. I'll try to document them
   later.


   - We will probably want to move this to a real server in the future. For
   now consider this as an experiment. I'm probably going to scrap it and start
   another one from scratch with a better commit message rewriter. I've given
   up rewriting the CVS messages themselves. I will warn before doing so, or
   create a different branch.

 Comments and opinions welcome.

2009/2/23 Keith Packard kei...@keithp.com

 On Mon, 2009-02-23 at 19:25 +0100, Werner LEMBERG wrote:

  Well, a direct import is trivial; however, it would be beneficial to
  walk over, say, the last 1000 to 2000 commits so that all get a nice
  one-line title.

 My 'parsecvs' tool will probably handle freetype's CVS repository fairly
 well. It's not easy to use, but was used to convert X.org's repositories
 where other tools failed due to the fairly complex (and often broken)
 history.

 It requires direct access to the CVS source repository; if you'd like me
 to give this a try, let me know.

 --
 keith.pack...@intel.com

#!/usr/bin/python
#
# This script is used to convert the FreeType commit messages
# to a simpler one-liner format.
#
# What we want to do here is to essentially replace messages that
# look like the following:
#
#* path1/file1.c (some_function), path2/file2.c,
#  path3/file3.c: THE REAL COMMIT MESSAGE THAT CAN
#  SPAN SEVERAL LINES
#
# by:
#
#THE REAL COMMIT MESSAGE THAT CAN SPAN SEVERAL LINES
#* path1/file1.c ... : THE REAL COMMIT MESSAGE ... etc
#
# not totally elegant, but gets the job done :-)
#
import sys, os, string, re

lines   = []
lineStart   = True
lineCurrent = 

re_sourcePath = re.compile(r\s*([A-Za-z_][A-Za-z0-9_/.]*)\s*(.*))
re_functionName = re.compile(r\([^)]*\)\s+(.*))

# read lines from stdin and create paragraphs into lines
for line in sys.stdin.readlines():
# strip trailing LN
line = string.strip(line)
if len(line)  0 and line[-1] == '\n':
line=line[:-1]

if len(line) == 0:
if not lineStart:
lineStart = True
lines.append(lineCurrent)
lineCurrent = 
else:
if not lineStart:
lineCurrent +=  
lineCurrent += line
lineStart= False

if not lineStart:
lines.append(lineCurrent)

# now, check whether the first paragraph begins with an asterisk
lines2=[]
for line in lines[0:1]:
firstLine = line[:]
if firstLine[0] == '*':
# find the location of the column
index = firstLine.rfind(':')
if index  0:
firstLine = string.strip(firstLine[index+1:])
lines2.append(firstLine)
lines2.append(line)

for line in lines2:
print line
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Invalid Preprocessor directive: #include FT_FREETYPE_H

[David Turner]

sorry, I read that too quickly :-)
mpsuzuki is right, you're missing the freetype2-config --cflags on your
command-line


2008/11/2 David Turner [EMAIL PROTECTED]

 hmmm, your compiler is not ANSI-C compliant, since #include MACRO_NAME is
 defined by the standard as a valid construct.
 You should get a better compiler, or write a script to replace all
 occurences of #include MACRO_NAME with #include corresponding/header.h

 2008/10/2 ccube [EMAIL PROTECTED]


 Hi,
 I want to use the FT2 library in my own programm.

 For testing, i use this sample code from the Freetype Project:

 #include ft2build.h
 #include FT_FREETYPE_H

 FT_Library library; ...
  error = FT_Init_FreeType( library );
 if ( error ) {
 ... an error occurred during library initialization ...
 }

 When compiling, i always get an error like Invalid Preprocessor
 directive:
 #include FT_FREETYPE_H

 What is missing?

 My Systems are Ubutnu 8.04, 8.10, x64, x86
 Everywhere the same error.

 Compiler is the standard ubuntu gcc compiler.

 Can anyone help me?

 Regards,
 Lukas
 --
 View this message in context:
 http://www.nabble.com/Invalid-Preprocessor-directive%3A--include-FT_FREETYPE_H-tp19778956p19778956.html
 Sent from the Freetype - Dev mailing list archive at Nabble.com.



 ___
 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] Invalid Preprocessor directive: #include FT_FREETYPE_H

[David Turner]

hmmm, your compiler is not ANSI-C compliant, since #include MACRO_NAME is
defined by the standard as a valid construct.
You should get a better compiler, or write a script to replace all
occurences of #include MACRO_NAME with #include corresponding/header.h

2008/10/2 ccube [EMAIL PROTECTED]


 Hi,
 I want to use the FT2 library in my own programm.

 For testing, i use this sample code from the Freetype Project:

 #include ft2build.h
 #include FT_FREETYPE_H

 FT_Library library; ...
  error = FT_Init_FreeType( library );
 if ( error ) {
 ... an error occurred during library initialization ...
 }

 When compiling, i always get an error like Invalid Preprocessor directive:
 #include FT_FREETYPE_H

 What is missing?

 My Systems are Ubutnu 8.04, 8.10, x64, x86
 Everywhere the same error.

 Compiler is the standard ubuntu gcc compiler.

 Can anyone help me?

 Regards,
 Lukas
 --
 View this message in context:
 http://www.nabble.com/Invalid-Preprocessor-directive%3A--include-FT_FREETYPE_H-tp19778956p19778956.html
 Sent from the Freetype - Dev mailing list archive at Nabble.com.



 ___
 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] Very very old CodeWarrior C compiler cannot parse directory-structured include files

[David Turner]

Dear mpsuzuki,

While I applaud your enthusiasm about such an old piece of software, I don't
think
we should spend any developer cycles trying to support this officially :-)

It is my opinion that any person who tries to use FreeType with such dated
tools
will have the necessary scripting skills to transform the sources by
themselves to fit their niche. And if they don't, they probably should
switch to a
better platform/com

Regards,

- David


2008/10/13 [EMAIL PROTECTED]

 On Mon, 13 Oct 2008 19:05:43 +0200
 Maarten Maathuis [EMAIL PROTECTED] wrote:

 On Mon, Oct 13, 2008 at 5:52 PM,  [EMAIL PROTECTED] wrote:
  Recently I've got still-sealed CodeWarrior Gold 10
  which was released on 1994, and tried to build FreeType2
  by this very very old CW.
 
 Am i the only one who wonders why a 14 year old compiler is
 even relevant today?

 I think I'm the only one who tries 14 year old compiler to
 build FreeType2. The reason why I used such legacy compiler
 is: I wanted to make a CW project file in the oldest format.

 On 2005, I updated CodeWarrior project file in builds/mac
 from CW v7 format to CW v9 XML format - afterwards I received
 several claims that developers using CW v7/v8 could not use
 new project file due to format incompatibility. It's the
 reason why I've chosen such very legacy compiler, I expected
 the oldest format will serve to all CW users.

 Maybe there's another fundamental question: CW for MacOS is
 discontinued product and no longer supported, is it relevant?
 I don't have solid answer, but I have 3 reasons to maintain.

 * CW has been supported since the initial release of FreeType2.

 * Some binaries built by CW depends on Metrowerks' own libc,
  the binaries built by MPW C compilers are not guaranteed
  to be the replacements.

 * At present, the cost to maintain CW files in FreeType2 is
  still payable for me.

 If FreeType2 had never supported CW (or had removed by other
 maintainers), I ought not to add CW support by myself.

 Regards,
 mpsuzuki


 ___
 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] new API introduced (FT_Get_Advances)

[David Turner]

Hello everyone,

just to let you know that I just introduced in the CVS depot a new API (and
corresponding header)
to be able to more quickly retrieve the advance width of individual glyphs
without loading their
outlines.

the new header file if FT_ADVANCES_H  (a.k.a. freetype/ftadvanc.h) and
provides two new APIs
(see copy of the header file with docs below).

the 'ftbench' demo program has also been updated with a new test that
exercise the new APIs
in both normal and fast mode (see below).

this works as follows:

when using a strongly hinted mode (either auto-hinted or bytecoded), this
does perform the hinting
and retrieves the advance(s) after that. this is slightly faster (about
10-20%) than doing successive
FT_Load_Glyph() calls, depending on the font backend being used.

however, when using no scaling, no hinting or even the light hinting mode
(which only hints in the
vertical dimension), the function can return results *immediately*  simply
looking the values in the font
file itself, if the font driver supports it. I have added support for this
in the TrueType / Type1 and CFF
font drivers. I still need to add CID and PFR support (I really don't think
Type42 is needed)

here are some runs of the new 'ftbench' on one of my work machines:

$ objs/ftbench /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
Load  : 19.415 us/op
*Load_Advances (Normal): 16.327 us/op*
*Load_Advances (Fast)  : 0.034 us/op*
Render: 6.285 us/op
Get_Glyph : 1.077 us/op
Get_CBox  : 0.539 us/op
Get_Char_Index: 0.074 us/op
Iterate CMap  : 35.950 us/op
New_Face  : 100.482 us/op
Embolden  : 0.000 us/op

$ objs/ftbench /usr/share/fonts/type1/t1-xfree86-nonfree/cour.pfa
Load  : 21.810 us/op
*Load_Advances (Normal): 13.508 us/op*
*Load_Advances (Fast)  : 0.080 us/op*
Render: 8.756 us/op
Get_Glyph : 1.190 us/op
Get_CBox  : 0.118 us/op
Get_Char_Index: 0.057 us/op
Iterate CMap  : 31.968 us/op
New_Face  : 1855.956 us/op
Embolden  : 0.222 us/op

feel free to comment on the API and suggest improvements if you see any
problem here.

Regards,

- David


copy of the new header file below:


/*/
  /*
*/
  /* Const
*/
  /*FT_ADVANCE_FLAG_FAST_ONLY
*/
  /*
*/
  /* Description
*/
  /*a bit-flag to be or-ed to the 'flags' parameter of the
*/
  /*@FT_Get_Advance and @FT_Get_Advances.
*/
  /*
*/
  /*when set, it indicates that you want these functions to fail
*/
  /*if the corresponding hinting mode or font driver doesn't
*/
  /*allow for very quick advance computation.
*/
  /*
*/
  /*typically, unscaled, unhinted, bitmapped and light-hinted glyphs
*/
  /*can have their advance width(s) computed very quickly.
*/
  /*
*/
  /*not so for normal and bytecode hinted modes, which require
*/
  /*loading/scaling/hinting the glyph outline instead, which is
*/
  /*extremely slow by comparison
*/
  /*
*/
#define  FT_ADVANCE_FLAG_FAST_ONLY   0x2000U



/*/
  /*
*/
  /* Function
*/
  /*FT_Get_Advance
*/
  /*
*/
  /* Description
*/
  /*Retrieve the advance of a given glyph outline in a @FT_Face.
*/
  /*by default, the unhinted advance is returned in font units
*/
  /*
*/
  /* Input
*/
  /*face   :: source @FT_Face handle
*/
  /*gindex :: glyph index
*/
  /*load_flags :: a set of bit-flags similar to those used
*/
  /*  when calling @FT_Load_Glyph, used to determine
*/
  /*  what kind of advances you need.
*/
  /* Output
*/
  /*padvance :: the advance value, in either font units or 16.16
*/
  /*format.
*/
  /*
*/
  /*if @FT_LOAD_VERTICAL_LAYOUT is set, this is the
*/
  /*vertical advance corresponding to a vertical layout.
*/
  /*otherwise, it's the horizontal advance in an
*/
  /*horizontal layout.
*/
  /* Return
*/
  /*FreeType error code.  0 means success.
*/
  /*
*/
  /* Note
*/
  /*This function may fail if you use @FT_ADVANCE_FLAG_FAST_ONLY and
*/
  /*if the corresponding's font backend doesn't have a quick way to
*/
  /*retrieve the advances.
*/
  /*
*/
  /*A scaled advance is returned in 16.16 format, but isn't
*/
  /*transformed by the affine transform specified by @FT_Set_Transform
*/
  /*
*/
  FT_EXPORT( FT_Error )
  FT_Get_Advance( FT_Faceface,
  FT_UIntgindex,
  FT_UIntload_flags,
  FT_Fixed  *padvance );


/*/
  /*
*/
  /* Function
*/
  /*FT_Get_Advances
*/
  /*
*/
  /* Description
*/
  /*