From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) 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):
Steps to Reproduce:
1.if ttfonts-ja have already installed, rpm -e --nodeps ttfonts-ja
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-*".
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.
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
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:
- family name
- charset which is supported
and etc useful value.
I think that we may have thing like the font management tool.
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.
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.
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
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.
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
* 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- ...)
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.
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-"?
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.
Oh, I see, I can have a look of ttmkfdir over weekend.
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
fzsy_gb18030.ttf BDFZ FZSongTi FZSYK--GBK-0
gbsn001p.ttf ARPH AR PL SungtiL GB BousungEG-Light-GB
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.
Yes, we absolutely don't do that.