GNOME Bugzilla – Bug 132366
crashes when loading ( finding font )
Last modified: 2007-01-21 02:37:30 UTC
when loading gimp 2.0pre2 under windows I get this error in the consule: GLIB-CRitcal **: file gconvert.c line:498 <g_convert>: assertion 'str != NULL' failed seems almost like its not sending UNICODE or something like that because it happens when gimp is "looking for data files : fonts"
Presumably there is some font in your Windows font folder that somehow causes this. You could try running GIMP with the fontconfig debugging flag (environment variable) FC_DEBUG set to 128 and redirect GIMP's stderr and stdout to a log file. You should then be able to see from the log file which font causes the problem. Still, it would be better of course if fontconfig and/or GIMP would just silently ignore fonts that cause problems. And, it is possible that there really isn't anything wrong with the font in question (it just in some way is unusual), and that this is a GIMP bug.
fixed it! the problem was I need a HOME envirment varible ( I pointed it to the C:/ directory ) . Maybe the installer should do that ?
hm, Tor, isn't the windows port supposed to run without $HOME set?
Yes, it is supposed to work without any HOME. It is possible that a dependency on HOME being set has crept in lately.
I can't think of anything in the font code that would pass a homedir based string to g_convert. Reopening so the reporter can identify where they got their gimp build from, and really verify it happens during the font list code.
An easy way to check whether font loading is the culprit here, is to pass --no-fonts to gimp on the command-line. Could the bug reporter please do that and report back?
There is a problem in fontconfig-2.2.1. If HOME (or USERPROFILE) isn't set, when trying to save the cache file in that case, it crashes. Presuambly this is what causes your problem. The g_convert() warning must be a side-effect. A fixed version of fontconfig-2.2.1 is available now from the download page for GIMP on Windows (www.gimp.org/win32/downloads.html).
Resolving as FIXED, even if the bug as such was in fontconfig, so perhaps NOTGNOME would have been more appropriate?
*** Bug 134086 has been marked as a duplicate of this bug. ***
*** Bug 134306 has been marked as a duplicate of this bug. ***
*** Bug 134369 has been marked as a duplicate of this bug. ***
*** Bug 138122 has been marked as a duplicate of this bug. ***
"A fixed version of fontconfig-2.2.1 is available now from the download page for GIMP on Windows (www.gimp.org/win32/downloads.html)." I went out and grabbed "fontconfig-2.2.1-tml-20040201.zip" from www.gimp.org/win32/downloads.html and it appears to be the same version (it's the same size and has the same date/time) as what is included in the GTK 2.2.4- 20040124 I downloaded from http://www2.arnes.si/~sopjsimo/gimp/stable.html a couple hours ago. Anyhow, I replaced the original GTK 2.0 libfontconfig-1.dll with the new one I downloaded from www.gimp.org/win32/downloads.html and I still have the same crash problem. I checked in my windows\system directory and subdirectories for the DLL and didn't find a copy in there. Is this not the right URL for the fixed fontconfig dll? http://www.gimp.org/~tml/gimp/win32/fontconfig-2.2.1-tml-20040201.zip Would the HOME or USERPROFILE environment variable fix really matter if a specific .FON was in the fonts directory or not? I'm not sure how removing a font fixes the problem when I still don't have either environment variable fixed. I think this maybe a separate, unrelated issue. Sorry I'm not better at resolving this myself. I just wanted to let you know at least the proposed solution doesn't appear to work as described - unless I've overlooked something. Thank you for your assistance.
IIRC you need to remove the font cache (fonts.cache-1) so that it is regenerated with the updated software.
I removed the font cache file but it still crashes when launching. I looked at the cache file and seems to have all the fonts listed (a-z) but I didn't try to decipher and match them up with the font files installed in my fonts directory. The only method I have found at this point is to move the offending font (term_hex.fon) out of my windows font directory, blow away the cache, and start Gimp 2.0 If term_hex.fon is present in the font folder when Gimp is launched, it will crash. guaranteed (at least on my system :) Thanks again for your time with this. I'm willing to try anything you suggest, except getting rid of the font permanently :)
*** Bug 138191 has been marked as a duplicate of this bug. ***
I too am having this problem with GIMP 2.0.0. I think that perhaps it is because my HOME environment variable is set to %USERPROFILE% rather than a valid directory. This email seems to be talking about a similar problem: http://www.cygwin.com/ml/cygwin/2003-01/msg01546.html I'm going to see if I can figure out where in the registry I need to edit to fix this problem.
Created attachment 25979 [details] Reg file to fix HOME environment variable This patch sets the HOME environment variable for the current user to "%USERPROFILE%" using the REG_EXPAND_SZ type. It can fix brokeness that occurs when the key has the same value, but is of type REG_SZ
OK. You need to make sure that HOME is set to something valid (or possibly nothing at all). To check: * open up a command prompt (Start / Run / cmd or Start / Run / command) * type: "echo %HOME%" If it gives you a path that exists, it's ok. If it gives you something like %USERPROFILE%, then the registry key is of the wrong kind. Short story =========== Import the attachment I added to fix it (to what it most likely would be anyway). Long story ========== If the registry key specifying an environment variable contains a reference to a variable (something that looks similar to %FOO%) it needs to be of type REG_EXPAND_SZ. If it is of type REG_SZ, the variable is not replaced when the value is queried - leading to problems with Cygwin and GIMP. Officially, you should be able to fix it by going to the Control Panel and then System. Select the Advanced tab and hit Environment Variables. This gives you a list of the different variables available. Just edit HOME and it should save it as either a REG_EXPAND_SZ or REG_SZ depending on whether the value you've entered contains variables or not. This didn't work for me. I had to do the following instead: 1. Open RegEdit and go to HKEY_CURRENT_USER\Environment. 2. Take a look at the HOME value. If it contains a %.....% type value, it needs to be of type REG_EXPAND_SZ. Unfortunately RegEdit doesn't allow you to create such REG_EXPAND_SZ values, only REG_SZ values (at least in Windows 2000 it doesn't). 3. So export the HKEY_CURRENT_USER\Environment key (File/Export) 4. Edit the file so that I could import a HOME of type REG_EXPAND_SZ. (I just copied the line for TEMP which was a REG_EXPAND_SZ type value, changing TEMP to HOME in the copied version). 5. Import the registry file. 6. Edit the value using RegEdit so that it points to the correct place, rather than where TEMP is. I then re-exported it and trimmed the excess values to create the attachment I sent. You can use the attachment and then just edit the value if it doesn't suit you.
Perhaps someone should explain this to Keith Packard, the author of fontconfig. There should be ways to handle this problem.
I've had a report from someone who tried to manually set HOME=<valid dir> from a command line and it did not fix this problem for him. See also bug #136786 which describes the same problem and how setting HOME does not help. For the record, when RegEdit does not allow creating values of type REG_EXPAND_SZ, RegEdt32 does (this is valid for Win2K systems).
It is quite possible that there are third-party fonts out there that screw up fonctonfig and/or FreeType. The fontconfig and FreeType developer can't test with all broken fonts in the world, can they...? Especially as they mainly run Unix, and presumably mainly use fontconfig for TrueType or other scalable fonts. I don't know why fontconfig and/or FreeType even bothers to scan the bitmap (.fon) files. Anyway, if James could send the term_hex.fon file to me, I can check what it does to fontconfig, and then add a workaround for that (I have CVS write access to fontconfig).
*** Bug 138224 has been marked as a duplicate of this bug. ***
*** Bug 138194 has been marked as a duplicate of this bug. ***
Surely it's possible but looking at the list of dupes (see the above bug #138194, there are four people reporting the same problem in one single bug report) it seems that it's by far a too common problem to just say "there may be a few malformed fonts out there, let's ignore them" as it's a showstopper for so many people. It also bugged on me, not exactly in this way but as reported in bug #137550. I suspect that the root cause is the same in both cases and is related to the font cache handling, since in this case just removing the faulty font is not enough to avoid the problem: the cache must be deleted as well.
Thanks to James Olsen for sending me the term_hex.fon file. I can now confirm that there definitely is a bug somewhere. The question is just whether it is in fontconfig, freetype, pango or GIMP. The problem is that this font has a name that isn't a valid UTF-8 string. Reopening. (Actually it looks as if in the term_hex.fon case the name just has some random junk bytes at the end, but there might be other fonts for non-Latin scripts that has non-ASCII names on purpose, in whatever charset and encoding the font creator happened to use.) This name is propagated through FreeType, fontconfig and Pango without causing any warnings to GIMP, which then at gimpfontlist.c:161 proceeds to set the GIMP_TYPE_FONT object's name to this string. Later when GIMP sorts the font list, the name gets passed to gimp_object_name_collate() and then gimp_object_name_normalize(), which calls g_utf8_collate_key() on it. This causes a crash, as that expects the string to be UTF-8. Which is the correct place to fix this? From the GIMP user point of view it is of course best to fix it in the GIMP as it then will be fixed in GIMP 2.0.1. (I don't know if using gimp_any_to_utf8() as such is a good idea, it would seem a bit silly to havethea font called "Terminal_Hex (invalid UTF-8 string)", it would in cases like this where the majority of the string is ASCII be best to just drop the junk at the end.) But is it really Pango that should return only UTF-8 strings from pango_font_description_to_string()? Pango docs don't say what charset and encoding the string is in. I will attach the term_hex.fon file so that can verify that it causes a crash on Unix, too. (Presumably FreeType reads .fon files also on Unix?)
Created attachment 26001 [details] A problematic font file
On Linux this font does not cause a crash - and it can be used with the Text Tool.
> On Linux this font does not cause a crash Ugh, odd. What name does pango_font_description_to_string() give to the font? (Or actually, fonts. There seems to be three fonts in that .fon file, Terminal_Hex, Terminal_HexTall and Terminal_Ctrl+Hex.) For me, the names have some extra junk bytes at the end. What version of FreeType do you use? I have 2.1.5. Maybe later versions have fixed some bugs relating to the name returned for .fon fonts.
I use freetype-2.1.5 as well. According to the GIMP font list the three fonts are called: - Terminal_Ctrl+Hex - Terminal_Hex - Terminal_HexTall
Oh well. Might it then depend on what version of fontconfig you run? I run 2.2.1 (as do the other people running GIMP on Windows). Anyway, if the real mechanism why this font (and others, presumably, somebody has been mentioning some "profont" and describing workarounds that involve editing the .fonts.cacne-1 file) is problematic on Windows but not Unix can't be figured out, I guess it's best to just add a Win32-only workaround to gimpfontlist.c, making sure font names are UTF-8, truncating as necessary.
What does ftdump say on windows when you run it on that font? I don't see any non-ascii chars here.
ftdump run below. No non-ASCII chars here either. It only shows the Terminal_Hex family (font?) name, not Terminal_Ctrl+Hex or Terminal_HexTall. Presumably ftdump looks at a different location than those from which fontconfig gets the three names. How does this font show up in the .fonts.cache- 1 file on Linux? On Windows, the junk bytes are there after the three names. There is 1 face in this file. ----- Face number: 0 ----- font name entries family: Terminal_Hex style: Regular postscript: UNAVAILABLE font type entries FreeType driver: winfonts sfnt wrapped: no type: fixed size direction: horizontal fixed width: yes glyph names: no EM size: 0 global BBox: (0,0):(0,0) ascent: 0 descent: 0 text height: 0 fixed size 0: height 12, width 8 1: height 12, width 8 2: height 12, width 8 charmaps 0: platform: 3, encoding: 1
Created attachment 26013 [details] [review] Silly workaround for problem
ftdump for me prints info for all 3 faces. I'm pretty sure pango font descriptions are supposed to be in utf8. GIMP actually sets the family name directly from FcPatternGetString, which is supposed to return utf8 always. It looks for utf8, utf16, latin1, and converts to utf8 accordingly. fonts.cache-1 on linux doesn't show any bad characters. Maybe freetype on windows is mucking things up? Or the fontconfig logic for windows is buggy.. try making a simple program that calls FcFreeTypeQuery on the file and examine the pattern you get back.
Created attachment 26014 [details] Another offending font This font file makes my GIMP crash on my system.
That font doesn't cause any crashes here. The bitmap fonts don't actually render for me in the app, but there's no crash.
Just of curiosity: have You remembered to delete previous .fonts-cache-1? I get these (malformed) entries in .fonts-cache-1 (take a look at names: all of them have trashes after ProFontWindows): +"C:\\WINDOWS\\fonts\\profont.fon" 0 1035296146 "ProFontWindowsˇď:style=Regular:slant=0:weight=100:pixelsize=10:spacing=100:antialias=False:index=0:outline=False:scalable=False:charset= |>^1!|>^1!|>^1!|>^1!|>^1!|>^1!|>^1!|>^1!: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" +"C:\\WINDOWS\\fonts\\profont.fon" 1 1035296146 "ProFontWindowsxxxxxˢ:style=Regular:slant=0:weight=100:pixelsize=11:spacing=100:antialias=False:index=1:outline=False:scalable=False:charset= |>^1!|>^1!|>^1!|>^1!|>^1!|>^1!|>^1!|>^1!: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" +"C:\\WINDOWS\\fonts\\profont.fon" 2 1035296146 "ProFontWindows└└└└│:style=Regular:slant=0:weight=100:pixelsize=12:spacing=100:antialias=False:index=2:outline=False:scalable=False:charset= |>^1!|>^1!|>^1!|>^1!|>^1!|>^1!|>^1!|>^1!: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"
Oops... I should have create this as attachment, sorry for messing up the screen...
Don't have to delete it, running fc-cache will regen the cache file since it notices the directory has changed. The cache file has sane values in it. This might be a freetype bug, with a missing nul terminator. On windows you might be getting unlucky and the uninitialized data is garbage, whereas on linux it's 0'd anyway. Can someone try with freetype 2.1.7+ on windows?
For some reason the guy(s) providing the Windows binaries of FreeType (gnuwin32.sourceforge.net) have changed the name of the DLL to freetype6.dll in their 2.1.7 distribution. It was freetype-6.dll in 2.1.5. I don't know if this change sigifies an incompatible ABI and/or API change (in which case one would need to recompile Pango, fonconfig and GIMP), or whether just renaming the DLL to the old name would work. Will have to take a look... Yosh's guess that it's just a coincidence that these fonts get garbage appended to their names on Win32 but not on Linux sounds probable.
It would be nice to provide a Windows binary with freetype-2.1.7 and fontconfig-2.2.2 since that could fix quite some problems. Even nicer would be Pango-1.4 to get the fix for bug #101856 out to the people but I guess that will be more problematic. In GIMP, I think we should add a call to g_utf8_validate() on the font name before we accept a font. That will mean that broken fonts aren't available at all, but that's certainly better than a crash.
If anyone want's to try freetype 2.1.7: freetype-config doesn't list the additional dependencies yet. Change line 91 of this script to: libs="-lfreetype -lz -lgw32c -lole32 -luuid -lwsock32" This is reported, and will hopefully soon be fixed.
*** Bug 138319 has been marked as a duplicate of this bug. ***
I've committed a workaround for this problem: 2004-03-28 Sven Neumann <sven@gimp.org> * app/text/gimpfontlist.c (gimp_font_list_add_font): validate the font name. This should work around the crashes that Windows users were experiencing on startup (bug #132366). The real problem needs to be fixed elsewhere though.
fontconfig 2.2.1 has problems with freetype 2.1.7, people should use at least 2.2.2
*** Bug 136786 has been marked as a duplicate of this bug. ***
*** Bug 138364 has been marked as a duplicate of this bug. ***
Some more random comments: - Why does this problem show up only with some .fon files, but for them consistently for all (?) Windows users who have them? - If you look into the term_hex.fon file, it does have NULs after the name(s). So maybe some other field in the font header(s) is screwed up and causes FreeType to overwrite the bytes in the header that follow the name? But quite a coincidence that it would overwrite those couple of bytes, but otherwise leave the font functioning? Huh? Has anybody run Purify on fc-list with this font present? - Using Pango 1.4.0 would indeed be a good idea. That requires GLib 2.4.0, so I think I'll wait for GLib 2.4.1 first.
The two .fon files pasted here are all multiface files. That may have something to do with it.. or is multiface common? fc-cache on the two fonts here is valgrind clean with freetype 2.1.7. All I know is that the winfont driver has gotten some updates since 2.1.5 so it'd be worth it to try the newer version.
It seems that the freetype version included with the installer is 2.1.7; however I could not determine the fontconfig version because it lacks version information other than using FcGetVersion, which I don't have access to. Tor: I have frequently seen misused Windows API functions that return a buffer and a length but the buffer is not specified to return a string with a trailing NULL, while the programmer assumes it does. May this be just another instance of that misuse?
But FreeType doesn't use the Win32 API to access fonts, does it?
No, it doesn't.
*** Bug 138509 has been marked as a duplicate of this bug. ***
Further investigation has led me to the following conclusion: the problem is in Freetype. Specifically, the font name happens to be the last resource in a frame and the frame size does not include the trailing \0. In the sample ProFont.fon, at offset 0510h starts the .FON font structure about which you can learn e.g. here: http://www.csn.ul.ie/~caolan/publink/winresdump/winresdump/doc/resfmt.txt Note that the dfSize member in this case equals 0E92h, and exactly at offset (0510h+0E92h) = 13A2h there's the trailing \0 which should end the string. However looking at freetype-2.1.7/src/winfonts/winfnt.c lines 184 and 502 it seems that this trailing \0 is never loaded but the string is used as is. The fact that it works properly under Unix somewhat puzzles me. I have not investigated the streaming functions of Freetype so I can't tell what's a good fix for this problem. Of course checking the validity of the font name string can't hurt and is even a healthy practice.
*** Bug 138548 has been marked as a duplicate of this bug. ***
*** Bug 138593 has been marked as a duplicate of this bug. ***
*** Bug 138622 has been marked as a duplicate of this bug. ***
Look in the file: C:\Documents and Settings\YOUR_NAME_HERE\.fonts.cache-1) Open notepad and look for the lines contaning: "profont". Delete these lines and everything will work great for you. /Mattias NOTE TO ERROR! What I did was look through every line of the file, you can open it in Notepad and read it easily. Doing this I found that the entry for the font "profont" has some vertical lines that no other font had, and one of the line ended before the other and kept on going on the line below. I deleted every line that was about profont (being careful to leave no blank lines after I was finished ). I restarted gimp and it got past the font part and kept on going fine. Now it starts everytime fine. /Jon Hoskin
Reply from Werner Lemberg on the FreeType development list: > Further investigation has led me to the following conclusion: the > problem is in Freetype. Specifically, the font name happens to be > the last resource in a frame and the frame size does not include > the trailing \0. According to the winfnt document I have this must not happen. The order is WinFont header <face name> <device name> <bitmap data> So the face name can never be the last resource in a (FreeType) frame, provided the FON file is following the specification. An exception is an empty FON file but I think this is not what you have in mind... > In the sample ProFont.fon, at offset 0510h starts the .FON font > structure [...] > > Note that the dfSize member in this case equals 0E92h, and exactly > at offset (0510h+0E92h) = 13A2h there's the trailing \0 which > should end the string. But 13A2h is outside of the frame which size is given by dfSize! The valid range is from 0510h to 13A1h, which gives 0E92h bytes. This means that your test font is even invalid since the specs say that the NULL terminator must included for computing the field size. > However looking at freetype-2.1.7/src/winfonts/winfnt.c lines 184 > and 502 it seems that this trailing \0 is never loaded but the > string is used as is. The fact that it works properly under Unix > somewhat puzzles me. As mentioned above, it seems that your test font is not following the specs, and I probably have never seen such a beast. > I have not investigated the streaming functions of Freetype so I > can't tell what's a good fix for this problem. Indeed, it's not easy to find an elegant solution. > Of course checking the validity of the font name string can't hurt > and is even a healthy practice. Please send me the offending FON file (ProFont.fon?); I'll try to fix it. [I'll send him the two fonts attached to this bug.]
BTW, as so many people seem to have problems with this profont.fon font, does anybody know where it comes from? Are there perhaps several versions available? (The one attached to this bug contains the string "ProFont Distribution 2.2").
Hmm, yes, Google is your friend of course... Profont is apparently from here: http://www.tobias-jung.de/seekingprofont/index.html
I think it is not a problem with a single font. Apparently it is created by "Fontographer" and probably many fonts created by it will be affected. Even if the font is broken, IMO a workaround should be coded into Freetype as it seems to be a common case. I doubt that all of the reporters of this bug had a problem with that precise font. See e.g. bug #136786 which talks about problems with 07_table.fon, and so on. For the record, I was not claiming that Freetype was doing anything wrong. I've just tried to point out where the problems come from; of course there's the premise that says "Be strict with what you write, and tolerant with what you read" (maybe the wording is different but you get the idea).
i don't have the word profont in C:\Documents and Settings\YOUR_NAME_HERE\.fonts.cache-1 . But after renaming it to see what would happen, win created a new one which isn't making problems now. gimp runs just fine. i don't understand what I've done at all but it worked great for me :D
I've tried the comment #64 re: deleting lines from the .../fonts.cache-1 file. There were many fonts listed in this file on my computer, and I simply deleted everything after the first 10 or so lines, saved, and started GIMP. YEAH! GIMP now launches correctly, so it appears, something about one or more fonts listed in this fonts.cache-1 file directly affects whether GIMP 2.0 crashes on my WinXP/J computer or not. (The other tricks noted did nothing at all.) That said, 1) I didn't find any 'profont' lines at all, so this affects fonts beyond Profont (brand?) 2) I've got far too many fonts to see which ones are affected by their deleting from the fonts.cache-1 file to post right now, but I could if anyone thinks this would help.... In any case, the 'proper' behaviour here would simply be to note which line(s) are unacceptable, and simply skip those fonts rather than crashing, IMO.
Werner Lemberg confirms: This is indeed a bug in the font. Compare this e.g. with coure.fnt, and you can see that the strings are NULL-terminated, and this last byte is still part of the resource. I've fixed this problem now in FreeType's CVS. Please test. From FreeType's ChangeLog: 2004-03-31 Werner Lemberg <wl@gnu.org> Handle broken FNT files which don't have a trailing NULL byte in the face name string. * src/winfnt/winfnt.h (FNT_FontRec): New member `family_name'. * src/winfnt/winfnt.c (fnt_font_done): Free font->family_name. (FNT_Face_Init): Append a final zero byte to the font face name. I haven't yet decided whether I'll just backport that localized change to FreeType 2.1.7 and build and distribute that, or build a FreeType2 CVS snapshot and distribute that, or do nothing. Probably do nothing ;-) Sven added a workaround to GIMP some days ago. GIMP now just ignores fonts with bogus (non-UTF8) names, so these buggy fonts won't crash GIMP 2.0.1. On the other hand, some of these Fontographer-created fonts might actually be useful, so maybe somebody really would like to use them in GIMP? Closing this as FIXED, as there is now a workaround in GIMP's source, and FreeType2 also has a fix.
Tor, it would be very helpful if you can provide a patched Freetype that people can be pointed to to replace the current one. This would also prevent people from complaining about missing fonts because of a bad name. In any case, thank you very much for your help submitting the issue to the Freetype list and for keeping us Bugzilla readers informed on the outcomes. Manish: thank you too; comment #40 turned out to be pretty accurate and guiding.
Tor: uh, I didn't realize that you don't provide Freetype but refer to the gnuwin32 project's package. In that case probably the above does not apply. Sorry.
*** Bug 138910 has been marked as a duplicate of this bug. ***
*** Bug 138961 has been marked as a duplicate of this bug. ***
I am reopening this report to increase the chance that people can find it. Should avoid some duplicates. We can close it again as soon as there are binary packages available that contain the fix.
*** Bug 139038 has been marked as a duplicate of this bug. ***
Just FYI, also causing the startup crash is mangal.ttf that ships with Windows XP by default Available from http://irfca.org/users/delhimetro/fonts/mangal.ttf And some third party: http://www.tactile3d.com/tristan/ For example: http://www.tactile3d.com/tristan/Download.php?get=ProggyClean.zip Delete those fonts from %WINDIR%\Fonts and no more crashing. Windows XP SP1 GTK+ 2 (2.2.4-20040124), GIMP 2.0.0 from: http://www2.arnes.si/~sopjsimo/gimp/stable.html
*** Bug 139652 has been marked as a duplicate of this bug. ***
Keeping this report open doesn't seem to help much, so I will now close it again so that it doesn't appear on the list of bugs on the 2.0.1 milestone.
*** Bug 139708 has been marked as a duplicate of this bug. ***
*** Bug 139997 has been marked as a duplicate of this bug. ***
*** Bug 140263 has been marked as a duplicate of this bug. ***
*** Bug 140310 has been marked as a duplicate of this bug. ***
*** Bug 140372 has been marked as a duplicate of this bug. ***
*** Bug 140407 has been marked as a duplicate of this bug. ***
I've tried deleting the cache file, deleteing records in the cache file. renaming the cache file. uninstalling adn reinstalling gtk and gimp to no avail. Does anyone have any other ideas on how one might go about solving this problem. I am a little confused as to why this is closed. It seems that this is still a recurring issue.
> Does anyone have any other ideas on how one might go about > solving this problem. Sure, didn't you read the comments? The problem has been fixed (by adding a workaround) in GIMP, and by fixing the root cause in FreeType. Unless you build GIMP yourself, just wait for a newer build of GIMP to be made available. Also at some point a new FreeType version (source code) will be released, and a binary build for Windows distributed by the gnuwin32 folks some time later. > I am a little confused as to why this is closed. It seems that > this is still a recurring issue. It is fixed in the source code, which is what Bugzilla is about. The GIMP developers don't want to (and shouldn't have to) concern themselves with what binary builds of versions are available for what platforms at what time.
Hi Tor Lillqvist, now we got the GIMP 2.0.1 in a fine installation script, and I tried it on my Win2000 SP2 Professional German OS. But the crash on the selection of a font is still not yet fixed in 2.0.1. Regards: Hermann
Noone said it would have been fixed in GIMP. The bug and the fix is in freetype. Version 2.1.8 has just been released.
Hey, I tried several times over the last year to load Gimp and it always crashed when it tried to start. This time, after reading several comments all over the net, I downloaded the latest version of freetype6.dll from you site---the binary file. Then, I searched for freetype6.dll. It was in three locations on my computer. It was under phpserver/xampp/apache and phpserver/xampp/php4. But I believe the offending instance was under windows common files. I replaced it with the one from your site and VOILA!! I got the GIMP. Oh yea! You need to make your install overwrite older versions!!
By the way. No one has more fonts than me!