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): How reproducible: Always 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.
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. Thanks
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.
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 correctly.
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 at. 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 ttmkdir sources * Solution: autogenerate Foundry name by the family name like following algorithm; 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 fonts.alias. 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 Japanese: kochi-gothic.ttf: Take Kochi Gothic Kochi-Gothic kochi-mincho.ttf: Take Kochi Mincho Kochi-Mincho Korean: 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.
Yes, we absolutely don't do that. See http://www.microsoft.com/typography/otspec/os2.htm#vendid