Compilation pleine d'erreurs d'un tout petit projet

Version imprimable

31/07/2024, 14h42
Jipété

Compilation pleine d'erreurs d'un tout petit projet
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:

1 2 //#include "../src/ttfParser.h" je mets les deux fichiers ensemble dans un dossier #include "ttfParser.h"
et juste après,
Code:

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.
31/07/2024, 15h32
deedolith

Salut,

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

Citation:

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 ?
31/07/2024, 18h16
Jipété

Citation:

Envoyé par deedolith

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.)

Citation:

Envoyé par deedolith

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.

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

Code:

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.:aie:
Petit test avec une police qui traine sur mon ordinateur

Code:

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.

31/07/2024, 19h30
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:

1 2 $ ./ttf_parser Unable to parse font /data/Almanach.ttf
Et pourtant il n'y a pas d'erreur :
Code:

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:

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, :resolu: pour la compil.
31/07/2024, 20h32
Obsidian
Salut,

Citation:

Envoyé par 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.

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.
Citation:
Donc ça s'exécute, bien, et je me prends un râteau :

Code:

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é.
Citation:
Et pourtant il n'y a pas d'erreur :

Code:

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.
Citation:
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:

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.

Citation:

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 ?
31/07/2024, 20h55
Jipété

Citation:

Envoyé par Obsidian

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, :P

Citation:

Envoyé par Obsidian

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é, :mrgreen:
31/07/2024, 22h03
Obsidian

Citation:

Envoyé par Jipété

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, :P

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

Citation:

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.

Citation:

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

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.
01/08/2024, 00h37
Jipété

Merci pour ta prise en compte de ce souci bizarre. :ccool:

Citation:

Envoyé par Obsidian

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, :mrgreen:

Citation:

Envoyé par Obsidian

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.)

Citation:

Envoyé par Obsidian

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, :plusser:

Citation:

Envoyé par Obsidian

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.
01/08/2024, 03h20
Obsidian

Citation:

Envoyé par Jipété

Merci pour ta prise en compte de ce souci bizarre. :ccool:

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, :mrgreen:

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.

Citation:

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.

Citation:

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, :plusser:

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. :-)

Citation:

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.

Citation:

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.
01/08/2024, 08h26
Jipété

1 pièce(s) jointe(s)

Bonjour,

Citation:

Envoyé par Obsidian

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à : Pièce jointe 657760
J'ai rajouté "mon" Almanach.ttf, juste parce que j'en ai parlé hier et sur le forum FP.

Citation:

Envoyé par Obsidian

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.

Citation:

Envoyé par Obsidian

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,

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:

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:

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

01/08/2024, 14h41
Jipété

2 pièce(s) jointe(s)

Ho gab', tu me sauves la vie !

Citation:

Envoyé par gabriel21

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 ! :

Pièce jointe 657772

Plus qu'à apprendre à maitriser l'animal, :mouarf:

Citation:

Envoyé par gabriel21

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 :

Pièce jointe 657773

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.
01/08/2024, 17h03
gabriel21

Citation:

Envoyé par Jipété

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.

Citation:

Envoyé par Jipété

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 :

Pièce jointe 657773

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).

1 pièce(s) jointe(s)

Citation:

Envoyé par gabriel21

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 :

Pièce jointe 657790

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:

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 !)

1 pièce(s) jointe(s)

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:

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:

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:

static int copyright_check = false;

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

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:

1 2 else if ( strcmp(pt,"n")==0 || strcmp(pt,"checkcopyright")==0 ) // à ajouter dans main copyright_check = true;
Recompiler et bingo !
Code:

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

Pièce jointe 657960
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:

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,