Discussion :

[Jipété]

Bonjour,

tellement pleine d'erreurs qu'il est impossible de les reproduire ici, et pourtant
1- ça vient de github (https://github.com/kv01/ttf-parser/tree/master), on pourrait penser que ça va fonctionner du premier coup ;
2- il n'y que 2 petits fichiers, un .cpp et un .h, pas de quoi fouetter un chat.
Mes seules modifs, dans le .cpp :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
//#include "../src/ttfParser.h" je mets les deux fichiers ensemble dans un dossier
#include "ttfParser.h"

et juste après,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
//const char* font_path = "test/fonts/cm-unicode/cmunrm.ttf";
const char* font_path = "/data/Almanach.ttf";

Tout ça est porté par une Debian 64bits 11.9.
Et pour compiler :
gcc -o ttf_parser parseTest.cpp.

Merci de me dire où je me gourre, et bon après-midi.

[deedolith]

Salut,

Est ce que tu t'es occupé de ca ?

Define TTF_FONT_PARSER_IMPLEMENTATION in ONE cpp file to enable the implementation in the header file.

Alternativement, on peut en faire une constante de compilation, non ?

[Jipété]

Est-ce que tu t'es occupé de ça ?

Euh non, dans le .cpp il y a le define qui va bien, donc pas plus, quoi. Enfin, il me semble (je ne suis pas spécialiste C++, je joue plutôt avec FreePascal.)

Alternativement, on peut en faire une constante de compilation, non ?

Je te laisse manœuvrer, l'idée c'est d'avoir un binaire pour faire des tests et que je puisse le recompiler facilement, pour changer la fonte en analyse.

EDIT : je crée une nouvelle discussion pour le code en C pur, ça sera mieux.

[gabriel21]

Si tu compile avec g++ et pas gcc, il te signale une toute petite erreur avec la correction possible.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
g++ -o test parseTest.cpp  
In file included from parseTest.cpp:12: 
../src/ttfParser.h: In member function ‘uint32_t TTFFontParser::TableEntry::parse(const char*, uint32_t)’: 
../src/ttfParser.h:102:53:error: ‘memcpy’ was not declared in this scope 
  102 |                         get4b(&tag, data + offset); memcpy(tagstr, data + offset, sizeof(uint32_t)); tagstr[4] = 0; offset += sizeof(uint32_t); 
      |                                                     ^~~~~~
../src/ttfParser.h:22:1:note: ‘memcpy’ is defined in header ‘<cstring>’; did you forget to ‘#include <cstring>’? 
   21 | #include <fstream> 
  +++ |+#include <cstring>
   22 | #ifdef _DEBUG 
../src/ttfParser.h: In member function ‘uint32_t TTFFontParser::NameTable::parse(const char*, uint32_t, std::unordered_map<long unsigned int, std::vector<std::__cxx11::basic_string<char> > >&, uint16_t)’: 
../src/ttfParser.h:222:33:error: ‘memcpy’ was not declared in this scope 
  222 |                                 memcpy(new_name_string, data + offset_start + stringOffset + nameRecord[i].offset_value, sizeof(char) * nameRecord[i].length); 
      |                                 ^~~~~~
../src/ttfParser.h:222:33:note: ‘memcpy’ is defined in header ‘<cstring>’; did you forget to ‘#include <cstring>’? 
../src/ttfParser.h: In function ‘int8_t TTFFontParser::parse_data(const char*, FontData*)’: 
../src/ttfParser.h:647:9:error: ‘memset’ was not declared in this scope 
  647 |         memset(glyph_loaded, 0, sizeof(bool) * max_profile.numGlyphs); 
      |         ^~~~~~
../src/ttfParser.h:647:9:note: ‘memset’ is defined in header ‘<cstring>’; did you forget to ‘#include <cstring>’?

Un fois la correction effectuée (ajout de la directive #include <cstring> en début de fichier): pas de problème.
Petit test avec une police qui traine sur mon ordinateur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
./test 
Font: SF Distant Galaxy Alternate Italic parsed 
Number of glyphs: 186

Il faut appuyer sur la touche d'entrée pour sortir.

[Jipété]

OK merci, je prends bonne note que gcc n'est pas capable de bien compiler du C++, parce que je me suis contenté de remplacer l'un par l'autre et zou !, ça a compilé, les modifs dont tu parlais ayant déjà été mises en place.

Donc ça s'exécute, bien, et je me prends un râteau :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ ./ttf_parser 
Unable to parse font /data/Almanach.ttf

Et pourtant il n'y a pas d'erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ echo $?
0

Je suspecte le problème que je traque depuis des mois avec 17 fontes...

Alors je change de fonte, j'en prends une qui ne m'a jamais posé de problème, et ça roule :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ ./ttf_parser 
Font: Cambria Regular parsed
Number of glyphs: 3221

Bon, je comptais sur ce parseur pour y voir plus clair mais ça n'est pas gagné (genre j'aurais bien aimé voir comment se comporte le parseur avec le champ loca) parce que, (asseyez-vous !) si ça coince sous Linux avec ce binaire ainsi qu'avec FreePascal, ces 17 fontes sont utilisables dans LibreOffice et aussi sous Windows, hé ouais...

Enfin bon, pour la compil.

[Obsidian]

Salut,

OK merci, je prends bonne note que gcc n'est pas capable de bien compiler du C++, parce que je me suis contenté de remplacer l'un par l'autre et zou !, ça a compilé, les modifs dont tu parlais ayant déjà été mises en place.

Comme on le dit souvent ici et ailleurs, C et C++ sont deux langages distincts, même si le second est officiellement conçu pour s'appuyer sur le premier et respecter — autant que possible — la compatibilité avec le premier.

C'est pour cette raison que la plupart des compilateurs reconnaissent directement les deux et comme, à défaut d'options explicites, les compilateurs sont faits pour être les plus tolérants possibles, ils acceptent en général de compiler dès lors qu'une expression est syntaxiquement valide. La bonne pratique consiste malgré tout à passer « dans un mode ou dans l'autre », en faisant soit du C à 100%, soit du C++ à 100% également, un peu comme on passe de VFR à IFR en aviation…

Concernant GCC, il s'agissait au départ de « GNU C Compiler », pour indiquer qu'il s'agissait de la version GNU de la commande UNIX « cc » (« C compiler »). Le projet a été ensuite rebaptisé en « GNU Compiler Collection » dès lors que sa base a été reprise puis étendue pour reconnaître un plus grand nombre de langages, tels que Objective-C, Fortran, ADA et même Java avec gcj, qui n'est en revanche plus pris en charge depuis GCC 7.

Donc ça s'exécute, bien, et je me prends un râteau :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ ./ttf_parser 
Unable to parse font /data/Almanach.ttf

Présenté comme ça, je doute que le chemin soit le bon. Si tu mets un slash « / » en début de chemin, alors ton programme va chercher « data/Almanach.ttf » à partir de la racine du filesystem (là où se trouvent usr, home, etc ou var) et pas celle de ton home ni même l'emplacement de l'exécutable ou le répertoire courant depuis lequel il est lancé.

Et pourtant il n'y a pas d'erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ echo $?
0

C'est normal : ce message est renvoyé par une fonction void elle-même appelée comme callback par la routine qui effectue le traitement. Au passage, cette routine renvoie un code d'erreur dans error. Bon, j'ai rapidement regardé le code : elle ne renvoie que -1 ou -2 en cas d'erreur, donc ça ne nous aidera pas beaucoup.

Par contre, la fonction font_parsed() du programme d'exemple est faite pour écrire « unable to parse » si ce code est non nul et poursuivre le traitement dans le cas contraire. Dans tous les cas, elle ressort normalement sans information supplémentaire car void et ta fonction main n'a aucune raison de se douter que les choses ne se sont pas déroulées comme prévu. Elle est d'ailleurs faite pour renvoyer 0 dans tous les cas et c'est bien ce que tu obtiens.

Je suspecte le problème que je traque depuis des mois avec 17 fontes...

Alors je change de fonte, j'en prends une qui ne m'a jamais posé de problème, et ça roule :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ ./ttf_parser 
Font: Cambria Regular parsed
Number of glyphs: 3221

Si c'est le chemin qui est en commentaire dans l'exemple que tu nous montres, alors on voit que c'est bien un chemin relatif, sans « / » initial.

Bon, je comptais sur ce parseur pour y voir plus clair mais ça n'est pas gagné (genre j'aurais bien aimé voir comment se comporte le parseur avec le champ loca) parce que, (asseyez-vous !) si ça coince sous Linux avec ce binaire ainsi qu'avec FreePascal, ces 17 fontes sont utilisables dans LibreOffice et aussi sous Windows, hé ouais...

En fait, à la base, que cherches-tu à savoir exactement ?

[Jipété]

Présenté comme ça, je doute que le chemin soit le bon. Si tu mets un slash « / » en début de chemin, alors ton programme va chercher « data/Almanach.ttf » à partir de la racine du filesystem (là où se trouvent usr, home, etc ou var) et pas celle de ton home ni même l'emplacement de l'exécutable ou le répertoire courant depuis lequel il est lancé.

Quand je bossais avec Windows, pour retrouver rapidement un fichier, je le mettais dans C:\ et pour suivre ce principe, sous Linux je le mets dans /data/, un dossier accessible à tout le monde mais comme je suis seul, ce n'est pas gênant,

En fait, à la base, que cherches-tu à savoir exactement ?

Pourquoi, sur environ 930 fichiers ttf et otf, j'en ai 17 qui ne sont pas en accord avec l'outil FreePascal utilisé pour le parsing et ça se manifeste par des rejets dans ma liste de fontes alors que LibreOffice travaille bien avec eux, tout comme Windows dans des machines virtuelles.

Et je cherche à savoir si le problème se trouve dans les librairies FreePascal (pas impossible, elles n'accèdent pas au champ loca, qui serait critique) ou dans les fontes, qui auraient été mal designed, ce que je ne crois pas trop.
Mais pour ouvrir un rapport de bug chez FreePascal, vaut mieux être bien armé,

[Obsidian]

Quand je bossais avec Windows, pour retrouver rapidement un fichier, je le mettais dans C:\ et pour suivre ce principe, sous Linux je le mets dans /data/, un dossier accessible à tout le monde mais comme je suis seul, ce n'est pas gênant,

Pas de problème avec ça, si c'est volontaire et bien identifié.

Pourquoi, sur environ 930 fichiers ttf et otf, j'en ai 17 qui ne sont pas en accord avec l'outil FreePascal utilisé pour le parsing et ça se manifeste par des rejets dans ma liste de fontes alors que LibreOffice travaille bien avec eux, tout comme Windows dans des machines virtuelles.

Effectivement. Est-il possible d'avoir la liste des noms de ces fontes en particulier ?

Je pense globalement à la même chose que toi, à savoir : soit un champ spécial inutilisé dans tous les autres cas, soit une valeur malformée pour lesquelles les autres bibliothèques sont tolérantes, soit une version spécifique du format non prise en charge par un outil trop vieux.

Mais pour ouvrir un rapport de bug chez FreePascal, vaut mieux être bien armé,

Si tu es certain que /data/Almanach.ttf peut être atteint, vérifie d'abord que le fichier lui-même ne pose pas de problème : genre droits d'accès, lien symbolique vers un fichier qui n'existe plus ou fichier mal téléchargé, c'est-à-dire bien là mais vide (0 octet) ou alors téléchargé partiellement, ce qui est plus difficile à repérer du premier coup d'œil. Ouvre-le avec un éditeur hexadécimal si tu le peux pour tirer cela au clair.

Si le fichier est valable et proprement ouvert, et que tu tiens à utiliser à utiliser la présente bibliothèque (il y en a d'autres, comme FreeType, mais pas forcément plus faciles), alors tu peux utiliser gdb et tâcher de monitorer la fonction « parse_data() » pour voir à quel moment elle rend la main. Si tu veux faire cela de façon orthodoxe, tu utilises la commande record, sinon tu places un breakpoint à l'entrée et tu utilises « n » (next) jusqu'à ce qu'elle re-sorte.

[Jipété]

Merci pour ta prise en compte de ce souci bizarre.

Effectivement. Est-il possible d'avoir la liste des noms de ces fontes en particulier ?

No problemo, see below :
ALMANAC.TTF sans H, celui avec un H je lui ai fait une modif, lire dans le lien en bas.
ean13.ttf
FOOD.TTF
FREIG.TTF
GEOGRAPH.TTF
JANCIENI.TTF
JANCIENT.TTF
Jancient-orig.ttf "orig" parce qu'à une époque lointaine je me suis amusé à bricoler je ne sais plus quoi avec Somfy, qu'on retrouve ligne précédente.
JBLACK.TTF
KEY.TTF
KEYSTROK.TTF
Linedraw.ttf
MTSORTS.TTF
WEBDINGS.TTF
wingding.ttf
WINGDNG2.TTF
WINGDNG3.TTF
Bon, je ne sais pas ce que tu veux faire avec mes 17 fontes mais, si tu misères pour trouver les fichiers, je peux encore faire un zip,

Je pense globalement à la même chose que toi, à savoir : soit un champ spécial inutilisé dans tous les autres cas, soit une valeur malformée pour lesquelles les autres bibliothèques sont tolérantes, soit une version spécifique du format non prise en charge par un outil trop vieux.

Et c'est bien pour répondre à ces interrogations que je continue à creuser (quand je pense que j'étais parti sur l'idée de créer un mini-gestionnaire de fontes, parce que le choix avec une DropDownBox et ses centaines de lignes c'est juste totalement contre-productif.)

Si tu es certain que /data/Almanach.ttf peut être atteint, vérifie d'abord que le fichier lui-même ne pose pas de problème : genre droits d'accès, lien symbolique vers un fichier qui n'existe plus ou fichier mal téléchargé, c'est-à-dire bien là mais vide (0 octet) ou alors téléchargé partiellement, ce qui est plus difficile à repérer du premier coup d'œil. Ouvre-le avec un éditeur hexadécimal si tu le peux pour tirer cela au clair.

Une petite précision : je ne veux pas me la péter, c'est juste pour situer le contexte : 45 ans d'info dans les pattes, au SAV hard pour manger, et du code D1, D3, D6, D7, puis Lazarus pour les outils qui manquent, et du graphisme et un poil de sound pour le cerveau droit.

Pour le fun : lors de l'arrivée des premiers PC, vers 93/94, je me suis retrouvé avec un 80286 Olivetti, un dd 40 Mo et tout un stock de diskettes (DOS 6.22, Win 3.11) et un de mes premiers amusements fut de bricoler une diskette bootable qui décompressait un micro-win3.1 qui affichait un Write opérationnel. Je me suis étonné moi-même,

Si le fichier est valable et proprement ouvert, et que tu tiens à utiliser à utiliser la présente bibliothèque (il y en a d'autres, comme FreeType, mais pas forcément plus faciles), alors tu peux utiliser gdb et tâcher de monitorer la fonction « parse_data() » pour voir à quel moment elle rend la main. Si tu veux faire cela de façon orthodoxe, tu utilises la commande record, sinon tu places un breakpoint à l'entrée et tu utilises « n » (next) jusqu'à ce qu'elle re-sorte.

Tu m'as perdu, là, surtout avec 30 ° dans le salon à 23 h 30, c'est infernal...

Tiens, jette un œil là, https://forum.lazarus.freepascal.org...c,67820.0.html (pas besoin d'être inscrit, et il y a 2 pages).
Bon, le titre n'est plus approprié (les choses évoluent), mais je donne ce lien car il y a des choses intéressantes dans les 3 derniers posts, for those who read english and speak Pascal.

[Jipété]

Bonjour,

Voici venue la fin de mes tourments.
Je récapitule : je possède à ce jour 935 fichiers ttf et otf, certains datant de 30 ans et ayant toujours bien fonctionné, en général et sous Windows.
C'est en passant sous Linux qu'un souci est apparu, lors de la tentative d'utilisation de l'option permettant de connaitre l'emplacement des fichiers, utile pour leur gestion, qui me générait une exception SIGSEGV pour 17 d'entre eux, je veux parler de la

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
function GetFontFile(fName:string): string; 
// https://forum.lazarus.freepascal.org/index.php?topic=48975.0 
var
  lFC: TFPFontCacheItem;
begin
  lFC := gTTFontCache.FindFont(fName);
  try
    Result := lFC.FileName;
  except
    //
  end;
end;

fonction qui s'appuie sur l'unité fpTTF.pp de FreePascal et que j'ai modifiée ainsi car j'en avais assez de l'arrêt complet du programme en cas de souci avec une ou des fonte(s) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
function GetFontFile(fName:string): string;
// https://forum.lazarus.freepascal.org/index.php?topic=48975.0 
var
  lFC: TFPFontCacheItem;
begin
  lFC := gTTFontCache.FindFont(fName);
  if lFC <> nil 
  then Result := lFC.FileName
  else begin
    Result := '';
    ShowMessage('Problème avec la fonte '+fName);
  end;
end;

Et je me suis rapidement aperçu que quand FindFont ne remontait rien, c'était parce que les champs de type string HumanFriendlyName, PostScriptName et FamilyName étaient vides !
Ces 3 champs (ainsi que le champ FileName, qui n'est jamais vide puisqu'il définit le fichier courant), se trouvent dans l'objet fpTTF.TFPFontCacheItem, section public.

J'avais donc 935 fichiers True/OpenType dont 17 n'étaient pas présents dans la liste Family d'un outil en cours de création, et je précise tout de suite que ces 17 fichiers sont parfaitement utilisables dans le monde Windows, exactement comme les 918 autres. Dans le monde Linux, c'est aléatoire...

Je me suis alors mis à examiner l'intérieur des 17 fichiers avec un outil en Perl (ttftable de la librairie Font-TTF-Scripts-1.06 + installation du paquet libfont-ttf-perl [lecture : http://scripts.sil.org/FontUtils, téléchargement : https://github.com/silnrsi/font-ttf-scripts.git]) qui extrait le tag "name" dans un fichier binaire à examiner avec un éditeur hexa dans lequel j'ai pu constater que les champs remontés vides par l'outil FreePascal étaient bien présents dans les 17 fichiers !
Utilisation : ttftable -export "name=essai" /chemin/fontname.ttf génèrera un fichier dans le dossier ouvert pour lancer le script, script que je n'ai pas réussi à automatiser avec TProcess, dommage, mais comme il n'y avait que 17 fichiers, j'ai moins perdu de temps à les traiter un par un à la main.

Une confirmation par un autre outil issu de la suite FontForge (showttf.c, téléchargement : https://github.com/fontforge/fontfor...ools/showttf.c puis une petite modification pour avoir accès aux valeurs des champs [ajout d'une option "-n" comme "name" :
ajouter tout en haut sous static int head_check = false; la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

static int copyright_check = false;

puis ajouter dans "readit" sous le bloc if ( head_check ) { le bloc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
    if ( copyright_check ) {
	if ( info.copyright_start!=0 )
	    readttfname(ttf,util,&info);
return;
    }

et tout en bas dans le main, après head_check = true;, ajouter

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
	    else if ( strcmp(pt,"n")==0 || strcmp(pt,"checkcopyright")==0 ) // à ajouter dans main
		copyright_check = true;

Recompiler et bingo !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ ./showttf -n /filepath/afile.ttf 
blablabla
...

])
et pour moi l'affaire est classée : tous les champs nécessaires et utiles au bon fonctionnement des fontes sont présents dans les fichiers et exploités par les outils adéquats SAUF ceux qui s'appuient sur fpTTF de FreePascal, qui peuvent avoir un comportement aléatoire.

Ce qui m'a fait m'acharner sur tout ça a été le fait de constater que ces fameux champs absents dans FreePascal étaient bien présents avec un vieil outil Windows, j'ai nommé Softy.exe, qui m'a permis de générer cette magnifique image


où l'on remarque qu'il n'y a que 16 vignettes car, pour une raison que j'ignore, la fonte wingding.ttf de Windows (30 ans d'âge environ !) fait violemment planter Softy et comme on n'a pas son code, ça restera comme ça d'autant plus que sous Linux avec showttf et mon ajout j'ai mes infos :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
$ ./showttf -n /data/17ttf/wingding.ttf 
NAME table (at 532)
	format=0
	nrecords=39
	taboff=474
	 platform=1 plat spec encoding=0 language=0 name=0 Copyright
	 strlen=112  stroff=0	   Copyright � 1992-1995 Microsoft Corp. All Rights Reserved.
                                             � 1990-1991 Type Solutions, Inc. All Rights Reserved.
	 platform=1 plat spec encoding=0 language=0 name=1 Family
	 strlen=9  stroff=116	   Wingdings
	 platform=1 plat spec encoding=0 language=0 name=2 Subfamily
	 strlen=7  stroff=1566	   Regular
	 platform=1 plat spec encoding=0 language=0 name=3 UniqueID
	 strlen=27  stroff=1556	   Wingdings Regular: MS: 1995
	 platform=1 plat spec encoding=0 language=0 name=4 FullName
	 strlen=9  stroff=116	   Wingdings
	 platform=1 plat spec encoding=0 language=0 name=5 Version
	 strlen=12  stroff=1583	   Version 2.55
	 platform=1 plat spec encoding=0 language=0 name=6 Postscript
	 strlen=17  stroff=1595	   Wingdings-Regular
	 platform=1 plat spec encoding=0 language=0 name=7 Trademark
	 strlen=57  stroff=1612	   The Windows logo is a trademark of Microsoft Corporation.
	 platform=1 plat spec encoding=0 language=0 name=8 Manufacturer
	 strlen=20  stroff=1669	   Microsoft Typography
	 platform=1 plat spec encoding=0 language=0 name=9 Designer
	 strlen=31  stroff=149	   Kris Holmes and Charles Bigelow
	 platform=1 plat spec encoding=0 language=0 name=10 Descriptor
	 strlen=1444  stroff=112	   The Wingdings fonts were designed blabla...

Les plus observateurs noteront que dans l'image il y a deux fois une même fonte : à la deuxième ligne les deux premières vignettes présentent les mêmes données, issues pourtant de deux fichiers différents mais ça ne se voit pas là et je ne sais plus pourquoi je m'étais amusé à faire une modif de je ne sais plus quoi... Ne pas en tenir compte, cette grande image est surtout là pour montrer que ces 16 fichiers sont accessibles sous Windows avec un outil remontant à Windows 3.1 alors que la dernière du couple FreePascal/Lazarus n'en est pas capable, hélas.

La seule chose qui reste en suspens et me chiffonne, c'est que je n'ai pas trouvé pourquoi ces 17 fichiers-là et pas les autres génèrent une erreur.
On peut la contourner mais ça fait "pas fini".

C'est tout.
Bonne journée,