The fontconfig library that GIMP uses has such a cache already. You need to run
the fc-cache utility to create it. The installer is supposed to do that for you.

fontconfig would probably work under unix/linux versions of GIMP, but i'm using
MS windows. i don't think it's included, nor is it being used, in the installer
for GIMP for windows because i can't find it in the GIMP directory (after
installing GIMP). fc-cache can't also be found.

fontconfig is being used on Win32 as well and fc-cache is supposed to be part of
the GIMP binary package. I've reassigned your report to the Installer component
since it is obviously a problem with the binary installer for which we don't
offer any support at all. You will have to wait for the people taking care of
the installer to get back to you. Or try to contact them directly.

I don't really see what we can do about this report. There's a cache and it is
supposed to be used. I have no idea why it doesn't work for the bug-reporter.

This isn't really an installer-related problem.

fc-cache shouldn't be needed to create the font cache on Windows - actually it 
doesn't even work by default (the Fonts directory is has the Read Only attribute 
on XP, and fc-cache.exe refuses to write to it). On first startup, Gimp creates 
the font cache file in the user's home directory, and then uses that. The only 
way I could reproduce the problem was if .fonts.cache-1 in home directory was 
empty and marked Read Only.

Does this comment help? Can you please check file permissions?

Setting the bug to NEEDINFO awaiting feedback from the bug reporter...

i does help. i think my cygwin X server (or the part of it that deals with 
fonts) created the .fonts.cache-1 in my home directory and set its permission 
to read only so GIMP wasn't able to recreate the fonts cache. (i set my 
cygwin /home directory to point to "c:\Documents and Settings"). i deleted 
the .fonts.cache-1 and stated GIMP. It recreated the .fonts.cache-1. Thanks for 
the help.

This bug is fast becoming a FAQ. I recall a bug report which mentioned that the
.fonts.cache-1 file generated by the GIMP differed from the one which was there
after the installation (which was presumably created by fc-cache) - which one is
doing the wrong thing?

This doesn't appear to be an installer bug - setting component to Data.

Dave.

*** Bug 164067 has been marked as a duplicate of this bug. ***

Setting the component back to Installer. Data is the component for data files
shipped with GIMP, such as brushes, patterns and the like.

Installer is to do with Jernej's installer software - this is a problem with how
the GIMP interracts with fontconfig on win32 - setting component to General, in
the absence of anything better.

Dave.

Actually this appears to be a problem that should be dealt with in the
fontconfig library. But then, I don't see how the library (or GIMP for that
matter) could do anything about a read-only cache file. If the file is
read-only, it can't be updated nor can it be deleted. This can probably only be
solved with manual intervention. This would make it a documentation issue. One
thing we could consider to do is to add a dialog that informs the user that the
font cache cannot be updated due to permission problems. Would that be an option?

I had this problem in the past (but not now with 2.2 on a new computer in a new
job). I used several gtk+ apps - xchat, for one, gnumeric, an older GIMP (late
1.3.x and 2.0.x)- I don't know who generates the cache file, but I suspect
(Sven, correct me if I'm wrong) that if a .fonts.cache-1 file is present, that
the GIMP tries to parse it, and only falls back to loading the fonts manually if
it can't - the GIMP currently doesn't update the cache file in this situation, I
don't know why (removing the cache file as the actual user is possible, so it
wasn't read-only).

I assume that the problem comes down to (1) who's generating the .fonts.cache-1
file and (2) what does the GIMP do when it finds such a cache file, but cannot
parse it?

Dave.

It might be a good idea then for the installer to actually install fc-cache.

I explained this before, but I can explain it again for Dave. GIMP doesn't
actively read this file, nor does it create this file or touch it in any other
way. This happens transparently by means of libfontconfig.

Consider me a slow learner then. 

libfontconfig is an API used in the GIMP, I thought. Which means that
indirectly, it's the GIMP writing that file when we load fonts. Perhaps we're
not using the API correctly? Or different libfontconfigs are installed which
produce incompatible .font.cache-1 files? Or we are using libfontconfig
correctly, but FcConfigParseAndLoad() is returning FcFalse for some reason, and
FcConfigBuildFonts is returning FcTrue and we end up with a valid FcConfig
structure, but it's not being written by FcGlobalCacheSave (so we're building a
fonts cache, but not writing it or something) ?

I'm no expert in these matters, but it definitely feels like a GIMP bug, given
that the same problem doesn't affect other windows GTK+ apps. I have not yet
found the app which is guilty of generating the file which gives dodgy results,
but it might be the GIMP.

Other GTK+ apps are probably not using fontconfig directly. Anyway, I decided
not to care about Win32 bugs any longer so please try to solve this w/o me.

Other GTK+ apps aren't using fontconfig at all. They use the pango win32 backend
for GUI text rendering. We need fontconfig because we need the pangoft2 API to
do the text layer rendering. 

There might be a bug in fontconfig with regard to cache files. Someone who uses
windows just really needs to sit down and figure out exactly what's going on.

*** Bug 168877 has been marked as a duplicate of this bug. ***

If you open up the .fonts.cache-1 file in your fave text editor (emacs for
windows works for me) and do a query replace regexp for "lang=.*|en.*:" and
replace that with "lang=en:" and save then the startup times are TONS faster!

instead of seeing lang=aa|ast|...|zu: you just see lang=en: which took my
.fonts.cache-1 from 360KB to 261KB.

(I'm using Gimp 2.2.4 and GTK 2.6.4 currently)

The questions is why the .fonts.cache-1 seems to get corrupt. BTW, my cache file
is over 400kB in size, and there normally isn't any noticeable slowdown at startup.

I've seen this error myself, though, and can't explain why it seems to happen
randomly. I checked this with Filemon and it seems like the file get's read on
GIMP startup and a copy is written at the same time (which probably replaces the
original if there are any differences). Maybe this step fails for some reason.

forgive me if this is dumb and repeating whats been said...

As said before deleting .fonts.cach-1 solves the problem as another
(uncorrupted) .fonts.cach-1 is generated as soon as the GIMP is re-run. 

When i compare the old (bad).fonts.cach-1 with the new one i typically see the
following difference to each font refered to:- 

old:-   "D:\\WINDOWS\\fonts\\cga80852.fon" 0 998564400
"Terminal:style=Regular:slant=0:weight=100:pixelsize=8:spacing=100:antialias=False:index=0:outline=False:scalable=False:charset=
|>^0~|>^1!|>^1!|>^1!|>^1!|>^1!|>^1!P0oWQ:lang=aa|ast|ay|bi|br|ch|da|de|en|es|eu|fj|fo|fur|fy|gd|gl|gv|ho|ia|id|ie|io|is|it|lb|mg|nb|nl|nn|no|oc|om|pt|rm|sma|smj|so|sq|sv|sw|tn|ts|vo|wa|xh|yap|zu:fontversion=0"

new:-   D:\\WINDOWS\\fonts\\cga80852.fon" 0 998568000
"Terminal:style=Regular:slant=0:weight=100:pixelsize=8:spacing=100:antialias=False:index=0:outline=False:scalable=False:charset=:lang=:fontversion=0"

I also noted that the bad cach does not refer to the fonts that I have installed
since i first installed the GIMP.

does this make sense to anyone out there?

Hello everybody. I'm just a 'standard' user of GIMP from Argentina. I had the
problem reported in this bug since I installed GIMP 2.2.6 on my WinXP SP2. The
startup used to take almost four minutes. I thought it was because I have 826
fonts installed. Today, after installing GIMP 2.2.8 I found this report. I
deleted .fonts.cache-1 (which was 200Kb and was NOT a Read only file) and run
GIMP. After that, the new .fonts.cache-1 is 548kb, but GIMP starts up almost
instantly! Don't know if this info might be usefull. Sorry by my english.

I am merely a Windows user. Recently downloaded GIMP for windows.
I can only report what I see.
'Gimp Startup'.. 'looking for data files'.. progress is fine until it 
reaches 'fonts'. Then it hangs for, perhaps, several minutes. Afterward, 
progress proceeds apparently normally.
WinXP SP2.

Our Argentinian friend, Gaston, might have a clue for me...I think I need more 
info, but I'll see what I can discover.  

Colin, did you try deleting the .fonts.cache-1 file as suggested in the comments
here?

Yes, thanks!
I did... eventually. Had to 'Search' for it. Turns out it's in C:\Documents 
and Settings\[colin] folder. :^]
After deleting it, first GIMP Startup hung on 'fonts' again, but subsequent 
startups "almost instantly"..

If it's of any interest, both the deleted and the re-created files show as the 
same size [on disk] - 372kb.
Not marked as 'read only', but the option remains available.
 

Created attachment 56234 [details]
Corrupt font cache file

This is an example of a corrupt cache file - nothing obviously corrupt, still GIMP takes a long time at the fonts stage.

Created attachment 56235 [details]
Fonts cache, recreated

Same system, same fonts, this is the working cache automatically recreated after the previous one started to fail.

Maybe this helps to determine why the previous one is corrupt and how it got corrupted.

The only difference between the above two are the timestamps recorded, which are exactly one hour off. So there isn't really anything corrupt about it, but since Windows timekeeping is screwy, it's probably considered out of date.

If you stick the old "corrupt" file back into place, does the problem reproduce? And does GIMP eventually load, just after a while, or is it just stuck?

GIMP does load eventually. However, the modification dates of these file on my system have something in common that, regarding the obscure nature of this problem, shouldn't be discarded as mere coincidence:

- the corrupt file was last modified on 2005-03-27, the day DST started in Germany
- the working file was last modified on 2005-11-01, two days after DST had ended

I know that I renamed the first corrupt file on purpose, and might have just deleted the last one. Can anyone confirm that the problems described here started for him when DST starts or ends? (Just in case, DST == daylight saving time)

See http://www.codeproject.com/datetime/dstbugs.asp

I guess fontconfig needs to have some Win32 love applied, to fix up the broken timestamps that stat() returns.

*** Bug 340757 has been marked as a duplicate of this bug. ***

*** Bug 354723 has been marked as a duplicate of this bug. ***

*** Bug 421382 has been marked as a duplicate of this bug. ***

BTW, fixes for the stat() brokenness I mention in comment #31 are present in the fontconfig 2.3.2 and 2.4.2 Win32 binaries avilable from http://ftp.gnome.org/mirror/gnome.org/binaries/win32/dependencies/ . These fixes are not (yet, if ever) accepted upstream. (The diffs are at the same locations.) This is upstream bug https://bugs.freedesktop.org/show_bug.cgi?id=8526

*** Bug 430850 has been marked as a duplicate of this bug. ***

*** Bug 393800 has been marked as a duplicate of this bug. ***

This has been a problem for me on Vista32 since I upgraded to GIMP 2.2.15 and GTK+ 2.10.11. Not only is the cache file not used, but after I tried deleted it it wasn't recreated. The cache DID work with earlier versions of GIMP/GTK.

I'm on Daylight Saving Time right now, GMT+1, but disabling it has no apparent effect.

I too have this slow start up problem with Vista 32 Ultimate, GIMP 2.2.15, GTK+ 2.10.11

I found .fonts.cache-1 in my "home directory" and deleted it.
Ran GIMP again - slow - file not recreated.
Ran GIMP again, and again, slooooooooow  :-(

Maybe some Vista users could examine what exactly does happen on their systems? At least with Tor's patched libs, I do not see delays on DST changes anymore.

I'd love to. How do I? :-p

Same.  I'd happily look into it, if I knew what I'm looking for.  I'm not a Windows expert,  or gimp, or gtk, or ... oh wait, I'm useless.

I've looked at 'Event logs' and see nothing related, no idea where else to look. Sorry.

I should add, I had this same font problem also with slightly older versions of Gimp and GTK+,  the problem started for me when I upgraded XP to Vista.  So I upgraded to latest Gimp/GTK+ but obviously still have the problem.

No change with GTK 2.10.13 and GIMP 2.2.16.

> I've looked at 'Event logs' and see nothing related

Indeeed, nothing GIMP or GTK+-related puts anything in the Event log.

What you could do is download process monitor from sysinternals and check what files are accessed during the slow phase and which files take the most time.

> No change with GTK 2.10.13 and GIMP 2.2.16.

Nor was there any reason to expect any change.

I ran procmon and am now the proud owner of a 759MB CSV log-file! I noticed that GIMP re-read a lot of font files around the M mark many times before carrying on through the list, but other than that I'm not exactly willing to trawl through five million events unless I have something specific to look for...

I don't know if this helps, but it seems to me, that the problem with the font cache seems to be related to the version of the GTK-environment one uses.
I use Vista Home Premium and had no problem using the GIMP until I switched to GTK ver. 2.10.11. No font cache is created at all then.
Downgrading to GTK 2.6.4 solved the problem, even when I was using The GIMP 2.15. 
Now I use GIMP 2.16 and GTK 2.10.13, and the problem appeared again.

Is it safe to use older version of GTK with newer versions of GIMP?

>What you could do is download process monitor from sysinternals and check what
files are accessed during the slow phase and which files take the most time.

Ok then.

As Tom says, the resulting log file is huge.  
Here is an extract of what happens while loading 1 font, picked as a random example:

Column headings are Squence #, Time, Process Name, PID, Operation, Path, Result,  Detail:

109581	13:40:43.5352762	gimp-2.2.exe	4576	CloseFile	C:\Windows\Fonts\ariblk.ttf	SUCCESS	

109582	13:40:43.5356598	gimp-2.2.exe	4576	CreateFile	C:\Windows\Fonts	SUCCESS	Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened

109583	13:40:43.5357542	gimp-2.2.exe	4576	QueryDirectory	C:\Windows\Fonts\batang.ttc	SUCCESS	Filter: batang.ttc, 1: batang.ttc

109584	13:40:43.5358246	gimp-2.2.exe	4576	CloseFile	C:\Windows\Fonts	SUCCESS	

109586	13:40:43.5376720	gimp-2.2.exe	4576	CreateFile	C:\Windows\Fonts\batang.ttc	SUCCESS	Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a, OpenResult: Opened

109587	13:40:43.5379441	gimp-2.2.exe	4576	QueryStandardInformationFile	C:\Windows\Fonts\batang.ttc	SUCCESS	AllocationSize: 16,265,216, EndOfFile: 16,264,732, NumberOfLinks: 2, DeletePending: False, Directory: False

109588	13:40:43.5380213	gimp-2.2.exe	4576	ReadFile	C:\Windows\Fonts\batang.ttc	SUCCESS	Offset: 0, Length: 4,096, Priority: Normal

109590	13:40:43.5381517	gimp-2.2.exe	4576	ReadFile	C:\Windows\Fonts\batang.ttc	SUCCESS	Offset: 4, Length: 512

Following this there are many operations similar to the last one, with varying Offsets,  Length most often 512 but sometimes bigger, eg. 158k.

By "many" I mean for some fonts, around 4000 times.  I noticed this occured over 60,000 times for one particular .ttc file.

Does this help anyone ?   Anything else I can look at ?

Probably irrelevant but for completeness: There is also a "fastio_check_if_possible" operation accompanying every ReadFile operation, but these are excluded from the Process Monitor log by a default filter.

You should get in contact with the fontconfig developers as that is their code and we can't really do anything about the fontconfig performance in GIMP.

Thanks for running procmon.

If reading the information fontconfig needs for one (admittedly largeish, CJK TrueType Colletcion type one) font causes 60 000 "system calls", that does indeed sounds like some optimization in fontconfig (or freetype, is it?) would be a nice idea. 60 000 sounds like it is in the same order of magnitude as the number of glyphs in the file. Perhaps fontconfig/freetype should map the file into memory instead of reading it in small pieces. (I think Windows possibly itself already *has* all the system font files mapped into memory anyway, so it might even be that if a user program also maps such a file into memory, the mapping is just shared. Hmm, I am on a bit shaky ground here.)

(Win32 API calls like ReadFile() aren't quite equivalent to system calls on Unix, are they? I hope they are more lightweight?)

Anyway, the real problem here isn't so much that scanning font information is slow. The real problem is that for some reason, for some people fontconfig doesn't use caches, but has to do the slow scan each time GIMP starts. Could the reason for this be some bogus value of the TMP or TEMP environment variable perhaps? What are these for you?

Talking about different GTK+ versions here is not that informative unless people also tell what fontconfig and freetype versions are bundled with said GTK+ versions. Unfortunately, given Windows's nonexistent package management system, that is hard to find out. One thing people could do if they notice that this problem occurs for them in one version of "GTK+" but not anoother, is to check the size of the libfontconfig-1.dll and freetype6.dll files bundled with said GTK+ installations. Please report that here and I can try to identify them based on that. (Sadly these DLLs don't contain any version resource blocks.)

Fontconfig in GTK+ 2.6.13 installer is 2.4.2-tml-20070301 (same as with 2.6.11), and freetype is 2.3.5 (with 2.6.11 it was 2.2.1).

>Could the reason for this be some bogus value of the TMP or TEMP environment >variable perhaps? What are these for you?

TEMP=C:\Users\myusername\AppData\Local\Temp    - which does exist.
TMP= (the same)

>is to check the size of ...

freetype6.dll = 427,835 bytes.
libfontconfig-1.dll = 218,443 bytes.

I'm sorry, but I have to correct myself. 

Downgraded GTK+ version was of course "gtk+-2.10.6-1", with dlls "libfontconfig-1.dll" sized 210KB and "freetype6.dll" sized 445KB.

My current GTK+ version was (before I changed it back again) gtk+-2.10.13 with dlls "libfontconfig-1.dll" sized 217KB and "freetype6.dll" sized 434KB.

@Tom Edwards: It seems safe for me to use "gtk+-2.10.6-1" with "The GIMP 2.2.16", which solved the problem for me.

Seemingly, the problem really has to do with the GTK+ version.

> Seemingly, the problem really has to do with the GTK+ version.

Yes, but you should realize that this is only how it appears to you as a user, because the GTK+ installer bundles (also installs) the fontconfig and freetype software (DLLs). From a source code point of view these two are completely separate from GTK+. This bugzilla is about bugs in the source code in GTK+, GIMP, GLib, etc. fontconfig and freetype have their own (different) bug tracking systems. (But until we know what the root cause for these problems is, it isn't really useful to file bugs in either of them.)

(In fact, the GTK+ software as such doesn't even use fontconfig or freetype. GIMP does. A more correct name for the GTK+ installers would perhaps be "Installers for GTK+ and other software used by GIMP" or some such monster...)

To make the point perfectly clear, could you try this: Use the gtk+-2.10.13 installer, but then replace the freetype and fontconfig DLLs with the ones from the gtk+-2.10.6-1 installer.

When you are testing this, have you made sure you remove the fontconfig cache files between tests? In older fontconfigs, the cache file was called .fonts.cache-1 and it was located in the user's "home" directory, which on Windows (XP ant later) is the directory pointed to by the USERPROFILE environment variable. Newer fontconfigs use cache files in the folder fontconfig\cache under the user's temporary folder, which is the one pointed to by the TMP or TEMP environment variable.

I have made the tests now you have requested. I have replaced both files and one or the other with the following results:

Replacing freetype6.dll alone doesn't change anything, downgrading both results in   .fonts.cache-1 being created and therefore a much quicker start of the GIMP next time. Replacing libfontconfig-1.dll alone has the same effect and therefore seems to be responsible for the problem.

When using the new installation, simply no file is created, nor .fonts.cache-1 in my user directory or an alternative file in the folder /users/*/appdata/local/temp, which is the per user temporary directory on my system.

From my "user perspective": Does it make sense to store the font cache in a temporary folder, where it might be ocassionally deleted, so that the slow start of the GIMP reappears again and again?

>@Tom Edwards: It seems safe for me to use "gtk+-2.10.6-1" with "The GIMP
2.2.16", which solved the problem for me.

I'm now using this set-up. While the font cache is created, GIMP doesn't use it!

*** Bug 456799 has been marked as a duplicate of this bug. ***

Bingo!  Used the preveious libfontcache-lib.dll from my daughters PC and GIMP loads fast and furious on Vista now!

Alright, I tried the "run GIMP 2.2.16 on GTK+ 2.10.6-1" after uninstalling the new version that caused this bug.  Unfortunately, the installation of the old GTK+ complained about .DLL's (I forget what it said, because I was trying to just hurry up and see if it worked) so the new GIMP (and as it turns out the old GIMP) now refuse to install on the old GTK+.  Currently I'm running the new versions of both, with the --no-fonts argument, but even when I turn it off, .fonts.cache-1 is not recreated.  Since this happened when I upgraded the GTK, I'm guessing that the new libfontconfig-1.dll cannot properly create the .fonts.cache-1 file in Vista, thus forcing GIMP to manually cache all 415 of my fonts each time.  I think that a look into the .fonts.cache-1 creation section of libfontconfig-1.dll could show why the file isn't being made.  Once this file exists, the problem should go away.  

I'd do it myself, but I have no experience with .DLL's, I don't even know what language they are written in.  

If someone who knows a good bit about the C:\User\name folder in Windows Vista (where the .fonts.cache-1 file is stored) could take a look at the libfontconfig-1.dll source, I'd greatly appreciate it!

OR! even better idea.  If someone could upload a working (old) version of this DLL, I'd be happy with replacing my current one with it.  Just thought of this now... slow me.

(Also, all this could be completely off, I'm a tweaker/customizer/maintenance man, not a heavy duty coder, so I'm a bit out of my league with this stuff, but I like the GIMP, so I try.)

(In reply to comment #59)
> Used the preveious libfontcache-lib.dll

Is the file really named like this?

> Is the file really named like this?

It's libfontconfig-1.dll for me. I've replaced my recent version with a copy built in June 2006 to no avail though.

*** Bug 458727 has been marked as a duplicate of this bug. ***

*** Bug 461912 has been marked as a duplicate of this bug. ***

The way the font cache is handled has changed in more recent versions of fontconfig. Therefore, most of the discussion in this bug is obsolete. 

Let's close this bug accordingly and consolidate the new bugs into the one with the best description.

It is the new versions that are broke with Vista (requiring loading an older version), so is this really obsolete?  The other bugs submited were marked as duplicates to this one.  Is there another open bug report for the current fontconfig issue with Vista?

Instead of closing this bug as obsolete, I am marking it as a duplicate of bug #378153.  This is not perfect because these bugs do not address exactly the same issue, but at least it will not give you the feeling that this issue has been forgotten.  Some of the problems described here (and duplicate bug reports) seem to be more related to bug #378153 anyway, so it is not entirely wrong to mark this one as a duplicate.



*** This bug has been marked as a duplicate of 378153 ***

IMO it has been wrong for the more recent reports to be duplicated to this one, and it has been pretty much invalidated by mixing in the behaviour of two different reasons of fontconfig in the later comments as well.

Raphaël, I do hope that resolving it as a duplicate won't lead to a situation where we will have to close the new one for pretty much the same reasons.