Bug 56309 - xfs init script generate incorrect fonts.scale and fonts.dir
Summary: xfs init script generate incorrect fonts.scale and fonts.dir
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ttfonts-ja
Version: 7.2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-11-15 12:43 UTC by Akira TAGOH
Modified: 2007-03-27 03:49 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2002-03-22 07:14:48 UTC

Attachments (Terms of Use)

Description Akira TAGOH 2001-11-15 12:43:37 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20010901

Description of problem:
As you know when new TrueType fonts was installed, init script re-generate
fonts.scale and fonts.dir. However those files is too bad for ttfonts-ja.
Actually the XLFD in those files, foundry should be 'kochi' and family
should be 'gothic' and 'mincho', but it's not.

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

How reproducible:

Steps to Reproduce:
1.if ttfonts-ja have already installed, rpm -e --nodeps ttfonts-ja
2.reinstall ttfonts-ja
3./etc/init.d/xfs restart

Actual Results:  fonts.scale and fonts.dir has illegal XLFD like
'-misc-Kochi Gothic-*' and '-misc-Kochi Mincho-*"

Expected Results:  XLFD should be '-kochi-gothic-*" and '-kochi-mincho-*".

Additional info:

This problem is also ttmkfdir issue BUT I hope that you provide how to
inhibit to re-generate those files by init script because ttfonts-ja has
correct fonts.dir and fonts.scale probably and the re-generation may be
useful with another fonts.

Comment 1 Mike A. Harris 2001-11-20 03:15:27 UTC
I'm not sure what the problem is, but it most certainly is not
XFree86 at fault.  It is questionable wether the xfs initscript
should be doing what it is doing right now, but it seems the
best hack way to have useable fonts.  I am considering other
alternatives however for the future.  I think I may end up
removing the stuff from the initscript, and insist that all
font packages are created sanely.  Unfortunately, we can't
control external RPM packages, or users who want to install
fonts from a zip file, or from their Windows directories.

fonts.dir should *NEVER* ever be included in the RPM packaging.
These files should *ALWAYS* be generated during the postinstall
script phase of package installation, or at runtime afterwards.

Including fonts.dir files is just plain broken.  If ttmkfdir
or mkfontdir are broken, then they should be fixed.  If the
fonts.dir file that comes with the package works, then we need
to know how it was created perhaps, to fix the problem.  This
is a very important issue for future releases, so I'm raising
the priority.


Comment 2 Akira TAGOH 2001-11-21 09:53:57 UTC
it's basically correct. Ok, I put the problem in order.

Right now the fonts.dir which generated by xfs(ttmkfdir) is:
kochi-gothic.ttf -misc-Kochi Gothic-medium-r-...

I think that this result is natural because TTF doesn't have something that is
replaced with foundry.
However actually it should be -kochi-gothic-medium-r-...
what's misc? what's Kochi Gothic?
that font is the gothic style and is classified into the kind kochi. that font
also can be used instead of another 'gothic'.
it's impossible in that fonts.dir.

I don't think that want to spread inaccurate fonts.dir. Also I think that it's
impossible to make all generate automatically. 
So that I have one suggestion.
those TTF packages has hints file and fonts.dir and fonts.scale is made to
generate based on hints file.
hints file includes:
- foundry
- family name
- weight
- charset which is supported
and etc useful value.

I think that we may have thing like the font management tool.

Comment 3 Alexei Podtelezhnikov 2001-12-26 00:13:11 UTC
Okay. A couple more MAJOR issues, quite important in my view. I examined the 
ttfonts-ja (1.0-7) using Windows TrueType tool, freely available at 
www.microsoft.com/typography. I was suprised to find out the following:

1) A bare mentioning of the NAGA10 license, a non-free license. I couldn't find 
what exactly this means because all the info was in Japanese on the Internet. 
Debian, however, manages this issue around, I guess, by stripping those parts.
If this is the case for Red Hat, get rid of this notice!

2) The font does provide glyphs for gazillion other encodings besides japanese: 
Latin-1, Latin-2, Greek, Symbol, Cyrillic and so on an so forth.

Regarding (2), since the font does provide extra character encodings making it 
in fact ISO-10646-2 unicode font (again according to MS font tool), I think 
that the freetype tools do the _RIGHT_ thing by generating the _CORRECT_ 
fonts.dir and other files. The files generated during installation, however, 
are just artificially stripped of the right information. And I do agree with 
mharris that we could not possibly rely on static fonts.dir and others. What if 
a person wants to add a font to the directory [even if unlawfully, one's got to 
face it ;)]?

3) The name of the fonts is indeed Kochi Gothic, etc. with capitalized first 
letters and with a space in between. Again, the tools did the right thing.

4) watanabe fonts (the .ttf files) wasn't even recognized by Windows for 
installation. there is something wrong with them.

As for other possible solutions on the issue (2) I'll attache a comment to the 
other bug 57818.

Comment 4 Akira TAGOH 2001-12-26 12:11:41 UTC
1) I know. actually kochi fonts which is included in ttfonts-ja doesn't have
naga10 font. original kochi fonts provides 10pt and 11pt by naga10 font. you can
check it by ftdump or Windows TrueType tool.

2) kochi fonts doesn't have ISO-10646-2 font. the glyphs which is added in
ISO-10646-2 for Japanese is categorized JIS X 0213:2000 (aka 3rd and 4th
levels). but right now supported by kochi fonts is only 1st level and a part of
2nd level. I wonder why you think freetype tools which generates the encodings
which it doesn't have is correct.

3) it may be correct that fonts.dir which is generated _automatically_ by
ttmkfdir. but it's missing the alternatives.

4) No, probably that cause is that Windows doesn't support Shift JIS encoding.

Comment 5 Alexei Podtelezhnikov 2001-12-27 02:45:03 UTC
I checked, rechecked and double-checked. Kochi fonts allow and support 
characters from other encodings, according to Windows. They still come with 
fonts.dir that are later replaced by xfs initscript. When I try to uninstall 
them later. It's unclean: leaving *.dir.rpmsave and .scale.rpmsave.

I also tried ttfonts-ko. Those ttfs are clean. ttmkfdir likes them. nothing 
gets replaced. Windows 98 also reports only Latin-1 and Korean ranges as 
supported. Everything is consistent here. End uninstall is clean too. 

So this problem is specific to ttfonts-ja, while ttmkfdir treats them 

Comment 6 Mike A. Harris 2002-01-23 20:01:00 UTC
Owen, can you look into the ttmkfdir problems?  You mentioned
planning on making changes to it before,so perhaps you could
investigate it for us.  I understand debian and Mandrake both
have their own special ttmkfdir as well.  Might be worth looking

Any comment appreciated.

Comment 7 Won-kyu Park 2002-03-22 07:14:44 UTC
In the case of ttfonts-ko.

when I edit the /usr/share/fonts/ko/Truetype/fonts.alias

/etc/init.d/xfs regenerates fonts.dir and then original fonts.dir replaced
by new one.

but the name of the fonts are changed form -Baekmuk-Gulim-... to -misc-Baekmuk 
unigulir-... oops! (the same as ttfonts-ja ploblem)

(I think this problem as ttmkfontdir issue)

I suggest an alternative idea to make a fonts.dir

* Case: a ttf missed the Foundry info or, Foundry name is not registerd in
ttmkdir sources
* Solution: autogenerate Foundry name by the family name like following 

truncate first white space from family name and use first word as foundry!
use remaining as family name.

(ex) Kochi Gothic -> -Kochi-Gothic- ...)

Comment 8 Akira TAGOH 2002-03-22 07:55:21 UTC
Well, I noticed it's difficult that it will be generated all by ttmkfdir. I gave
up asking ttmkfdir for it, because this problem can be easy to fix using
Right now ttfonts-ja has fonts.alias. it will conduct to right way.

Comment 9 Yu Shao 2002-03-22 08:46:35 UTC
Will the changes from '-kochi-gothic-" to "-misc-Kochi Gothic-" or 
"-Baekmuk-Gulim-" to "-misc-Baekmuk" cause any problem? If Xfree works ok, then
it is ok, and ttmkfdir does the right thing.

Or any reason we have to use "-kochi-gothic-"? 

Comment 10 Akira TAGOH 2002-03-22 09:04:37 UTC
I already described about it. I'm not sure what's a problem for ttfonts-ko, but
ttfonts-ja had to do it at least.
Kochi Gothic is really 'gothic' and Kochi Mincho is really 'mincho'. so if the
users request XLFD like '-*-gothic-*' for example, it should come up for
'gothic', and we should not prevent it.
About ttfonts-ko, if these name is generic name, it should be provided, I think.

Comment 11 Yu Shao 2002-03-22 09:14:51 UTC
Oh, I see, I can have a look of ttmkfdir over weekend.

Comment 12 Yu Shao 2002-03-25 06:27:23 UTC
First, Information Dump:
                  VendID  Family Name         PostScript Name
kochi-gothic.ttf: Take    Kochi Gothic        Kochi-Gothic
kochi-mincho.ttf: Take    Kochi Mincho        Kochi-Mincho

batang.ttf:       HWAN    Ubatang             Ubatang
dotum.ttf:        IBM     dotum               dotum
gulim.ttf:        HWAN    Baekmuk-unigulir    Baekmuk-unigulir

Simplified Chinese:
fzsy_gb18030.ttf  BDFZ    FZSongTi            FZSYK--GBK-0
gbsn001p.ttf      ARPH    AR PL SungtiL GB    BousungEG-Light-GB

Traditional Chinese:
bkai00mp.ttf      ARPH    AR PL KaittiM Big5  ZenKai-Medium
Because ttmkfdir doesn't recognize "Take" "HWAN" and "BDFZ", so it will ouput
default "misc" as foundry name.Seems other than mapping "Take" to "Kochi", if we
don't standardize those names, nobody can do anything helpful.  

Comment 13 Akira TAGOH 2002-03-25 08:07:41 UTC
Yes, we absolutely don't do that.
See http://www.microsoft.com/typography/otspec/os2.htm#vendid

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