Yaron Cohen-Tal | 26 Jun 10:35 2015

[ft] Building Freetype 2.6 for Android fails with "arm-linux-androideabi-ranlib: not found".


Did any1 succeed with building and installing freetype in Android? I use the following script to build it:

    export PLATFORM_PREFIX=/opt/android/ndk-standalone_toolchain-r10e-4.9
    export NDKROOT=/opt/android/android-ndk-r10e
    export ARCH_ABI="arm-linux-androideabi-4.9"
    export ANDROID_PLATFORM=android-21
    sudo rm -rf $PLATFORM_PREFIX
    sudo mkdir -p $PLATFORM_PREFIX
    sudo $NDKROOT/build/tools/make-standalone-toolchain.sh --platform=$ANDROID_PLATFORM \
        --system=linux-x86_64 --arch=arm --abis=armeabi-v7a --ndk-dir=$NDKROOT \
        --toolchain=$ARCH_ABI --install-dir=$PLATFORM_PREFIX
    sudo chmod -R 755 $PLATFORM_PREFIX
    export HOST=arm-linux-androideabi
    rm -rf $BUILD_DIR
    mkdir $BUILD_DIR
    cd $BUILD_DIR
    ../../src/freetype-2.6/configure --host=$HOST --prefix=$PLATFORM_PREFIX \
        --without-zlib --with-png=no
    make -j4
    sudo make install

And the "sudo make install" step it fails with:

libtool: install: arm-linux-androideabi-ranlib /opt/android/ndk-standalone_toolchain-r10e-4.9/lib/libfreetype.a
/home/yaronct/build/freetype-android-standalone-2.6/libtool: 1: eval: arm-linux-androideabi-ranlib: not found
/home/yaronct/src/freetype-2.6/builds/unix/install.mk:32: recipe for target 'install' failed
make: *** [install] Error 127

but the file exists and it's in the "PATH":
which arm-linux-androideabi-ranlib /opt/android/ndk-standalone_toolchain-r10e-4.9/bin/arm-linux-androideabi-ranlibAnd has the required permissions:-rwxr-xr-x 1 root root 732696 Nov 4 05:27 /opt/android/ndk-standalone_toolchain-r10e-4.9/bin/arm-linux-androideabi-ranlibI'm using Debian 8.1 for AMD64.

Freetype mailing list
Freetype <at> nongnu.org
Lawrence D'Oliveiro | 26 Jun 00:34 2015

Re: [ft] Help with making sure all characters fit in Certain pixel dimensions

On Thu, 25 Jun 2015 16:10:06 -0500, Shomari Sharpe wrote:

> I'm creating an font system that uses bitmap fonts generated from
> freetype to be used in my game engine. It appears that even though I
> have specified a pixel size of 64px there are characters that are
> rendered outside the actual pixel size I have specified though the
> actual FT_Face->Glyph->Bitmap is actually smaller the 64px. There
> also seems to be a big gap of approximately 12px above glyphs.

The interpretation of the “size” of the font is very much up to the
font designer. Looking at the bitmap you supplied, the baseline of the
text is situated 64 pixels from the top of the image. But you forgot to
take into account descenders--those characters that extend below the

If you want text to fit into an exact cell size, I would suggest
rendering all the needed glyphs into a larger image while measuring
them individually, to find the largest extents. Then use those largest
extents to compute a scale factor to shrink them all down uniformly to
fit into the desired cell dimensions.

The result will probably not look as good as the font designer intended.

Freetype mailing list
Freetype <at> nongnu.org
Shomari Sharpe | 25 Jun 23:10 2015

[ft] Help with making sure all characters fit in Certain pixel dimensions

I'm creating an font system that uses bitmap fonts generated from freetype to be used in my game engine. It appears that even though I have specified a pixel size of 64px there are characters that are rendered outside the actual pixel size I have specified though the actual FT_Face->Glyph->Bitmap is actually smaller the 64px. There also seems to be a big gap of approximately 12px above glyphs. Below is the code I am using for placement on a flat bitmap.

------------------------------------- CODE -----------------------------------------
font_size = 64;

        /* convert to an anti-aliased bitmap */
        FT_Render_Glyph( freetype_face->glyph, FT_RENDER_MODE_LCD );

        //This reference will make accessing the bitmap easier
        FT_Bitmap& bitmap=freetype_face->glyph->bitmap;
for (int y = 0; y < bitmap.rows; y++)
            for (int x = 0; x < bitmap.width; x++)
                pixel_t pixel = { 0, 0, 0, bitmap.buffer[bi]};
                putpixel((xoffset+x), (yoffset+y+ font_size-abs(freetype_face->glyph->bitmap_top)), maxwidth, fontdata, pixel);
xoffset += bitmap.width;

---------------------------------- END CODE ------------------------------------

I've included a sample png image showing the results. Help please?

Shomari Sharpe
Freetype mailing list
Freetype <at> nongnu.org
Jun Dai | 18 Jun 01:39 2015

[ft] Possible Bug in FT_Get_FSType_Flags

Deal FreeType Organization,

Thank you for this wonderful library. This is Jun Dai from Prevo Tech.

Currently I experience a strange behave from FT_Get_FSType_Flags call. I load a True Type font from system and use FT_Get_FSType_Flags call to check if this font is editable or not.  
According to FreeType document, the FT_GetFSType should return one of the FT_FSTYPE_XXX flag. But I receive a 1, which is not listed as any of those flags.
The test font is a restricted true type font. I was expecting a return of FT_FSTYPE_RESTRICTED_LICENSE_EMBEDDING flag.


The following is the testing code.
I am on windows 8.1 pro.
FreeType is 2.6 windows build.  


--- Start of Test Code ---


int _tmain(int argc, _TCHAR* argv[])


       //Free Type Library, it use to load font for library

       FT_Library _library = NULL;


       //initial Free Type library;

       FT_Error error = FT_Init_FreeType( &_library );



             return 0;


       //windows font, which is a restricted font

       const char* WINDOWSFONT = "C:\\Windows\\Fonts\\sanss___.ttf";


       //load file

       FILE* ffile = NULL;

       int errorcode = fopen_s(&ffile, WINDOWSFONT, "rb");

       if(errorcode == 0 && ffile != NULL)


             //copy font file into memory

             fseek(ffile, 0, SEEK_END);

             int fontFileSize = ftell(ffile);

             fseek(ffile, 0, SEEK_SET);

             BYTE* fontFile = new BYTE[fontFileSize];

             int remain = fontFileSize;

             BYTE* tempbuff = fontFile;

             while(remain > 0)


                    int rbyte = fread(tempbuff, 1, remain, ffile);

                    if(rbyte < 1) break;

                    remain -= rbyte;

                    tempbuff += remain;




             //load font face.

             FT_Face fontface = NULL;

             error=FT_New_Memory_Face(_library, fontFile, fontFileSize, 0, &fontface);

             if (error || fontface ==NULL)



                    return 0;


             //check font type flag

             FT_UShort flag = FT_Get_FSType_Flags(fontface);



                    case FT_FSTYPE_INSTALLABLE_EMBEDDING:

                    {//Fonts with no fsType bit set may be embedded and permanently installed on the remote system by an application.

                           printf("Font Type INSTALLABLE_EMBEDDING:  %d \n", flag);




                    {//Fonts that have only this bit set must not be modified, embedded or exchanged in any manner without first obtaining

                     //permission of the font software copyright owner.

                           printf("Font Type RESTRICTED_LICENSE_EMBEDDING:  %d \n", flag);




                    {//If this bit is set, the font may be embedded and temporarily loaded on the remote system. Documents

                     //containing Preview & Print fonts must be opened ‘read-only’; no edits can be applied to the document.

                           printf("Font Type PREVIEW_AND_PRINT_EMBEDDING:  %d \n", flag);



                    case FT_FSTYPE_EDITABLE_EMBEDDING:

                    {//If this bit is set, the font may be embedded but must only be installed temporarily on other systems.

                     //In contrast to Preview & Print fonts, documents containing editable fonts may be opened for reading,

                     //editing is permitted, and changes may be saved.

                           printf("Font Type EDITABLE_EMBEDDING:  %d \n", flag);



                    case FT_FSTYPE_NO_SUBSETTING:

                    {//If this bit is set, the font may not be subsetted prior to embedding.

                           printf("Font Type NO_SUBSETTING:  %d \n", flag);



                    case FT_FSTYPE_BITMAP_EMBEDDING_ONLY:

                    {//If this bit is set, only bitmaps contained in the font may be embedded; no outline data may be embedded.

                    //If there are no bitmaps available in the font, then the font is unembeddable.

                           printf("Font Type BITMAP_EMBEDDING_ONLY:  %d \n", flag);





                           printf("Font Type unknow:  %d \n", flag);






             fontface = NULL;




       if(_library != NULL)



             _library = NULL;


       return 1;



--- End of Test Code ---



Thank you for your help


Jun Dai

Freetype mailing list
Freetype <at> nongnu.org
TINTU THOMAS | 12 Jun 08:53 2015

[ft] How can I Minimize Heap Size in Freetype 2.6?

Hello ,

I was using freetype 2.4 version in my embedded application for rendering ttf files only. It uses about 12 KB heap size, when I set  FT_RENDER_POOL_SIZE to 4096 Bytes.
But in freetype 2.6 ,it takes around 20 KB heap size minimum. Here I could observe ,freetype 2.6 doesn't use raster_pool anymore.
So can you answer these...

1. What is the minimum heap size needed for freetype to rasterize ttf files as a binary image? (I don't need smoothing and gray shades)

2.How can I minimize heap size in freetype 2.6 for this purpose?

Tintu Thomas
Freetype mailing list
Freetype <at> nongnu.org
follower | 12 Jun 02:34 2015

[ft] Change in monochrome rendered font behaviour from to 2.5.1


I've encountered a change in behaviour which I've narrowed down to
being between libfreetype6 version and 2.5.1 (I originally
encountered the issue moving code from 2.4.8 & 2.5.2 and can confirm
the new behaviour continues in 2.6).

Specifically, the change is that monochrome rendered fonts (in small
sizes for a low resolution display) appear noticeably "worse" unless
the `FT_LOAD_FORCE_AUTOHINT` option is supplied. It's not clear to me
if this is a bug or an intended change in behaviour.

The following demonstrates the difference in behaviour (when viewed
with a monospace font) with a 14 pt letter 'e' from

python fontdemo.py

python fontdemo.py

Note particularly the bottom right curved portion of the 'e'. (Another
obvious character is 'f' where the vertical changes from 2 to 3 pixels

The `fontdemo.py` file is from
via <https://dbader.org/blog/monochrome-font-rendering-with-freetype-and-python>
using `freetype-py`. But the original code I encountered this with
used the PIL/Pillow library in Python.

In the `fontdemo.py` code, when run with 2.5.1+, if I change this:

    self.face.load_char(char, freetype.FT_LOAD_RENDER |

to this:

    self.face.load_char(char, freetype.FT_LOAD_RENDER |

the original behaviour is retained. Unfortunately PIL/Pillow does not
provide a way to supply this option AFAICT:


I seem to recall reading that there was some intentional change in
hinting/grid-fitting for monochrome fonts. Is what I'm seeing a bug or
is this an intentional change in behaviour?


Erlend Langseth | 7 Jun 11:41 2015

[ft] Can't get offset of glyphs right.


I'm trying to render text, using FreeType 2. My problem is in offsetting each glyph with respect to their own origin. In this mail, with "offset", I refer to what is called bearingX and bearingY in this illustration.

I first render all glyphs, storing necessary metrics, then use the results to render text.
Given an unsigned char c, this is how I render glyphs, and need to obtain the correct offsets (C++):

FT_Face face;

if (!FT_Load_Char(face, c, 0)) {
      if (!FT_Render_Glyph(face->glyph, FT_RENDER_MODE_NORMAL)) {
             if (!FT_Get_Char_Index( face, c )) continue;
                   // Set offset of glyphs accessing face->glyph here.

I have tried to use face->glyph->bitmap_left (and bitmap_top), and also face->glyph->metrics.horiBearingX / 64.0f (and Y), but the results always look arbitrary:

http://a.pomf.se/iudwvo.png      And with inverted yoffset: http://a.pomf.se/jlkngl.png

This is how I render text at the moment (no kerning yet). (Additional question: is width, height, xadvance, yadvance, xoffset and yoffset all metrics I need to render text?)

On lines 27 and 28, you see how I apply the offset. size is the pixel size of the font (note that I "normalize" the metrics by dividing by pixel size in the first place).

Thanks in xadvance!
Freetype mailing list
Freetype <at> nongnu.org
katz - | 7 Jun 09:05 2015

[ft] How to use subpixel hinting in FreeType

Dear FreeType mailing list,

I am a beginner at using FreeType and new to the concept of subpixel hinting. I've read through most API references that seemed related, but I am still not sure how should I use the library to attain RGB (or RGBA?) bitmaps with glyphs hinted on the subpixel level. If there are any examples on this I did not manage to find, please direct me to it.

So here is what I tried doing so far:
I built the library with both the FT_CONFIG_OPTION_SUBPIXEL_RENDERING and the TT_CONFIG_OPTION_SUBPIXEL_HINTING definitions. Here is my program, that runs without errors:

With this method, I end up with a glyph bitmap which is three times wider than the intended size. If this is the right approach, then my question is how should I use this information to get an RGB bitmap with the right size? The code tries to directly map the values of the result bitmap to the RGB channels, but this doesn't seem right:
The colors are obviously too strong.

I guess I am doing something really wrong here, because if I try different sizes (for example: 31) the result will be distorted:
I am also getting distortions like that seemingly every time, if I don't turn on LCD filtering.

Any help on the subject is greatly appreciated!

- katz
Freetype mailing list
Freetype <at> nongnu.org
Werner LEMBERG | 6 Jun 05:38 2015

[ft] Fw: [ft-devel] fitting a text

[Originally sent to the wrong list.]

Please help this guy.

From: folkert <folkert <at> vanheusden.com>
Subject: [ft-devel] fitting a text
Date: 2015-06-05 09:24:12 GMT

I'm trying to draw text to a bitmap. It should fit the height of the
bitmap and the width can be extended whenever required.
Getting the width right works fine but the height is a problem: a, b, c
fit nicely but g, q and _ fall below the bottom. How can I get this to
My code is:

	int target_height = 50; // height of bitmap

        FT_Library library;
        FT_Face face;
          (void)FT_New_Face(library, filename.c_str(), 0, &face);

          (void)FT_Set_Char_Size(face, target_height * 64, 0, 100, 0); /* set character size */
        FT_GlyphSlot slot = face->glyph;

          w = 0;
          h = target_height;

	  // calculate resulting width
          for(int n = 0; n < text.size(); n++)
                 if (FT_Load_Char(face, text.at(n), FT_LOAD_RENDER))

                 w += slot->advance.x / 64;

	  // draw text to bitmap
          image = new uint8_t[w * h];
	  memset(image, 0x00, w * h);

          double x = 0.0;
          for(int n = 0; n < text.size(); n++)
		if (FT_Load_Char(face, text.at(n), FT_LOAD_RENDER))

		draw_bitmap(w, h, &slot->bitmap, slot->bitmap_left + int(x / 64.0), target_height -
slot->bitmap_top - slot->advance.y);

		x += slot->advance.x;


draw bitmap:
    // x_offset is the 'x' from the code above that gets the slot->advance.x added to it for every character
    // x,y here just iterate from 0 to slot->bitmap.width and .height

    int y_offset = target_height - slot->bitmap_top - slot->advance.y;

    image[(y + y_offset) * image_width + x + x_offset] = slot->bitmap.buffer[y * slot->bitmap.width + x];

Folkert van Heusden

Freetype-devel mailing list
Freetype-devel <at> nongnu.org
Freetype mailing list
Freetype <at> nongnu.org
Werner LEMBERG | 31 May 05:18 2015

[ft] New FreeType release soon


right now I'm trying to fix GX support[*], then I'm going to do a new
release, which will be 2.6.0.  This should happen within a week, I
hope.  In case you feel that something urgent should be fixed also,
please raise your voice.


[*] Behdad, it is indeed necessary to interpolate after each design
    tuple.  My implementation already works quite nicely, but there
    are two glitches that I have to identify and correct before
    committing the code to the repository.
puxi | 29 May 09:51 2015

[ft] Gamma (?) huge difference between FreeType and others (OS X, or even FreeType based MacType)

I'm fully confused. I don't know how to say properly, because I'm not
talking about font's darken/slightly, I'm saying, they just like got
the different "colors" of the results.
Here are some sreenshots (I use Firefox to compare them),

Linux/FreeType2 2.5.5-1

MacType (MacType is FreeType based, more details see bottom external links)

!!Especially when setting font's gamma valve to high level as that
makes font get more slightly.
MacType with font gamma changes

Linux/FreeType with font gamma changes (I use INFINALITY patch to
tweak the gamma value)

Putting them together,

As you can see, even the MacType got the results as same as OS X. Only
Linux is so different.  Still not sure it is a "Gamma correction"
issue. If not, what is making Linux font rendering so "weird"?
How to fix it?

External links:
History of gdi++