Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 7613

Summary: ttmkfdir creates foundry names with spaces, sends X into a spin
Product: [Retired] Red Hat Linux Reporter: paul
Component: freetypeAssignee: Preston Brown <pbrown>
Status: CLOSED WORKSFORME QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-02-17 17:25:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
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?