Re: Logging Library-GSOC

[Werner LEMBERG]

> Also I have updated the progress report for 3rd week @ here
> 

Thanks!  The recent discussion with Behdad reminded me to ask you
whether you have also investigated the case where you modify the
existing debugging and tracing code of FreeType without using an
external library.  For example, such new code might be based on the
code from 'dlg' but stripped down to the bare features we would like
to see.


Werner

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 >> conftest.c "#if FT_SIZEOF_INT == "${ac_cv_sizeof_int}
 echo >> conftest.c "ac_cpp_ft_sizeof_int="${ac_cv_sizeof_int}
@@ -1158,15 +1158,7 @@ 

Re: [patch] Simplify ftconfig.h

[Alexei Podtelezhnikov]

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.

[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
 #define FT_ULONG_MAX ULONG_MAX
-#include "ftconfig.in"
+#include 

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: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Alexei,

> You probably mean the slight "pulsing" inside. You are right, it
> should not happen. It might be the same effect as the one apparent on
> the miter line, or I am just seeing things.

Yes, it's kind of like discontinuities in the distances. I'll share a
screenshot once I subdivide the conic curve.

> The 8x8 neighborhood has larger distances diagonally than vertically
> or horizontally so they (like all distances) have to be clamped
> accordingly. You should probably also preset (memset) the grid to the
> same cutoff value with appropriate sign for the outside. Keep in mind
> that orientations are different for TrueType and Type1/CFF.

Yeah, I was not clamping them before. Now it looks good apart from the
sign.

> Even if you preset the field to an appropriately signed cutoff, there
> might still be unvisited inside regions of opposite signs. Those can
> be found by one pass over looking for large discontinuities, easily
> fixable by flipping the sign.

Yeah, even I was thinking of doing a single pass of all the rows from left
to right, flipping the distances as I go along. So I will try to implement
it
next. The corner checking still stands, it can't be avoided because at
corners
two lines give opposite signs, so to resolve this the corner checking has
to be
done.

>> Lastly, instead of checking the 8x8 neighborhood of the line segments, I
calculated the
>> bounding box of the line, increased it by 8 in the x and y direction and
used that to
>> calculate the distances. It is still very fast and doesn't result in
that hard edge (https://i.imgur.com/24Rz8eV.png).
>> We can even align the bounding box along the line and create a pretty
tight space. I
>> think it is worth giving it a try as well.
>
> Sure, I like it. This is a good test if splitting is worth anything.

Meanwhile here is the performance of using bounding box:
So, I generated 100 glyphs with a pixel size of 256 (which
in my opinion is more than enough for SDF) using a spread of
16:

* the previous method (checking all grid points): took 18.296 seconds for
all glyphs ( ~182 ms average )
* the bounding box method: took 1.487 seconds for all glyphs ( ~14.8 ms
average )

[I did the test on a ttf font so it only contains lines and conic curves]
They look exactly the same. Moreover the bounding box method can be made
even
faster by aligning it properly.

So, the next thing I'll do is the single pass phase to determine the sign of
unchecked grid points, and then I'll try the subdividing. The code is a
little
messed up right now, so I'll probably push it in 2-3 days.

Also, I was working on the integration part today. I added functionality
to set renderer properties (namely the `spread' parameter).  So, there is
API for this `FT_Property_Set' and `FT_Property_Get'. Is there any similar
API for setting the renderer specific modes which is defined by the
`FT_Renderer_SetModeFunc'
function, or do I get the module from `FT_Get_Module' (`FT_Get_Renderer'
will not return `sdf'
renderer because it has same glyph format as the `smooth' renderer) and
then call the
function manually ?

Thanks for your comments

Re: GSOC Build tests

[Greg Williamson]

Over the past couple weeks I've converted the build tests to use autotools
for the three desktop OSes. I've managed to leave the cmake tests intact
too.  I also now have demos building against the freetype version pulled in
the CI. I wasted quite a bit of time trying to get autotools to work with
MSVC to no avail so if anyone has had success with it please let me know.
You can see a preview of the updated build tests here:
https://dev.azure.com/fundies/freetype2/_build/results?buildId=195.
However, the mingw builds are currently failing because it seems their repo
is in process of updating but I promise that it worked before :). I've
tried to structure the CI's yaml config in a way that it will be easy to
add tests for other build systems for the future when you switch to meson
or whatever. I think with the current configuration I'm hitting most build
configurations but we can always add more later. Over the coming week I
plan to write some functionality tests. I believe my best course of action
for this is just to use the existing freetype demo programs in tandem with
some bash scripting to check for inconsistencies in various fonts between
commits. I will hope to have some tests and some of the UI for manual
inspection of failures ready by early next week.

On Sun, Jun 7, 2020 at 6:46 AM Alexei Podtelezhnikov 
wrote:

>
> >> 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 GUI programs are compiled with a GUIless batch driver. In ftview,
> ftstring, ftggrid it is even usable with “-k Pq” for example. The other GUI
> progs are ftgamma, ftmulti, and ftdiff. There are and console ftdum,
> ftbench and ttdebug in good shape.  The rest are not much used and rather
> obsolete.
>
>