Hello,
Here is the end of my torments.
I recap: I currently have 935 ttf and otf files, some dating back 30 years and having always worked well, in general and under Windows.
It was when switching to Linux that a problem appeared, when trying to use the option to know the location of the files, useful for their management, which generated a SIGSEGV exception for 17 of them, I mean the
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;
function that relies on the fpTTF.pp unit and that I modified like this because I was tired of the complete shutdown of the program in the event of a problem with one or more fonts:
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('Problem with font '+fName);
end;
end;
And I quickly realized that when FindFont didn't return anything, it was because the string fields HumanFriendlyName, PostScriptName and FamilyName were empty!
These 3 fields (as well as the FileName field, which is never empty since it defines the current file) are in the fpTTF.TFPFontCacheItem object, public section.
So I had 935 True/OpenType files, 17 of which were not present in the Family list of a tool being created, and I should point out right away that these 17 files are perfectly usable in the Windows world, exactly like the other 918. In the Linux world, it's random...
I then started to examine the inside of the 17 files with a Perl tool (ttftable from the Font-TTF-Scripts-1.06 library + installation of the libfont-ttf-perl package [read:
http://scripts.sil.org/FontUtils, download:
https://github.com/silnrsi/font-ttf-scripts.git]) which extracts the "name" tag in a binary file to examine with a hex editor in which I was able to see that the fields returned empty by the FreePascal tool were indeed present in the 17 files!
Usage:
ttftable -export "name=try" /path/fontname.ttf
will generate a file in the folder opened to launch the script, a script that I was not able to automate with TProcess, too bad, but since there were only 17 files, I wasted less time processing them one by one by hand.
A confirmation by another tool from the FontForge suite (showttf.c, download:
https://github.com/fontforge/fontforge/blob/master/contrib/fonttools/showttf.c then a small modification to have access to the values of the fields [addition of an option "-n" like "name":
add at the very top under "static int head_check = false;" the line
static int copyright_check = false;
then add in "readit" under block "if ( head_check ) {" the block
if ( copyright_check ) {
if ( info.copyright_start!=0 )
readttfname(ttf,util,&info);
return;
}
and at the very bottom in the main, after "head_check = true;", add
else if ( strcmp(pt
,"n")==0 || strcmp(pt
,"checkcopyright")==0 ) // to add in main copyright_check = true;
Recompile and bingo!
$ ./showttf -n /filepath/afile.ttf
blablabla
...
])
and for me the case is closed: all the fields necessary and useful for the proper functioning of the fonts are present in the files and used by the appropriate tools EXCEPT those that rely on FreePascal's fpTTF, which may have random behavior.
What made me persist in all this was the fact of noticing that these famous fields absent in FreePascal were indeed present with an old Windows tool, I named Softy.exe, which allowed me to generate this magnificent image where we notice that there are only 16 thumbnails because, for a reason that I do not know, the Windows wingding.ttf font (about 30 years old!) violently crashes Softy and since we do not have its code, it will stay like that especially since under Linux with showttf and my addition I have my information:
$ ./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
platform=1 plat spec encoding=0 language=0 name=2 Subfamily
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
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...
The most observant will notice that in the image there is twice the same font: in the second line the first two thumbnails show the same data, however coming from two different files but it is not visible there and I do not know why I had fun making a modification of I do not know what... Do not take it into account, this large image is mainly there to show that these 16 files are accessible under Windows with a tool dating back to Windows 3.1 while the last of the FreePascal/Lazarus couple is not capable of it, alas.
The only thing that remains pending and bothers me is that I have not found why these 17 files only and not the others generate an error.
We can get around it but it is "not finished".
That's all.
Have a nice day,
Recent
