|Summary:||ttmkfdir creates foundry names with spaces, sends X into a spin|
|Product:||[Retired] Red Hat Linux||Reporter:||paul|
|Component:||freetype||Assignee:||Preston Brown <pbrown>|
|Status:||CLOSED WORKSFORME||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2000-02-17 17:25:54 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description paul 1999-12-06 01:02:18 UTC
Running ttmkfdir in a fairly standard Win98 /windows/fonts directory creates a fonts.scale file which contains spaces in the foundry (or is it family?) names. After adding this directory to the font path and restarting the X font server, any operation that uses fonts (e.g. xlsfonts) sends X into a fairly tight loop. I'm not sure whether this is an X problem (i.e. spaces in foundry names not handled properly) or a ttmkfdir problem (i.e. spaces in foundry names are illegal but it puts them there anyway). Either way, replacing the names containing spaces with made-up abbreviations without spaces fixes the problem.
Comment 1 Preston Brown 2000-01-13 03:58:59 UTC
fixed for 6.2. and yes, it is the family name, not foundry name, that causes problems.
Comment 2 paul 2000-01-13 09:12:59 UTC
Which was the problem: ttmkfdir creating invalid names, or X not handling valid ones?
Comment 3 Preston Brown 2000-02-16 15:50:59 UTC
paul: I'm having doubts about the validity of my patch. Can you show me the lines in the old fonts.dir that were giving you problems?
Comment 4 Paul Gear 2000-02-16 17:40:59 UTC
No problems, Preston. I ran this command in my Win98 fonts directory: awk -F- '$2 ~ / /' fonts.scale Here are some of the matching lines (i'm sure bugzilla will mangle the word wrapping, but you should get the picture): desdemon.TTF -The Font Bureau, Inc.-Desdemona-medium-r-normal--0-0-0-0-p-0-ascii-0 gradl.TTF -The Font Bureau, Inc.-Gradl-medium-r-normal--0-0-0-0-p-0-ascii-0 lhandw.ttf -Bigelow & Holmes-Lucida_Handwriting-medium-r-normal--0-0-0-0-p-0-ascii-0 lhandw.ttf -Bigelow & Holmes-Lucida_Handwriting-medium-r-normal--0-0-0-0-p-0-fcd8859-15 lhandw.ttf -Bigelow & Holmes-Lucida_Handwriting-medium-r-normal--0-0-0-0-p-0-iso8859-1 lhandw.ttf -Bigelow & Holmes-Lucida_Handwriting-medium-r-normal--0-0-0-0-p-0-iso8859-15 I mangled the second field by hand to remove the spaces and it works fine.
Comment 5 Preston Brown 2000-02-16 19:11:59 UTC
and if you change lhandw.ttf -Bigelow & Holmes-Lucida_Handwriting-medium-r-normal--0-0-0-0-p-0-fcd8859-15 to lhandw.ttf -Bigelow & Holmes-Lucida Handwriting-medium-r-normal--0-0-0-0-p-0-fcd8859-15 It breaks X?
Comment 6 Paul Gear 2000-02-16 21:55:59 UTC
Sorry - i was not clear enough there. Here is a broken entry: lhandw.ttf -Bigelow & Holmes-Lucida_Handwriting-medium-r-normal--0-0-0-0-p-0-ascii-0 And here is the equivalent entry that works: lhandw.ttf -bigelowholmes-Lucida Handwriting-medium-r-normal--0-0-0-0-p-0-ascii-0 The first one was created since i upgraded to the Rawhide version you made, and the second beforehand. It looks like you fixed the wrong field. I haven't actually tested it since you released the rawhide version, as i'd found the workaround.
Comment 7 Preston Brown 2000-02-17 17:25:59 UTC
I can't duplicate the tight loop with XFree86 3.3.6 (for next release) and spaces in either the foundry or the font name, so I am reverting this patch. I tested both xlsfonts and xfontsel.
Comment 8 Paul Gear 2000-02-26 01:31:59 UTC
OK - no problems. Is there any way we can get a reminder from Bugzilla to test this once the new version is released?