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.

[Obsidian]

Merci pour ta prise en compte de ce souci bizarre.

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 veux bien un *.zip quelque part (éventuellement sur une branche dédiée du dépôt Git). Effectivement, les fontes sont difficiles à trouver mais en plus, on a parfois des homonymes ou des fontes repackagées dans d'autres formats.

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.

Je n'en doute pas une seconde… ;-) Même ici sur Développez seul, ton compte commence à avoir beaucoup d'ancienneté.

C'est juste que le fil étant public, c'est toujours une bonne chose de rappeler l'essentiel mais en plus, la bibliothèque elle-même ne donnant que très peu d'informations, c'est à nous de revérifier tout ce que l'on pourrait légitimement s'attendre à retrouver dans un message de log en temps normal. Ce serait dommage (mais néanmoins courant) de se rendre compte que l'on a perdu du temps sur une bêtise.

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,

Le premier PC, c'était 1981, surtout (je n'étais pas vieux à cette époque, mais déjà là pour le voir quand même. Avec l'essor des huit bits juste derrière. Cette époque me manque. :-)

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

Pareil ici. J'ai fini par m'acclimater à la température (surtout par rapport aux années passées) mais c'est encore trop chaud pour coder et avoir un cerveau en plein état de fonctionnement.

Je voulais juste dire que le gros du travail est fait par la fonction TTFFontParser::parse_data() du fichier src/ttfParser.h à partir de la ligne 474. Il y a une série de return -2 qui correspondent à tous les cas où la lecture d'un fichier peut échouer, ce qui veut dire que le code d'erreur est le même dans tous les cas. La section « loca » en particulier est recherchée à la ligne 524.

Tu peux poser un breakpoint à cet endroit pour vérifier si c'est bien là que ça échoue mais si tu veux vérifier tous les autres cas et savoir à quel moment la lecture échoue, soit tu parcours la fonction pas à pas jusqu'à ce que tu la voies ressortir, soit tu poses des breakpoints sur tous les return (un peu fastidieux), soit tu modifies le code pour produire des informations avant chaque test.

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.

Merci pour le lien.

[Jipété]

Bonjour,

Je veux bien un *.zip quelque part (éventuellement sur une branche dédiée du dépôt Git).

Pas de compte Git, je vais le mettre là : 18_fontes.zip
J'ai rajouté "mon" Almanach.ttf, juste parce que j'en ai parlé hier et sur le forum FP.

Le premier PC, c'était 1981...

En ce temps-là je mettais mes mains dans les premiers Vax de DEC, le 11/780 puis 11/750 et 11/730, des monstres, surtout le premier, tout en lisant le magazine "Micro-Systèmes" mais l'hexadécimal et son manque total de lisibilité m'ont dégouté ! J'étais habitué à la beauté de l'octal, découvert chez DEC et ses PDP11.

Je voulais juste dire que le gros du travail est fait par la fonction TTFFontParser::parse_data() du fichier src/ttfParser.h à partir de la ligne 474. Il y a une série de return -2 qui correspondent à tous les cas où la lecture d'un fichier peut échouer, ce qui veut dire que le code d'erreur est le même dans tous les cas. La section « loca » en particulier est recherchée à la ligne 524.

Tu peux poser un breakpoint à cet endroit pour vérifier si c'est bien là que ça échoue mais si tu veux vérifier tous les autres cas et savoir à quel moment la lecture échoue, soit tu parcours la fonction pas à pas jusqu'à ce que tu la voies ressortir, soit tu poses des breakpoints sur tous les return (un peu fastidieux), soit tu modifies le code pour produire des informations avant chaque test.

Les points d'arrêt je sais les poser/les utiliser avec Delphi/Lazarus mais sorti de là, je suis largué. En cas de besoin, je m'en dépatouille à coups de printf, lol !

Je vais retourner voir ce que je peux explorer avec FreePascal, j'y suis bien plus à l'aise.
Bonne journée,

[gabriel21]

J'ai télécharger ton archive.
FontMatrix et KFontView les chargent sans problème.

Test plus poussé avec la fonte ALMANAC.TTF
FontForge la charge sans problème
Mais il m'affiche les messages suivants :

Code :

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

1
2
3
4
5
6
7
Glyph 2 is called ".notdef", a singularly inept choice of name (only glyph 0
  may be called .notdef)
  FontForge will rename it.
Le glyphe nommé ohm est mappé en U+03A9.
  Son nom indique qu'il devrait être mappé en U+2126.
Le glyphe nommé currency est mappé en U+20AC.
  Son nom indique qu'il devrait être mappé en U+00A4.

Si je veux l'exporter à nouveau (l'enregistrement se fait dans un autre format propre au logiciel) il me fournit d'autres messages de mise en garde :

Code :

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

Points manquant aux extréma pour les lettres N,P,Q,b,d,e,k

Il accepte quand même de l'exporter, mais le problème reste entier et le parser ne te donne qu'une seule glyphe.

Bref la police est mal faite et doit être corrigé. Si tu en as le temps et la patience FontForge permet de le faire et il est multiplateforme.

En espérant que cela t'aide dans ta recherche

[Jipété]

Ho gab', tu me sauves la vie !

J'ai téléchargé ton archive.
FontMatrix et KFontView les chargent sans problème.

Impec !
J'ai fait au plus simple, l'install de fontmatrix et voili et voilou ! :



Plus qu'à apprendre à maitriser l'animal,

Test plus poussé avec la fonte ALMANAC.TTF
...
Bref la police est mal faite et doit être corrigée. Si tu en as le temps et la patience FontForge permet de le faire et il est multiplateforme.

En espérant que cela t'aide dans ta recherche

Tu m'as considérablement aidé avec tes quelques lignes !

Je vais regarder plus attentivement ton FontForge (j'ai un peu peur d'une usine à gaz...)

Mais c'est bizarre cette histoire avec Almanac puisque c'est elle qu'on voit sur l'image du haut et je rappelle qu'elle est dispo dans Writer et aussi sous Windows en machine virtuelle.

Je sens que je vais abandonner la programmation concernant les ttf's, le peu que j'ai essayé c'est épouvantable, sans compter les erreurs dont je ne sais pas si c'est lié au parsing de la ligne ou à autre chose :



Ce qu'on voit dans cette copie d'écran c'est l'erreur que voit le compilo quand je mets la souris sur le "Cr" de la ligne qu'on ne voit pas, masquée par l'infobulle : c'est CacheItem.Create(aFont);.

Et si je fais exécuter, c'est SIGSEGV systématique, et je n'arrive pas à trouver où ça coince.
Le problème de ces trucs c'est qu'il n'y a aucune aide et pour s'en sortir il me faudrait 3 ou 4 écrans, avec un seul c'est impossible.
(comment faisait-on, en 1993, avec des écrans 600x800 ? Je me le demande encore...)

Bref, merci à toi pour tes tests, j'attends qu'il fasse moins chaud pour retourner au charbon, et je suggère à Obsidian de ne pas trop perdre de temps là-dessus.

[gabriel21]

Ho gab', tu me sauves la vie !
Tu m'as considérablement aidé avec tes quelques lignes !

Mais c'est bizarre cette histoire avec Almanac puisque c'est elle qu'on voit sur l'image du haut et je rappelle qu'elle est dispo dans Writer et aussi sous Windows en machine virtuelle.

De rien.
Pour la police, il est possible qu'entre 1993 et aujourd'hui, les spécifications aient été modifiées. LibreOffice et Word ont un gestion assez souple des polices. Ce qui parfois peut amener à des problème lors de l'impression ou au remplacement quand un caractère n'est pas disponible ou endommagé par la police par défaut, ce qui ne saute pas forcément aux yeux, surtout derrière un écran.

Je sens que je vais abandonner la programmation concernant les ttf's, le peu que j'ai essayé c'est épouvantable, sans compter les erreurs dont je ne sais pas si c'est lié au parsing de la ligne ou à autre chose :



Ce qu'on voit dans cette copie d'écran c'est l'erreur que voit le compilo quand je mets la souris sur le "Cr" de la ligne qu'on ne voit pas, masquée par l'infobulle : c'est CacheItem.Create(aFont);.

Et si je fais exécuter, c'est SIGSEGV systématique, et je n'arrive pas à trouver où ça coince.
Le problème de ces trucs c'est qu'il n'y a aucune aide et pour s'en sortir il me faudrait 3 ou 4 écrans, avec un seul c'est impossible.
(comment faisait-on, en 1993, avec des écrans 600x800 ? Je me le demande encore...)

Je te suggère de vérifier si par hasard, tu n'aurais pas oublié une parenthèse ouvrante, voir les deux. Le message d'erreur est qu'il ne trouve pas CacheItem.Createafont => membre non trouvé. Or la ligne du dessus est Cache.item.Create(afont).

[Jipété]

Je te suggère de vérifier si par hasard, tu n'aurais pas oublié une parenthèse ouvrante, voire les deux. Le message d'erreur est qu'il ne trouve pas CacheItem.Createafont => membre non trouvé. Or la ligne du dessus est Cache.item.Create(afont).

Ah, tu ne connais pas bien Lazarus, toi : l'oubli d'une parenthèse y est absolument repéré et tu te fais descendre en flamme par le compilo qui va t'envoyer bouler.
Pour ça, c'est bien fait, FreePascal et Lazarus.

D'ailleurs, la preuve après un redémarrage il y a 5 minutes :



Alors pourquoi un couple de parenthèses a-t'il disparu dans ces lignes qui compilent parfaitement bien, c'est un grand mystère pour moi...

Maintenant, je n'ai pas honte d'avouer que ces trois lignes sont écrites au pif ou plutôt, à l'aide de la complétion, n'ayant de la part de FreePascal aucune aide sur le sujet.
Probable que je me gourre quelque part, mais où ?
EDIT : bon, j'ai trouvé, j'utilisais mal la création de l'objet.

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
  s,aFont: string;
  sl: TStringList;
  CacheItem: TFPFontCacheItem;
begin
  ShowMessage(inttostr(gTTFontCache.Count));
  if (gTTFontCache.Count=0) then
    gTTFontCache.ReadStandardFonts;
  {$IFNDEF WINDOWS}
  AssignFile(F,'/tmp/fonts.txt');
  Rewrite(F);
  sl := TStringList.Create;
  aFont := ledFontNameTest.Text;
  CacheItem := TFPFontCacheItem.Create(aFont); // /!\  /!\  /!\ 
  if CacheItem <> nil then CacheItem.Create(aFont) else exit;
  sl.Add('Ascender '+IntToStr(CacheItem.FontData.Ascender));
  CloseFile(F);
  SortLines(sl);
  mmoFontsList.Clear;
  mmoFontsList.Lines.Assign(sl); // j'ai une data !
  sl.Free;
  {$ENDIF}
end;

Je vais pouvoir avancer (mais bon sang, qu'est-ce qu'il fait chaud !)

[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,