Re: [freetype2] master 576403f 1/2: [builds] Relocate `FTMODULE_H'.

[Jan Alexander Steffens]

Hi,

My latest nightly failed to install (after make). It does not use a
separate builddir.

Log from `make install`:

rm -rf /build/freetype2-git/pkg/freetype2-git/usr/include/freetype2
rm -f /build/freetype2-git/pkg/freetype2-git/usr/include/ft2build.h
/usr/bin/mkdir -p /build/freetype2-git/pkg/freetype2-git/usr/lib
\

/build/freetype2-git/pkg/freetype2-git/usr/lib/pkgconfig
  \

/build/freetype2-git/pkg/freetype2-git/usr/include/freetype2/freetype/config
\

/build/freetype2-git/pkg/freetype2-git/usr/share/aclocal
./builds/unix/libtool --mode=install /usr/bin/install -c
  \

/build/freetype2-git/src/freetype2/objs/libfreetype.la
/build/freetype2-git/pkg/freetype2-git/usr/lib
libtool: install: /usr/bin/install -c
/build/freetype2-git/src/freetype2/objs/.libs/libfreetype.so.6.17.4
/build/freetype2-git/pkg/freetype2-git/usr/lib/libfreetype.so.6.17.4
libtool: install: (cd /build/freetype2-git/pkg/freetype2-git/usr/lib
&& { ln -s -f libfreetype.so.6.17.4 libfreetype.so.6 || { rm -f
libfreetype.so.6 && ln -s libfreetype.so.6.17.4 libfreetype.so.6; };
})
libtool: install: (cd /build/freetype2-git/pkg/freetype2-git/usr/lib
&& { ln -s -f libfreetype.so.6.17.4 libfreetype.so || { rm -f
libfreetype.so && ln -s libfreetype.so.6.17.4 libfreetype.so; }; })
libtool: install: /usr/bin/install -c
/build/freetype2-git/src/freetype2/objs/.libs/libfreetype.lai
/build/freetype2-git/pkg/freetype2-git/usr/lib/libfreetype.la
libtool: warning: remember to run 'libtool --finish /usr/lib'
for P in /build/freetype2-git/src/freetype2/include/freetype/freetype.h
/build/freetype2-git/src/freetype2/include/freetype/ftadvanc.h
/build/freetype2-git/src/freetype2/include/freetype/ftbbox.h
/build/freetype2-git/src/freetype2/includ>
  /usr/bin/install -c -m 644\
$P 
/build/freetype2-git/pkg/freetype2-git/usr/include/freetype2/freetype
; \
done
for P in /build/freetype2-git/src/freetype2/include/freetype/config/ftconfig.h
/build/freetype2-git/src/freetype2/include/freetype/config/ftheader.h
/build/freetype2-git/src/freetype2/include/freetype/config/ftmodule.h
/build/freetype2-g>
  /usr/bin/install -c -m 644   \
$P 
/build/freetype2-git/pkg/freetype2-git/usr/include/freetype2/freetype/config
; \
done
/usr/bin/install -c -m 644
/build/freetype2-git/src/freetype2/include/ft2build.h
\
  
/build/freetype2-git/pkg/freetype2-git/usr/include/freetype2/ft2build.h
/usr/bin/install -c -m 644 ./builds/unix/ftconfig.h\
  
/build/freetype2-git/pkg/freetype2-git/usr/include/freetype2/freetype/config/ftconfig.h
/usr/bin/install -c -m 644
/build/freetype2-git/src/freetype2/objs/ftmodule.h
 \
  
/build/freetype2-git/pkg/freetype2-git/usr/include/freetype2/freetype/config/ftmodule.h
/usr/bin/install: cannot stat
'/build/freetype2-git/src/freetype2/objs/ftmodule.h': No such file or
directory
make: *** [/build/freetype2-git/src/freetype2/builds/unix/install.mk:45:
install] Error 1

On Fri, Jan 8, 2021 at 7:24 AM Werner LEMBERG  wrote:
>
>
> Alexei,
>
>
> > + * builds/toplevel.mk: Place `FTMODULE_H' in include/.
>
> Have you tested this commit on a Unix box with a build where 'srcdir'
> != 'builddir', and where 'srcdir' is read-only?  My gut feeling says
> that your commit is not correct.
>
> We have the following rules, which I consider the right way.
>
> * Files that can be configured by the user should be read first from
>   `builddir`, overriding the locations in `srcdir` (examples:
>   `modules.cfg`, `ftoption.h`).
>
> * Files that are auto-generated at configure time must always be
>   placed into `builddir` (example: `config.mk`).
>
> I want that this scheme works for *all* build systems (i.e., autoconf,
> GNU make, meson, cmake) – well, I guess that VC++ is different...
>
> In other words, this change
>
>   -INCLUDES := $(subst /,$(COMPILER_SEP),$(OBJ_DIR) \
>   -  $(DEVEL_DIR) \
>   +INCLUDES := $(subst /,$(COMPILER_SEP),$(DEVEL_DIR) \
>  $(BUILD_DIR) \
>  $(TOP_DIR)/include)
>
> looks very suspicious :-)
>
>
> Werner

Re: SDF format

[Jan Alexander Steffens]

On Sun, Dec 27, 2020, 20:41 Anuj Verma  wrote:

> Hello Alexei,
>
> *> [...] I went searching for *practical* examples on the internet and*
> *> found very few.*
>
> There are quite a few examples on youtube, and most of them use 8-bit
> buffers to represent SDF.
>
>
>
>
> *> This blog post>
> https://blog.mapbox.com/drawing-text-with-signed-distance-fields-in-mapbox-gl-b0933af6f817
> 
> > and some others refer to OpenGL textures as the next step, Their > format
> is unclear to me but it seems that we should align.*
>
> I don't think we have to align the format with OpenGL. We can convert
> the SDF data to any format in OpenGL, so I don't think we need to align.
> In the blog you mentioned the OpenGL texture format is probably GRAY8.
>
> *> The blog post that I mentioned is okay with GRAY8 unevenly split at
> 192,*
>
> *> which brings the question of units too. The units or scale of SDF do
> not > seem to be important. *
>
> For most cases negative values are simply ignored, therefore uneven
> splitting
> is okay. But, that might not be the case in every scenario. The units are
> not
> important, as long we can create acceptable interpolation to render text.
>
> * > Finally, I am not sure if you realize that FreeType gray coverage*
>
> *> [...] I wonder if we really need 16 bits for acceptable >
> interpolation. Probably not.*
>
> I do know about the FreeType's antialiased rendering, the 'bsdf' renderer
> takes advantage of the coverage values to generate SDF.
>
> As for the number of bits, even behdad told me that 8 bits is enough to
> produce respectable rendering:
> https://lists.nongnu.org/archive/html/freetype-devel/2020-06/msg00118.html
> And even some other SDF generators use 8 bits to represent the final SDF
> output data :
>  - https://github.com/libgdx/libgdx/wiki/Distance-field-fonts
>  - https://github.com/rougier/freetype-gl/blob/master/distance-field.c
> I did test 8 bit SDF today, and the final rendering output is
> similar to 16 bit. For my testing I used 3.5 fixed point representation,
> similar to what is used in skia. (
> https://lists.nongnu.org/archive/html/freetype-devel/2020-06/msg9.html
> )
>
> Finally, we can definitely use 8 bit output to represent SDF and render
> acceptable text using it. Now, we can either eliminate the current 16 bit
> output, or, we can keep both 16 and 8 bit output. What do you think will be
> the better option ? I think we should keep a single output (probably 8 bit)
> and later add an option to directly output floating point data (if we
> decide
> to add floating point calculations to FreeType)
>
> Anuj
>

Isn't the renderer implementing a multi-channel SDF scheme? I thought I saw
multi-channel mentioned in a commit message.

I stumbled upon multi-channel at  https://github.com/Chlumsky/msdfgen where
the readme seems to imply simple 8-bit single-channel SDFs aren't
satisfactory.

>

[PATCH] [freetype2] Fix documentation build.

[Jan Alexander Steffens (heftig)]

The empty line after `* @description:` caused the refdoc build to fail,
see

  https://github.com/freetype/docwriter/issues/77
---
 include/freetype/ftimage.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/freetype/ftimage.h b/include/freetype/ftimage.h
index a759e1399..5e2257f96 100644
--- a/include/freetype/ftimage.h
+++ b/include/freetype/ftimage.h
@@ -785,7 +785,6 @@ FT_BEGIN_HEADER
*   How vectorial outlines are converted into bitmaps and pixmaps.
*
* @description:
-
*   A raster or a rasterizer is a scan converter in charge of producing a
*   pixel coverage bitmap that can be used as an alpha channel when
*   compositing a glyph with a background.  FreeType comes with two
@@ -1054,7 +1053,7 @@ FT_BEGIN_HEADER
*   An opaque handle (pointer) to a raster object.  Each object can be
*   used independently to convert an outline into a bitmap or pixmap.
*
-   * @note
+   * @note:
*   In FreeType 2, all rasters are now encapsulated within specific
*   @FT_Renderer modules and only used in their context.
*
-- 
2.29.2

[PATCH] [freetype2-demos] * Makefile (COMPILE): Use same order of flags as freetype2

[Jan Alexander Steffens (heftig)]

This ensures the includedir for the built FreeType comes first, before
any flags for a system FreeType which was pulled in through pkg-config
for harfbuzz.
---
 Makefile | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 8e4ca56..e6ad0af 100644
--- a/Makefile
+++ b/Makefile
@@ -130,10 +130,10 @@ else
  $(TOP_DIR)/include \
  $(SRC_DIR)
 
-  COMPILE = $(CC) $(CPPFLAGS) \
-  $(CFLAGS) \
-  $(ANSIFLAGS) \
-  $(INCLUDES:%=$I%)
+  COMPILE = $(CC) $(ANSIFLAGS) \
+  $(INCLUDES:%=$I%) \
+  $(CPPFLAGS) \
+  $(CFLAGS)
 
   # Enable C99 for gcc to avoid warnings.
   # Note that clang++ aborts with an error if we use `-std=C99',
-- 
2.27.0

Re: [ft-devel] what FT_Color

[Jan Alexander Steffens]

On Mon, Feb 25, 2019 at 4:14 PM Alexei Podtelezhnikov 
wrote:

> The next FreeType release will introduce FT_Color, which is a big
> deal. Currently it represents color as common 32-bit RGBA structure.
> What is your opinion about SVG color gradients?
>
> Do we need to consider a more complex color structure with full
> description of color gradients?
> Or, alternatively, should we reference color gradients by an index
> within FT_Color?
>

I think this feature was added to support COLR/CPAL fonts, which only have
flat colors; the only use for gradients would thus be proper SVG. Given the
complexity of SVG I don't think it's a good idea to attempt to decompose it
into a set of shape layers with gradient descriptions. I think applications
would rather consume the SVG directly.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] How to port freetype2 to a system without file system

[Jan Alexander Steffens]

Yes, see FT_CONFIG_OPTION_DISABLE_STREAM_SUPPORT in
include/freetype/config/ftoption.h.

You can load faces from memory using FT_New_Memory_Face.

On Mon, Mar 12, 2018 at 4:57 PM duhuanpeng <548708...@qq.com> wrote:

> Hello,
>
> I have ported freetype2 to our system. Our system don't supports file
> system,
> so I write some functions to emulate file operations.
> > fopen,  fread, etc.
> But now I maintain a "FILE" array, it eats a lot memory.
>
> Is there any better way to port freetype2?
> Our fonts are store in flash, it appears like a normal array.
> like:
>   extern char font1[];
>   extern char font2[];
>
>
> (actually, I store multi font files in a single romfs image block.)
>
> Regards,
> duhuanpeng
>
>
>
>
>
> ___
> 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] merged CFF and Type1 hinting code now in master

[Jan Alexander Steffens]

On Sat, Oct 21, 2017 at 9:27 PM Nikolaus Waxweiler 
wrote:

> > Is this the scheme that you are proposing?
> >
> >   LIGHTNORMAL
> > TrueType  Auto v40
> > CFF   AdobeAdobe
> > Type 1AdobeAdobe
>
> Yup. My proposal makes the scheme more consistent, as Type1 and CFF get
> the same treatment. The CFF hinting engine does not even support x-axis
> changes as Dave explained some time ago, so LIGHT and NORMAL is already
> meaningless for Type1/CFF fonts. It may gain meaning if someone
> implements x-axis-hinting.
>
> > You are one step away from ditching NORMAL or LIGHT altogether. Is this
> > you intent?
>
> I wish.
>
> As a connoisseur of beautiful type, I'm a true believer of the Adobe CFF
>  hinting engine school of thought that changes as little as possible to
> strike a balance between low DPI clarity and the type's design. That's
> the spirit of LIGHT. The autohinter is LIGHT, too, but has a guessing
> element to it that is not there with the "native CFF hints", which is
> why I prefer to see the native engine in LIGHT mode.
>
> Given that the hinting strategy used for a TrueType font (light,
> x-and-y-changes, bludgeoning the shapes into monochrome bitmaps) is up
> to the designer, it's very hard to make FT output harmonious and
> consistent looking text regardless of source (a standard Linux distro
> ships stuff in all three scalable font formats). This is why I'd love to
> have the bytecode engine out of the picture, but I understand it has
> its' place.
>
> Remember: When I started this crusade, I first tried to implement
> hinting engine selection in fontconfig. Hardcoded and inconsistent
> assumptions in fontconfig-using GUI toolkits made that impossible
> however, so I opted for changing FreeType.
>

I originally suggested allowing LIGHT to use the Adobe hinter because the
results were so close to the autohinter already. If we want to tie
LIGHT/NORMAL to the style of hinting used (y vs x+y), I wonder if it would
make sense to use the autohinter in full x+y mode for NORMAL, so the table
becomes:

  LIGHTNORMAL
TrueType  Auto Bytecode
CFF   AdobeAuto
Type 1AdobeAuto
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] merged CFF and Type1 hinting code now in master

[Jan Alexander Steffens]

On Mon, Sep 25, 2017 at 9:31 AM Werner LEMBERG  wrote:

>
> I've just committed Ewald's GSoC project to master.  Please test!
>

Nice!

Shouldn't the T1 driver get the FT_MODULE_DRIVER_ HINTS_LIGHTLY flag now,
too?
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] glyph metrics don't match bitmap size (2.8.1)

[Jan Alexander Steffens]

On Tue, Sep 19, 2017, 07:25 Nicolas Jinchereau 
wrote:

> Thanks for the quick responses.
>
> I've managed to render text correctly now using LCD filtering (the new
> 2.8.1 version). I was able to do it by ignoring the glyph metrics and using
> the bitmap size itself. This works well enough for now, and the text looks
> great, but I would like to be able to retrieve final dimensions of the
> bitmap without actually rendering/allocating anything, so I can calculate
> the layout of a bitmap-font/texture-atlas, and blit the glyphs afterward.
> I've been doing this for while and only ran into a problem when I tried the
> new LCD filtering.
>
> I understand why the padding would be needed, but why wouldn't it be
> included in the glyph metrics (width/height)?
>

Because the layout shouldn't change just because the glyphs got blurred.
The bitmap_left and bitmap_top fields will tell you the offset of the
bitmap from the pen position on the baseline. (The pen position is adjusted
by the advance width of each glyph after drawing it, usually further
modified by kerning from layers above FreeType.)
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] glyph metrics don't match bitmap size (2.8.1)

[Jan Alexander Steffens]

On Tue, Sep 19, 2017 at 4:13 AM Nicolas Jinchereau <
nicolas.jincher...@gmail.com> wrote:

> When using FT_LOAD_TARGET_LCD, the size of the rendered bitmap doesn't
> seem to match the size in the metrics. It's usually off by 1~2 units - is
> this normal?
>
> Example:
>
> #include 
> #include FT_FREETYPE_H
> #include FT_LCD_FILTER_H
>
> int main()
> {
> FT_Library _library;
> FT_Init_FreeType(&_library);
> FT_Library_SetLcdFilter(_library, FT_LCD_FILTER_DEFAULT);
>
> FT_Face face;
> FT_New_Face(_library, "arial.ttf", 0, );
> FT_Set_Pixel_Sizes(face, 0, 14);
>
> FT_Int32 flags = 0;
> flags |= FT_LOAD_TARGET_LCD;
> flags |= FT_LOAD_RENDER;
>
> string sample =
> "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
>
> for(char c : sample)
> {
> FT_Load_Char(face, (int)c, flags);
> cout << (face->glyph->bitmap.width / 3) << " ==? ";
> cout << (face->glyph->metrics.width >> 6) << endl;
> }
>
> FT_Done_Face(face);
> return 0;
> }
>
> Any help with this would be appreciated
>

I assume you used to build 2.8 and earlier without subpixel rendering. In
that case, FT_LOAD_TARGET_LCD doesn't really do LCD rendering and just
gives you bitmaps three times wider without increasing the resolution.

With "subpixel rendering" enabled, glyphs are rendered at higher resolution
with LCD filtering which blurs the image horizontally. This requires up to
one pixel (three bitmap columns) of padding at each side.

With "subpixel rendering" disabled, 2.8.1 now includes a patent-free LCD
rendering technique which does not use filters but effectively multisamples
the outline. It has similar padding requirements.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Haarmony LCD rendering

[Jan Alexander Steffens]

On Wed, Aug 9, 2017 at 3:50 PM Alexei Podtelezhnikov 
wrote:

> On Wed, Aug 9, 2017 at 6:15 AM, Markus Trippelsdorf <
> mar...@trippelsdorf.de> wrote:
> > Yes, the fix is already in Chromium, but Firefox needs it, too:
> >
> https://skia.googlesource.com/skia/+/d1f2d15b36f6a6a9d199581b998a7ca924a1f1a8%5E%21/
>
> I strongly suspect that this fix is inadequate. Skia continues to
> pre-allocate the buffer too early. The fix just fits the FreeType
> buffer in the pre-allocated space. It happens to work for ClearType
> because we shrunk our buffer in this case. The default LCD image, on
> the other hand, is now a bit larger, so it won't fit in the
> pre-allocated space. I do not understand why Skia pre-allocates the
> buffer instead of just taking what FreeType returns. That would be a
> better fix.
>

It is indeed inadequate. I just tested a patched Firefox Nightly against
FreeType master, with old and new LCD rendering. Old looks fine but Harmony
still has some chopped glyphs.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Haarmony LCD rendering

[Jan Alexander Steffens]

On Wed, Aug 9, 2017 at 5:11 AM Alexei Podtelezhnikov 
wrote:

> What do you think?


Great! As it's in master now I've given it a try. Unfortunately, it seems
Firefox now cuts off many glyphs on the right side. A lowercase i or l can
become almost invisible.

On Wed, Aug 9, 2017 at 8:15 AM Markus Trippelsdorf 
wrote:

> What about vrgb rendering?
>

Looking at the code, it seems that vertical orientation is covered.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] C99, long long, and inline

[Jan Alexander Steffens]

On Mon, Sep 12, 2016 at 3:35 PM Alexei Podtelezhnikov 
wrote:

> *inline*
> Freetype smooth rasterizer is very nested. I seems to me that gcc
> selects some inlining scheme. Does anyone know how to check this? I
> would like to have some control over inlining, which can be useful for
> performance tuning.
>

With -O2, it only considers functions declared inline, very small functions
and functions called once. With -O3, any function can be inlined. In any
case, functions may not be inlined.

Functions with __attribute__((always_inline)) are always inlined.
Functions with __attribute_((noinline)) are never inlined.


> Anyway, I am for the jump to C99 in 2.8.
>

I think MSVC is still not fully C99-compliant. long long should be there,
though.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Something in 2.6.4 broke my windows fonts

[Jan Alexander Steffens]

On Thu, Jul 7, 2016 at 9:38 PM Werner LEMBERG  wrote:

> > Shouldn't thus envvar in question be named 'FT2_PROPERTIES'?
>
> Maybe, but `FREETYPE' is more meaningful than `FT2' for the common
> man, I guess :-)
>

For the record, I did some evil downstream patchery and introduced
FT2_SUBPIXEL_HINTING a few versions ago, recently extended for 2.6.4:

https://git.archlinux.org/svntogit/packages.git/tree/trunk/0003-Make-subpixel-hinting-mode-configurable.patch?h=packages/freetype2
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Experimental: v38 interpreter with minimal backwards compatibility mode and linear advance widths

[Jan Alexander Steffens]

On May 18, 2016 7:12 AM, "Werner LEMBERG"  wrote:
> There's one issue, though.  Have a look at Ins_MIAP: I have changed
> your diff
>
>   -#ifdef TT_CONFIG_OPTION_SUBPIXEL_HINTING
>   +#ifdef TT_SUPPORT_SUBPIXEL_HINTING_INFINALITY
>  /* Only adjust if not in sph_compatibility_mode or
ignore_x_mode. */
>  /* Determined via experimentation and may be incorrect...
 */
>   -  if ( !SUBPIXEL_HINTING  ||
>   +  if ( SUBPIXEL_HINTING_INFINALITY&&
>   ( !exc->ignore_x_mode||
> !exc->face->sph_compatibility_mode ) )
>   -#endif /* TT_CONFIG_OPTION_SUBPIXEL_HINTING */
>   +#endif /* TT_SUPPORT_SUBPIXEL_HINTING_INFINALITY */
>
> to
>
>   -#ifdef TT_CONFIG_OPTION_SUBPIXEL_HINTING
>   +#ifdef TT_SUPPORT_SUBPIXEL_HINTING_INFINALITY
>  /* Only adjust if not in sph_compatibility_mode or
ignore_x_mode. */
>  /* Determined via experimentation and may be incorrect...
 */
>   -  if ( !SUBPIXEL_HINTING  ||
>   -   ( !exc->ignore_x_mode||
>   - !exc->face->sph_compatibility_mode ) )
>   -#endif /* TT_CONFIG_OPTION_SUBPIXEL_HINTING */
>   +  if ( !( SUBPIXEL_HINTING_INFINALITY   &&
>   +  ( exc->ignore_x_mode&&
>   +exc->face->sph_compatibility_mode ) ) )
>   +#endif /* TT_SUPPORT_SUBPIXEL_HINTING_INFINALITY */
>
> to retain the original logic.  Please check.

This is weird. The original logic doesn't fit its comment and will adjust
if either ignore X mode or face SPH compat mode is disabled, not when both
are disabled as suggested.

Maybe this should be !(SUBPIXEL_HINTING_INFINALITY && (exc->ignore_x_mode
|| exc->face->sph_compatibility_mode)).

On the other hand, if this has been determined via experimentation, maybe
the comment is wrong and should read "Skip adjusting if in both
sph_compatibility_mode and ignore_x_mode" instead.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] Autohinter, Cantarell-Regular, 14ppem: dot on i and j on different grids, ascenders of d not snapped to zone

[Jan Alexander Steffens]

On Sun, Jan 31, 2016 at 2:28 PM, Werner LEMBERG  wrote:
>> Since this is an .otf and you can't force the autohinter in light
>> rendering mode (bug).
>
> Care to provide a fix?  It was you who made the auto-hinter use the
> new CFF engine in light hinting mode :-)

It was me, actually. And according to the code, forcing autohint (via
FT_LOAD_FORCE_AUTOHINT) should still work fine, see ftobjs.c:674.

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

Re: [ft-devel] Turning off stem darkening by default until all drivers support it?

[Jan Alexander Steffens]

On Thu, Jan 14, 2016 at 12:29 PM, Werner LEMBERG  wrote:
>> To you and your model of the world, these might "act globally on
>> many faces".  To a fontconfig-using-, or cairo, or Chrome, or
>> Firefox, or Skia, or Android, or Qt, or any other large-enough
>> platform, there's no global setting, there's just per-face
>> configuration that needs to be enabled.  If you push that to
>> FT_Library, that makes FT_Library thread-unsafe and bound to one
>> face at a time.
>
> I don't understand your reasoning.  FontConfig, for example, doesn't
> provide an `FT_Library' object to a client that queries font
> information, AFAIK.  An application has to call `FT_Init_FreeType' by
> itself, then deriving all `FT_Face' objects from the just created
> `FT_Library' object.  Ditto for Qt (where a call to `FT_Init_FreeType'
> is hidden by an application's Qt initialization).  How can this be
> thread-unsafe?  What am I missing?  Please provide a real-world
> example that helps me understand your concerns.

I'm not sure, too. Maybe applications mutex-protect FT_{New,Done}_Face
rather than use one FT_Library per thread, as the documentation
recommends?

Altering any settings on FT_Library while other threads use FT_Faces
created from it causes data races, unless you protect all the calls on
the Library *and* the Faces with the mutex.

Even then, while you might not get any corruption, you still have a
shared rendering state that might get changed unexpectedly.

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

Re: [ft-devel] rendering speedup

[Jan Alexander Steffens]

On Fri, Nov 20, 2015 at 4:30 PM,   wrote:
> Regarding the "right way", I agree that environment variables are to be
> avoided but maybe not completely i.e. allowing just one to select from the
> various built-in sets of settings and/or pointing to a user specific custom
> settings file.

No, they're to be avoided completely. FreeType has to work on systems
that have no environment variables and no file systems, so
configuration happens exclusively through the API.

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

Re: [ft-devel] Turning off stem darkening by default until all drivers support it?

[Jan Alexander Steffens]

On Wed, Nov 11, 2015 at 8:42 PM, Nikolaus Waxweiler  wrote:
> Thanks! Telling people to switch to slight hinting will be much easier than
> telling them to mess with fontconfig.

I suppose we still have time to add the suggested LOAD flag before the
2.7 release? IMO it should:

1) Switch on stem darkening
2) Change the default LCD filter weights as recommended on
   http://www.freetype.org/freetype2/docs/reference/ft2-lcd_filtering.html

Is this what it should do?

As for the name...

- FT_LOAD_LINEAR (probably too vague)
- FT_LOAD_INTEND_LINEAR_ALPHA_BLENDING_AND_GAMMA_CORRECTION (probably too long)
- FT_LOAD_LINEAR_LIGHT
- FT_LOAD_LINEAR_LIGHT_BLENDING
- FT_LOAD_FOR_LINEAR_LIGHT

More bikeshedding about a good name? It should be short and unambiguous.


On another note, what happens if FT_LCD_FILTER_LEGACY is requested but
not compiled in? Does it fall back to NONE or DEFAULT?

Disturbingly, I still get the legacy filter (which sucks) unless I'm
explicitly requesting another in fontconfig. I can probably blame
Cairo.

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

Re: [ft-devel] Turning off stem darkening by default until all drivers support it?

[Jan Alexander Steffens]

On Tue, Nov 10, 2015 at 9:24 AM, Nikolaus Waxweiler  wrote:
> I noticed that Liberation Sans/Serif/Mono and Open Sans looked pretty
> ClearType-y with hintfull

I think that is because they just choose not to do any (or much)
Y-snapping, even though they could, since they were designed with
FreeType in mind.

I believe the "ignore X mode" you get by default when SUBPIXEL_HINTING
is defined tries to get a ClearType-y result out of classic X-and-Y
fonts made for pre-ClearType engines. Though, that doesn't quite
explain why Segoe UI and Consolas are so terrible without it. Maybe
these fonts just weren't tested with old engines, or FreeType's
version 35 (w/o SUBPIXEL_HINTING) engine is still missing important
things.

Has anyone tried those fonts (Liberation, Open Sans, Segoe UI,
Consolas) on Windows 98? Would be nice to know if it shows the same
results, since it has the version 35 engine FreeType is trying to
emulate.

Also, isn't a version 35 engine only supposed to hint for mono
rendering, while we're doing symmetrical antialiasing here?
Analogously, the version 38 engine hints for the asymmetrically
smoothed rendering of ClearType.

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

Re: [ft-devel] Turning off stem darkening by default until all drivers support it?

[Jan Alexander Steffens]

On Tue, Nov 10, 2015 at 1:32 PM, Markus Trippelsdorf
 wrote:
> The big problem is that enabling linear blending is a compile time
> option for Qt 5. There is no way to control it at runtime AFAIK.

Isn't this is exactly what we want? A Qt built this way should pass
FT_LOAD_INTEND_LINEAR... to FreeType and expect all the output to be
appropriate for linear blending.

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

Re: [ft-devel] Turning off stem darkening by default until all drivers support it?

[Jan Alexander Steffens]

On Tue, Nov 10, 2015 at 2:03 PM, Nikolaus Waxweiler  wrote:
> I know it's a long ways out, but a compile time option shouldn't be a
> problem. Qt can check at compile time if FT delivers and distro packagers
> control Qt and FT version and compilation options anyway.

On Tue, Nov 10, 2015 at 2:06 PM, Nikolaus Waxweiler  wrote:
> Wait, this is an optional flag that libs have to use explicitly. So perfect
> backwards compatibility :)

Exactly. Any app or toolkit that doesn't know about this flag will get
pixels or outlines appropriate for legacy sRGB blending.

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

[ft-devel] [PATCH] Allow native CFF hinter in FT_RENDER_MODE_LIGHT

[Jan Alexander Steffens (heftig)]

This is, excepting whitespace adjustments, a pretty minimal
patch that makes Freetype use the native CFF hinter in
FT_RENDER_MODE_LIGHT, since these now have a very similar
rendering style.

Docs are adjusted to not mention that FT_LOAD_TARGET_LIGHT
implies FT_LOAD_FORCE_AUTOHINT anymore.
---
 include/freetype/freetype.h|  5 -
 include/freetype/ftmodapi.h| 15 +--
 include/freetype/internal/ftobjs.h |  3 +++
 src/base/ftobjs.c  |  3 ++-
 src/cff/cffdrivr.c |  7 ---
 5 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/include/freetype/freetype.h b/include/freetype/freetype.h
index b6247f5..c239f1b 100644
--- a/include/freetype/freetype.h
+++ b/include/freetype/freetype.h
@@ -2821,9 +2821,6 @@ FT_BEGIN_HEADER
*   have specified (e.g., the TrueType bytecode interpreter).  You can set
*   @FT_LOAD_FORCE_AUTOHINT to ensure that the auto-hinter is used.
*
-   *   Also note that @FT_LOAD_TARGET_LIGHT is an exception, in that it
-   *   always implies @FT_LOAD_FORCE_AUTOHINT.
-   *
* @values:
*   FT_LOAD_TARGET_NORMAL ::
* This corresponds to the default hinting algorithm, optimized for
@@ -2835,8 +2832,6 @@ FT_BEGIN_HEADER
* generated glyphs are more fuzzy but better resemble its original
* shape.  A bit like rendering on Mac OS~X.
*
-   * As a special exception, this target implies @FT_LOAD_FORCE_AUTOHINT.
-   *
*   FT_LOAD_TARGET_MONO ::
* Strong hinting algorithm that should only be used for monochrome
* output.  The result is probably unpleasant if the glyph is rendered
diff --git a/include/freetype/ftmodapi.h b/include/freetype/ftmodapi.h
index 544279a..89d9347 100644
--- a/include/freetype/ftmodapi.h
+++ b/include/freetype/ftmodapi.h
@@ -111,12 +111,14 @@ FT_BEGIN_HEADER
 #define FT_MODULE_HINTER  4  /* this module is a glyph hinter */
 #define FT_MODULE_STYLER  8  /* this module is a styler   */
 
-#define FT_MODULE_DRIVER_SCALABLE 0x100   /* the driver supports  */
+#define FT_MODULE_DRIVER_SCALABLE  0x100  /* the driver supports  */
   /* scalable fonts   */
-#define FT_MODULE_DRIVER_NO_OUTLINES  0x200   /* the driver does not  */
+#define FT_MODULE_DRIVER_NO_OUTLINES   0x200  /* the driver does not  */
   /* support vector outlines  */
-#define FT_MODULE_DRIVER_HAS_HINTER   0x400   /* the driver provides its  */
+#define FT_MODULE_DRIVER_HAS_HINTER0x400  /* the driver provides its  */
   /* own hinter   */
+#define FT_MODULE_DRIVER_HINTS_LIGHTLY 0x800  /* the driver's hinter  */
+  /* produces LIGHT hints */
 
 
   /* deprecated values */
@@ -125,9 +127,10 @@ FT_BEGIN_HEADER
 #define ft_module_hinter  FT_MODULE_HINTER
 #define ft_module_styler  FT_MODULE_STYLER
 
-#define ft_module_driver_scalable FT_MODULE_DRIVER_SCALABLE
-#define ft_module_driver_no_outlines  FT_MODULE_DRIVER_NO_OUTLINES
-#define ft_module_driver_has_hinter   FT_MODULE_DRIVER_HAS_HINTER
+#define ft_module_driver_scalable   FT_MODULE_DRIVER_SCALABLE
+#define ft_module_driver_no_outlinesFT_MODULE_DRIVER_NO_OUTLINES
+#define ft_module_driver_has_hinter FT_MODULE_DRIVER_HAS_HINTER
+#define ft_module_driver_hints_lightly  FT_MODULE_DRIVER_HINTS_LIGHTLY
 
 
   typedef FT_Pointer  FT_Module_Interface;
diff --git a/include/freetype/internal/ftobjs.h 
b/include/freetype/internal/ftobjs.h
index da5582d..9a333fc 100644
--- a/include/freetype/internal/ftobjs.h
+++ b/include/freetype/internal/ftobjs.h
@@ -506,6 +506,9 @@ FT_BEGIN_HEADER
 #define FT_DRIVER_HAS_HINTER( x )  ( FT_MODULE_CLASS( x )->module_flags & \
  FT_MODULE_DRIVER_HAS_HINTER )
 
+#define FT_DRIVER_HINTS_LIGHTLY( x )  ( FT_MODULE_CLASS( x )->module_flags & \
+FT_MODULE_DRIVER_HINTS_LIGHTLY )
+
 
   /*/
   /*   */
diff --git a/src/base/ftobjs.c b/src/base/ftobjs.c
index dc3a513..ea40396 100644
--- a/src/base/ftobjs.c
+++ b/src/base/ftobjs.c
@@ -686,7 +686,8 @@
 /* check the size of the `fpgm' and `prep' tables, too --*/
 /* the assumption is that there don't exist real TTFs where  */
 /* both `fpgm' and `prep' tables are missing */
-if ( mode == FT_RENDER_MODE_LIGHT   ||
+if ( ( mode == FT_RENDER_MODE_LIGHT   &&
+   !FT_DRIVER_HINTS_LIGHTLY( driver ) ) ||
  face->internal->ignore_unpatented_hinter   ||
  ( FT_IS_SFNT( face ) &&