[Freetype] Opening one font causes distortion of another

[Wenlin Institute]

Dear Freetype People,

Strange behavior is demonstrated by the following short program.

The program opens a Chinese TrueType font, and displays one Chinese 
character (U+6797 'forest'). Then it opens another TrueType font, and 
displays the letter 'A'. Finally, it displays the same Chinese 
character in the original font.

The Chinese character comes out differently the second time.

The only explanation I can think of is that some rendering 
information, such as autohinting, is applied to the whole FT_Library 
object, and it's changed when opening the second font, in a way that 
changes how the first font is rendered.

#include <stdio.h>
#include "freetype.h"

static void WriteBitmap(FT_Face face, FT_ULong c, char *fileName);

int main(void)
{
        FT_Library ftEngine;
        FT_Face asciiFace, hanziFace;

        FT_Init_FreeType(&ftEngine);
        if (FT_New_Face(ftEngine, "mssong.ttf", 0, &hanziFace) != 0) {
                printf("FT_New_Face failed\n"); return 1;
        }
        FT_Set_Pixel_Sizes(hanziFace, 0, 22);
        WriteBitmap(hanziFace, (FT_ULong) 0x6797, "hanziFile1.txt");

        if (FT_New_Face(ftEngine, "garawen.ttf", 0, &asciiFace) != 0) {
                printf("FT_New_Face failed\n"); return 1;
        }
        FT_Set_Pixel_Sizes(asciiFace, 0, 16);
        WriteBitmap(asciiFace, (FT_ULong) 'A', "asciiFile.txt");

        WriteBitmap(hanziFace, (FT_ULong) 0x6797, "hanziFile2.txt");
        printf("Done\n");
        return 0;
} // main

static void WriteBitmap(FT_Face face, FT_ULong c, char *fileName)
{
        FT_UShort glyphNumber = FT_Get_Char_Index(face, c);
        FT_GlyphSlot glyph;
        int row, col;
        char *p;
        FILE *file = fopen(fileName, "w");

        FT_Load_Glyph(face, glyphNumber, FT_LOAD_RENDER | FT_LOAD_NO_BITMAP);
        glyph = face->glyph;
        p = (char *) glyph->bitmap.buffer;
        for (row = 0; row < glyph->bitmap.rows; row++) {
                for (col = 0; col < glyph->bitmap.width; col++) {
                        fprintf(file, " %02x", (int) (*p++ & 0xff));
                }
                fprintf(file, "\n");
        }
        fclose(file);
} // WriteBitmap

The difference is in a thin horizontal stroke, part of which becomes 
lighter or disappears completely. Here is a comparison of the pixels 
in hexadecimal (one byte per pixel, grayscale; the whole bitmap is 
20x20 pixels):

% diff hanziFile1.txt hanziFile2.txt
6,8c6,8
<  00 00 00 00 44 ff 14 30 1f 00 00 00 44 ff 14 00 39 d6 32 00
<  00 74 c3 c0 d8 ff c5 dc bf ad c0 c0 e1 ff ce c6 d7 e0 ce 11
<  00 01 00 00 ad ff 14 00 00 00 00 02 ea ff 53 3f 00 00 00 00
---
>   00 00 00 00 44 ff 14 16 1f 00 00 00 44 ff 14 00 39 d6 32 00
>   00 13 03 00 4b ff 14 94 bf ad c0 c0 e1 ff ce c6 d7 e0 ce 11
>   00 02 00 00 ad ff 14 00 00 00 00 02 ea ff 53 3f 00 00 00 00

The problem occurs with both Freetype 2.1.0 and 2.1.4, but the 
difference is more noticeable in 2.1.4. Whatever happens while using 
the second (ASCII) font causes the rendering of the Hanzi font to 
become worse.

The same thing happens when different ASCII fonts are used, and it 
also happens for another Chinese font, DFPMingLight.TTF, though the 
difference is more subtle, and involves some darkening as well as 
some lightening:

diff hanziFile1.txt hanziFile2.txt
5,7c5,7
<  00 00 00 00 2c ff 00 00 00 00 00 00 00 2c fc 00 00 00 00 02 00
<  09 02 00 00 2c ff 00 15 ae 21 0b 00 00 2c fc 00 00 00 82 be 17
<  24 e4 c6 c0 db ff c0 ce e0 a8 93 d0 c0 db ff cb c0 c0 df e0 a2
---
>   00 00 00 00 2c ff 00 00 00 00 00 00 00 2c fc 00 00 00 03 00 00
>   09 02 00 00 2c ff 00 15 ae 21 0b 00 00 2c fc 00 00 00 a9 91 03
>   24 e4 c6 c0 db ff c0 ce e0 a8 93 d0 c0 db ff cb c0 c3 e0 e0 5e
9,16c9,16
<  00 00 00 0e fc ff 03 00 00 00 00 00 2b fc fc 8b 02 00 00 00 00
<  00 00 00 53 e9 ff 97 2b 00 00 00 00 88 ab fc 59 4b 00 00 00 00
<  00 00 00 a2 8d ff 0f cc 44 00 00 08 de 3f fc 0a b9 00 00 00 00
<  00 00 0a df 37 ff 00 40 f0 14 00 6d 8c 2c fc 00 92 56 00 00 00
<  00 00 6d 7b 2c ff 00 00 a7 2e 13 cf 0f 2c fc 00 21 e0 1f 00 00
<  00 1c b1 05 2c ff 00 00 00 05 a5 2e 00 2c fc 00 00 72 e1 2f 00
<  06 a2 14 00 2c ff 00 00 02 8d 2b 00 00 2c fc 00 00 00 8e f9 6e
<  66 23 00 00 2c ff 00 02 7e 28 00 00 00 2c fc 00 00 00 00 3b 00
---
>   00 00 00 0e fc ff 03 00 00 00 00 00 2b fc fc 8a 01 00 00 00 00
>   00 00 00 53 e9 ff 97 2b 00 00 00 00 88 ab fc 59 48 00 00 00 00
>   00 00 00 a2 8d ff 0f cc 44 00 00 08 de 3f fc 0a ae 00 00 00 00
>   00 00 0a df 37 ff 00 40 f0 14 00 6d 8c 2c fc 00 96 41 00 00 00
>   00 00 6d 7b 2c ff 00 00 a7 2e 13 cf 0f 2c fc 00 29 d1 0f 00 00
>   00 1c b1 05 2c ff 00 00 00 05 a5 2e 00 2c fc 00 00 89 c9 16 00
>   06 a2 14 00 2c ff 00 00 02 8d 2b 00 00 2c fc 00 00 03 b1 e8 37
>   66 23 00 00 2c ff 00 02 7e 28 00 00 00 2c fc 00 00 00 06 32 00

Fonts shouldn't interfere with each other like this. Any ideas what's 
going wrong, and how to solve it or get around it?

Tom Bishop

--

Wenlin Institute, Inc.        Software for Learning Chinese
E-mail: address@hidden     Web: http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)