Bug 91139 - ttmkfdir creates wrong entries for "Arial Unicode MS" and similar
Summary: ttmkfdir creates wrong entries for "Arial Unicode MS" and similar
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ttmkfdir
Version: 9
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Yu Shao
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-05-19 11:46 UTC by Petr Pajas
Modified: 2007-04-18 16:53 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-09-10 02:53:40 UTC
Embargoed:


Attachments (Terms of Use)

Description Petr Pajas 2003-05-19 11:46:06 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401

Description of problem:
ttmkfdir creates wrong entries for some TrueType fonts
such as Microsoft Arial Unicode font like the following

arialuni.ttf -monotype-Arial Unicode MS-medium-r-normal--0-0-0-0-c-0-iso10646-1
arialuni.ttf -monotype-Arial Unicode MS-medium-r-normal--0-0-0-0-c-0-iso8859-1

The error is in the "-c-" part which should read "-p-" otherwise
the font appears monospaced on the screen with large gaps between individual
characters which makes it completely unusable. The correct
fontspecs should look like

arialuni.ttf -monotype-Arial Unicode MS-medium-r-normal--0-0-0-0-p-0-iso10646-1
arialuni.ttf -monotype-Arial Unicode MS-medium-r-normal--0-0-0-0-p-0-iso8859-1

Also note, that other versions of ttmkfdir available on the internet, such as
http://freshmeat.net/projects/ttmkfdir/?topic_id=850
work correctly.

The same (errorneous) behavior can be reproduced on 7.3 with up2date updates
(with the only difference that ttmkfdir is packaged with
XFree86-font-utils-4.2.0-8 in 7.3).

Version-Release number of selected component (if applicable):
ttmkfdir-3.0.9-1

How reproducible:
Always

Steps to Reproduce:
1.get arialuni.ttf
2.in the same directory run ttmkfdir -o - |grep "Arial Unicode"


Actual Results:  ...
arialuni.ttf -monotype-Arial Unicode MS-medium-r-normal--0-0-0-0-c-0-iso10646-1
arialuni.ttf -monotype-Arial Unicode MS-medium-r-normal--0-0-0-0-c-0-iso8859-1
...

Expected Results:  ...
arialuni.ttf -monotype-Arial Unicode MS-medium-r-normal--0-0-0-0-p-0-iso10646-1
arialuni.ttf -monotype-Arial Unicode MS-medium-r-normal--0-0-0-0-p-0-iso8859-1
...

Additional info:

Comment 1 Yu Shao 2003-06-05 01:17:55 UTC
The reason i am using -c- is because for X core font backend, -c- would improve
the performance a lot compared with -p-, are you having any problem with using
-p- at the moment?

Comment 2 Petr Pajas 2003-06-05 09:44:26 UTC
I don't understand the X internals, to really know what's going on and what's
the actual difference between -p- and -c-, but it can be simply observed that
-c- is really a bad choice for this particular font. To your question: 
 
No problems with -p-. The font is displayed proportional which is what it should
be. 
For some applications (eg. perlTk based ones), it takes a while to load that font 
(arial unicode ms) but I guess that's ok as Tk seems to be searching all available 
glyphs and the font is 20Mb large. All other applications (KDE, mozilla, GTK2) work 
smoothly with this font set to -p-. 
 
With -c-, it seems that perlTk based apps also load fast, but that's of no use
as the 
font is completely unusable being displayed as monospaced (or something like that) 
with very large gaps between individual letters. Since arialuni.ttf is one of
the rare 
fonts with almost compete unicode set it is a pitty it doesn't work right in RH by 
default. 
 
BTW, changing -c- to -p- manually in fonts.scale is a little tricky as ttmkfdir
is called in xfs init.d script on boot time so one has to either comment it out
or do some sed work right in the init script. So fixing this in ttmkfdir would
be a great help.
 
HTH, thanks. Petr 

Comment 3 Yu Shao 2004-09-10 02:53:40 UTC
It has been very long, I will close it for now, if needed for current
releases, please reopen it. Sorry for the delay.


Note You need to log in before you can comment on or make changes to this bug.