02-13-2020, 02:33 PM
(This post was last modified: 02-13-2020, 09:41 PM by QuinB.
Edit Reason: Update on information
)
The solution to the 'fonts won't leave' problem seems to have been that the font files were present on the C:\Windows\Fonts directory but Windows did not have them loaded.
How that happened is a little difficult to say – my leading (but untested) hypotheses are either:
HOWEVER.
While it is possible for Windows not to know of the existence of a file in the C:Windows\Fonts directory, it appears that Gimp's font acquisition system access some font files in C:Windows\Fonts and also interrogates the C:Windows\Fonts\StaticCache.dat at startup and WILL pick up the existence of files Windows doesn't know about, presenting them in the Gimp fonts list as normal.
Notes.
The underlying problem being investigated, that Gimp does not show all font names for some font families, substituting
fontname
fontname #1
fontname #2
fontname #3
and presenting a system default font instead of the required glyphs for anything labelled with '#n', seems to be related to some form of non-unique identifier within the font files being presented to Gimp; if a single file, only, is loaded, it can be used correctly within Gimp, no matter what occurs when multiple files for the font family are loaded. As soon as multiple files are loaded, the only usable font appears to be the first one in the list lexically (I have not yet identified the sort field – see below).
There seems to be no difference in font behaviour whether the font files are presented via Windows or placed in a directory referenced from Gimp's Edit > Preferences > Folders > Fonts
Examination of the font files in Fontforge shows no obvious duplicated label in the fonts under test (a commercial OpenType edition of Farmhouse 1.0 and Farmhouse Rough 1.0) – it would have to be obvious because I am not a FontForge expert.
[EDIT]
With respect to the underlying problem stated above, the otf file has the FontForge 'TTF names' entry
String ID: Preferred Family
String: Farm House Rough
common to all the files in the font set.
This value is then picked up by Gimp and, as it is not unique, causes the additional fonts in the set to be unavailable.
Removal of the non-unique Preferred Family string allows the PS Names 'Family Name' string to be used which, in this font set IS unique.
How that happened is a little difficult to say – my leading (but untested) hypotheses are either:
- The fonts were in use when uninstalled so, while the system definitions had been removed, the files were still in place
- Windows has more than one font maintenance route (accessing C:Windows\Fonts via Windows Explorer / Settings>Fonts) and a disparity arose between them.
HOWEVER.
While it is possible for Windows not to know of the existence of a file in the C:Windows\Fonts directory, it appears that Gimp's font acquisition system access some font files in C:Windows\Fonts and also interrogates the C:Windows\Fonts\StaticCache.dat at startup and WILL pick up the existence of files Windows doesn't know about, presenting them in the Gimp fonts list as normal.
Notes.
The underlying problem being investigated, that Gimp does not show all font names for some font families, substituting
fontname
fontname #1
fontname #2
fontname #3
and presenting a system default font instead of the required glyphs for anything labelled with '#n', seems to be related to some form of non-unique identifier within the font files being presented to Gimp; if a single file, only, is loaded, it can be used correctly within Gimp, no matter what occurs when multiple files for the font family are loaded. As soon as multiple files are loaded, the only usable font appears to be the first one in the list lexically (I have not yet identified the sort field – see below).
There seems to be no difference in font behaviour whether the font files are presented via Windows or placed in a directory referenced from Gimp's Edit > Preferences > Folders > Fonts
Examination of the font files in Fontforge shows no obvious duplicated label in the fonts under test (a commercial OpenType edition of Farmhouse 1.0 and Farmhouse Rough 1.0) – it would have to be obvious because I am not a FontForge expert.
[EDIT]
With respect to the underlying problem stated above, the otf file has the FontForge 'TTF names' entry
String ID: Preferred Family
String: Farm House Rough
common to all the files in the font set.
This value is then picked up by Gimp and, as it is not unique, causes the additional fonts in the set to be unavailable.
Removal of the non-unique Preferred Family string allows the PS Names 'Family Name' string to be used which, in this font set IS unique.