FreeType produisant des glyphes asymétriques

Question

Donc j'essaye d'implémenter le rendu de police avec des champs de distance signés dans mon moteur graphique. Pour cela, j'utilise la bibliothèque FreeType pour générer des glyphes de toutes les lettres. Plus précisément, je suis en train de charger des bitmaps monochromes comme ceci:

FT_Load_Char(face, c, FT_LOAD_RENDER | FT_LOAD_TARGET_MONO) 

Et puis-je extraire tous les bits de la mémoire tampon de glyphe et le mettre dans une texture noir blanc monochrome que je peux afficher sur l'écran à des fins de test.

Mon code pour extraire les bits et le mettre dans un tableau d'octets:

FT_Bitmap bm = face->glyph->bitmap; 

FT_Bitmap mono; 
FT_Bitmap_New(&mono); 
//convert from 8 pixel per byte to 1 pixel per byte 
FT_Bitmap_Convert(ft, &bm, &mono, 1); 
//set each byte from 0/1 to 0/255 
for (int y = 0; y < mono.rows; y++) { 
    for (int x = 0; x < mono.width; x++) { 
     mono.buffer[y * mono.width + x] *= 255; 
    } 
} 

Mon problème cependant est que le produit Glyphes FreeType semblent être asymétriques.

Par exemple ceci est la lettre M avec une pixelsize de police de 64 en utilisant les OpenSans-Regular police:

Et voici la lettre M avec la même police avec une pixelsize de 1024:

Je l'ai essayé avec plusieurs polices, tailles de polices multiples, etc. et certains glyphes toujours rester asymétrique. Notez également que je lis les données de pixels des textures manuellement pour vérifier que la mise à l'échelle de texture d'OpenGL ou quoi que ce soit ne provoque pas l'erreur.

Des idées sur la raison pour laquelle FreeType semble produire des glyphes asymétriques ou quelqu'un pourrait-il me dire si cela pourrait même être un problème lors du rendu ultérieur du texte? Editer: J'extrais maintenant les bits en utilisant les fonctions de la bibliothèque, donc l'erreur doit être quelque part dans FreeType.

Answer 1

Vous faites l'hypothèse ici qu'OpenSans est une police où tous les glpyh sont symétriques. Ce n'est pas le cas, et ce n'est pas non plus un bug FreeType. Vous pouvez toujours envoyer un email à la liste freetype, mais vous obtiendrez probablement la même réponse.

Ce n'est pas une inexactitude car le concepteur de police a conçu le M glyphe de manière non symétrique, pour toutes les raisons qu'il a choisies. Un grand nombre de fois, cela sera fait pour augmenter la lisibilité. Un peu d'asymétrie fait que les moteurs suggèrent de pixelliser le glyphe d'une manière légèrement différente, qui sera plus lisible ou plus "nette". Voici quelques captures d'écran pour prouver que c'est le cas. Tout d'abord, il s'agit d'une capture d'écran fortement agrandie de Windows 10/Chrome 55 rendant le glyphe dans le navigateur à la plus petite taille que le site me permettrait de sélectionner. Bien que cela semble symétrique à première vue, ce n'est pas le cas.

En second lieu, j'ai téléchargé la police et a ouvert dans FontForge. Si vous regardez attentivement, vous pouvez voir que les courbes sur le bord intérieur des deux côtés sont en réalité légèrement différentes. J'ai également pris un moment pour regarder les deux points qui définissent le centre inférieur du M. Leurs positions sont (848, 0) et (985, 0). Le point médian entre ces deux points est (916.5, 0), cependant les deux points qui définissent le bord supérieur de cette partie du glyphe sont à (920, 256) et (928, 256). Ceci est légèrement décalé vers la droite.

Si vous cherchez des polices symétriques ou autrement simples, rechercher des polices orientées vers les programmeurs ou les polices de la console. Arial, Consolas, Courier New, etc. vont probablement très bien faire l'affaire.