Re: [patch] Simplify ftconfig.h

2020-06-30 Thread Werner LEMBERG


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


Werner



Re: [patch] Simplify ftconfig.h

2020-06-30 Thread 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 ftconfig.h.in works])
 orig_CPPFLAGS="${CPPFLAGS}"
-CPPFLAGS="-I${srcdir} -I. -I${srcdir}/../../include/freetype/config ${CPPFLAGS}"
+CPPFLAGS="-I${srcdir} -I. 

Re: Gradient Color Fonts, COLR v1 Contributions to FreeType

2020-06-30 Thread Dominik Röttsches
Hi Werner,

thanks for the encouragement.

On Tue, Jun 30, 2020 at 10:40 AM Werner LEMBERG  wrote:

> > In a team effort with Roderick Sheeter & Cosimo Lupo & Dave Crossland
> > (Google Fonts) and myself (Blink/Chrome)
>
> ... and Behdad Esfahbod ...

Yes!

> Thanks.  Are there fundamental differences to the googledocs version at
>   
> https://docs.google.com/document/d/1EPndWsdMK_M135FOIxQZ--dHpH727rXEBvLZqgIzZvs/edit?ts=5de68042#heading=h.no8g2ykeo8za

I don't think there are major differences, we moved it to GitHub to
allow public comments and issue tracking.

Dominik



Re: Gradient Color Fonts, COLR v1 Contributions to FreeType

2020-06-30 Thread Werner LEMBERG


> In a team effort with Roderick Sheeter & Cosimo Lupo & Dave Crossland
> (Google Fonts) and myself (Blink/Chrome)

... and Behdad Esfahbod ...

> we have proposed and published an OpenType extension to the COLR
> table to bring color gradients to color vector fonts.

Thanks.  Are there fundamental differences to the googledocs version
at

  
https://docs.google.com/document/d/1EPndWsdMK_M135FOIxQZ--dHpH727rXEBvLZqgIzZvs/edit?ts=5de68042#heading=h.no8g2ykeo8za

which even I have made suggestions to?

> I've started prototyping support for the COLR v1 additions to FreeType
> in a local repository.

Great!  Looking forward to your code :-)


Werner



Gradient Color Fonts, COLR v1 Contributions to FreeType

2020-06-30 Thread Dominik Röttsches
Hi,

In a team effort with Roderick Sheeter & Cosimo Lupo & Dave Crossland
(Google Fonts) and myself (Blink/Chrome) we have proposed and
published an OpenType extension to the COLR table to bring color
gradients to color vector fonts.

You can find the proposal here:
https://github.com/googlefonts/colr-gradients-spec/blob/master/colr-gradients-spec.md

Initial test/prototype fonts have been published here:
https://github.com/googlefonts/color-fonts

The proposal is an incremental, backwards compatible extension to the
COLR table and brings gradients to color fonts while enabling support
for OpenType variations on all aspects of the gradient definitions.

I've started prototyping support for the COLR v1 additions to FreeType
in a local repository. Once I am making further progress, I would like
to share a proposal for API additions to FreeType in the section
that's described as "Glyph Layer Management" in the API docs for
review. Initially, the main focus would be to expose gradient
information in a way similar to an extended FT_Get_Color_Glyph_Layer
method, so that the gradient specifications can be extracted and
painted at higher levels, for example in our Skia graphics library.

Once I have something to present, I'd be happy if FreeType maintainers
and reviewers could take a look and ensure it fits FreeType's
conventions and existing style, and decide if such contributions could
be merged to the FreeType project.

If you have any questions on COLR v1, I'll try to answer those and I'd
be happy to hear any thoughts and feedback so far,

Dominik