Meet the Gang 1 2 3 4 5 6 7 8 9 10 11 12 |
From leo
Answered By Heather Stern, Ben Okopnik, Jay R. Ashworth, Thorsten Mürell, Jim Dennis, Matthias
[Leo] Hey Gang - First off... absolutely stellar job. Linux is a little bit more fun as a result of all of you.
[Heather] Awww, shux
[Leo] Anyhow, I can't seem to get all my TrueType fonts to get recognized by ttmkfdir.
I've followed the True Type HOWTO exactly, and have been told to look at the resulting fonts.dir and fonts.scale, and alas, only half the TrueType fonts in that directory show up.
[Heather] Most curious; if they are legal TTF's, they should respond to the "file" command as something like:
swiss911.ttf: MS-Windows true type font .ttf
[Heather] notes about scale files moved down for readability
[Leo] I downloaded some TrueType fonts off the web (https://www.fontalicious.com)... is it possible that these fonts don't adhere to some kind of standard that's out there, and that's why ttmkfdir isn't working for them? If not, any ideas as to what I can do to get this working?
Thanks for the quick response Heather... So here's where I am now:
After I went and got the file utility from rpmfind.net, I ran it and got this:
[silver] ~/fonts/>file sushi.ttf
sushi.ttf: raw G3 data, byte-padded
The thing is, though, when I run file on say arial.ttf, I get this:
[silver] ~/fonts/file arial.ttf
arial.ttf: raw G3 data, byte-padded
[Heather] Whereupon Ben and I both chased down a rathole for a while thinking that perhaps he actually had downloaded a PICTURE of the font, instead of the font itself. Never mind that usually such pictures would have been GIFs, not "G3" TIFFs or other fax documents... the Gang came to the rescue, though...
[Heather] Also, that 'display' shows the file doesn't prove it's a normal image type - display speaks Freetype!
This isn't obvious because it doesn't insist on it; there's a call to make if you want to ask if a library is around to use, after you load. The better gtk and Gnome apps sometimes use it, so that they can use plain xlibs if the glitzier things aren't around.
(on my box it says it can't find Freetype, right before it fails to display the font, on fonts which otherwise work just fine. GIMP sees 'em all because of xfstt. Maybe my own "X 4 won't honor truetype" problem is that it doesn't find the lib, and my xfstt does, or is static. Hmm.)
[Thorsten] I think your guess could be wrong. My file command also says, that my *.ttf are "raw G3 data, byte-padded" (I've also got this /etc/magic from 1995), but I'm using them in all my apps and ttmkfdir has recognized them, too.
[Ben] OK, so to cut through all the bull... A couple of minutes ago, I downloaded the font that Leo mentioned. Looks pretty standard to "file" (BTW, "display" can't see it).
I unzipped it with the "-L" switch (I like my filenames in lower case, thank you), and moved it into "/usr/share/fonts/truetype/". Then, I shut down the "xfstt" TrueType server, ran "xfstt --gslist --sync", started "xfstt" back up, and ran "xset fp+ unix/:7101" to let X know that it had a TT server running.
<shrug> Nice font.
[Jay] Naw...
I'll bet 10 bucks he has an out of date /etc/magic file.
Hey, Ben. Mail me one of those font files, and let me file(1) it here...
[Heather] Aww, just go fetch one of the enlightenment themes over at e.themes.org. It's pan-distro and they all have at least one ttf in them.
I really like the "ganymede" font.
[Jay] ... with a /usr/share/magic dated 1/21/1995 (!) says that they're...
G3 files.
I know these are fonts, based on where they are (a directory called lib/fonts), and what they're called ("Lucida Typewriter" and the like).
So file(1) is wrong, among other things.
[Ben] Whoops. My "/etc/magic", dated 12/10/2000, with "file" v3.37, gets it right. Once I updated. Hey, this Debian "testing" distro stuff isn't too bad at all...
... Which merely left the font server files to sort out ...
I don't think I mentioned it before, but I'm running Drake 8 and xfs.
[Heather] Nope, you hadn't. For comparison (tho I think I said) I'm answering from a SuSE box serving fonts via xfstt... as I haven't been using Redhat itself for a while.
XFS without patches doesn't normally speak truetype, but I suppose you're using the X 4.x.x edition?
but arial.ttf shows up in fonts.dir as
arial.ttf -monotype-Arial-medium-r-normal--0-0-0-0-p-0-iso8859-15 arial.ttf -monotype-Arial-medium-r-normal--0-0-0-0-p-0-iso8859-1
while sushi.ttf doesn't appear... any ideas from here?
[Heather] Yes, these may be explicitly listed in fonts.scale, which is read for the data ... used for fonts which do not contain the correct font header info.
The real thing is managed by a triplet of files, which if kept all in sync, all is happy. Those three files are fonts.dir, fonts.scale, fonts.alias. fonts.dir and fonts.scale look exactly the same... the first line is a count of how many fonts, and the rest are X-style control lines, where the first word is the filename (foo.ttf) and the rest is a set of dash-separated parameters. The fonts.alias file looks the same except, there is no count line, and the ".ttf" gets stripped off. You can also add aliases for other popular spellings of things ("Comic Sans" and "MS Comic Sans" as seperate lines for the same font mscomicsans which is really comc.ttf), but I'm generally too lazy.
Here's an example for a Star Trek font. Note that Bitstream did most of the fonts for the series, but I created a special "foundry" to keep my trek stuff.
fonts.scale and fonts.dir contain:
crillee.ttf -startrek-crillee.bt-medium-r-normal--0-0-0-0-p-0-iso8859-1
but fonts.alias contains:
crillee -startrek-crillee.bt-medium-r-normal--0-0-0-0-p-0-iso8859-1
Notice that the tail item is exactly the same for both. ttfmkdir just reads the fonts and creates these entries.
[Heather] But, having these files in good health doesn't seem to guarantee success. On my own SuSE 7.2 system, I find that the builtin Truetype handler in its X 4 implementation doesn't act right:
Could not init font path element /usr/X11R6/lib/X11/fonts/truetype, removing from list!
... so I use xfstt instead, which has worked for me for a long time, and has no complaint about being pointed to the same directory. Sigh.
[Matthias] You may need to add
dir "/usr/X11R6/lib/X11/fonts/truetype"
to your /etc/X11/XftCache and run (as root) /usr/X11R6/bin/xftcache to=20 generate the X Freetype Cache.
and run (as root)
/usr/X11R6/bin/xftcache
to generate the X Freetype Cache.
[Heather] Hmm. No such file on SuSE 7.2. What distro are you speaking from?
'locate' on the fragment 'xft' finds an x based FTP client, and 'xftree' which is a file manager for the "Cool" environment aka XFCE. IOW, no dice and/or that tool didn't come with the Xfree 4.x.x base, and I dunno which RPM it'd be in.
[Ben] Hummm. I've got an "/etc/X11/XftConfig" on my Debian rig; it comes from, lessee now -
ben@Baldur:/etc/X11$ dpkg -S XftConfig xlibs: /etc/X11/XftConfig ben@Baldur:/etc/X11$ dpkg -s xlibs Package: xlibs Status: install ok installed Priority: optional Section: libs Installed-Size: 4956 Maintainer: Branden Robinson <branden@debian.org> Source: xfree86 Version: 4.1.0-9 <more output elided>
Looks like pretty standard X-4.1.0 to me; I don't even know that it's distro-related - "xlibs" should be fairly standard, right? On the other hand, "xftcache" is part of "xbase-clients"; if you don't have that installed (and Debian gets pretty cross with you if you don't, IIRC) you might not have it to be "locate"d.
[Heather] SuSE 7.2 seems to have come with X 4.0.2. Sigh.
[Matthias] Then freetype enabled applications should see the fonts.
[Heather] Magicpoint sees 'em fine...
[Matthias] If you're using KDE you may want to try "kfontinst", which can install TTF and Type1 fonts easily. It also generates the files fonts.dir and fonts.scale (whileas fonts.alias isn't needed by X to work).
[Heather] I use some Gnome and K apps, but avoid the full environments.
My dad-in-lawi uses K though. Does it make Ghostscript play nice too? That's where he's been having font fun lately, the world of K and X don't seem to agree with the printer.
[Heather] Chances are excellent that kfontinst exists on Mandrake, so maybe Leo can check if it does The Right Thing for him.
[Matthias] It also generates the files fonts.dir and fonts.scale (whileas fonts.alias isn't needed by X to work).
[Heather] Strictly speaking, I don't think the font service doesn't need fonts.scale either ... it's used by mkfontdir (or its cousins) along with the real fonts, to compose fonts.dir.
All my fonts.* files are in fine shape; xfstt uses fonts.dir the same way that standard xfs does, it just being the same server with a patch for freetype support.
[Leo] Anyhow, Heather mentioned that:
Yes, these may be explicitly listed in fonts.scale, which is read for the data ... used for fonts which do not contain the correct font header info.
If I were to do this, what would an entry look like?
[Ben] Here's my "/usr/X11R6/lib/X11/fonts/Speedo/fonts.scale":
See attached speedo.fonts.scale.txt
The top number in these is a count of the following font lines; I've glanced at a couple of these, and that's what it adds up to. <shrug> I guess that whoever wrote the software didn't feel like counting them. It looks like a mapping of all the actual font names (the front part of the string) into the type of font spec that X expects.
... and somewhere along the full discussion, Ben cranked out this ...
[Ben]
Baldur:~# perl -walne'/\.ttf\b/&&$x{$F[1]}++;END{print int keys %x}' Contents-i386
[Faber] Okay, I'm not too proud to ask...
What the hell does that do?
[Ben] Heh. It's a glorified frequency counter (I throw away the actual count of "items", so it just does a "uniq"):
-w enable warnings
-a autosplit on whitespace, load result into the "@F" array
-l line-end processing (in this case, print "\n"s after each line)
-n run code in a non-printing loop
-e execute the following code as script
/\.ttf\b/&&
If a line matches '.ttf' which is immediately followed by a word boundary, then...
$x{$F[1]}++
...using the second member of the "@F" array ($F[1]) as a key in the %x hash, increment the value assigned to that key. This will build a hash with every unique name as a key, and the values reflecting how many times that key appeared.
END{print int keys %x}
The END block, just like in "awk", runs only once, after the main loop has finished. So, once "%h" is loaded up, we extract the list of keys from it. "print keys %x" would have printed the list itself; "print int keys %x" enforces scalar context on the list, and just prints the number of items in it. Typical example of Perl context sensitivity.
[Jay] IOW: magic.
[Leo] Ok here's the thing now: I added the dir entry (as suggested earlier by someone else) in /etc/X11/XftCache and now there's a XftCache file appearing in my fonts folder. Some of the fonts that don't appear in fonts.dir appear in my new XftCache. Example entry:
"sushi.ttf" 0 "Sushi High:style=Regular:slant=0:weight=100:encoding=iso10646-1,iso8859-1,apple-roman,iso10646-1,iso8859-1,glyphs-fontspecific:core=False:index=0:outline=True:scalable=True"
Reissuing 'ttmkfdir -o fonts.scale' yields the same results (ie: sushi.ttf doesn't appear in fonts.scale)...
So now I'm really lost... the light at the end of the proverbial tunnel keeps getting darker and darker...
[Thorsten] No, no. That's wrong. In the world of Tux and his friends there aren't so much tunnels and all are leading to something useful.
What does your ttmkfdir say, if you type "ttmkfdir --version", perhaps it is out of date or too good for your fonts?
[Leo] ttmkfdir --version yields no version information. Just says it's an invalid option... the copyright information is from 1998. Should I go get the newest ttmkfdir out there?
[Heather] Note that just having the right fonts.* files in my truetype directory aren't enough to make it happy, either. If it helps, the home page for xfstt is... uh... if you believe Freshmeat, it doesn't have one. But you can download iti from ibiblio. The same place also mentions xfsft, which uses Freetype directly, and is much better known. Of course I went to its homepage and learn that he no longer maintains it seperately now that it is happily merged into Xfree86 proper. So that answers my question anyway.
And it means that your own answer might be the same as mine, either one of:
- use xfstt or another "external" font server to translate your TTF fonts to a standard X protocol font
- find and/or properly install Freetype libraries on your system, making sure that ld.so.conf agrees with you on this subject. Don't forget to use ldconfig to make it update the libraries locations. Also don't forget it searches through the locations in the order listed, so if you've a bogus library in there (an old rev maybe?) you really do need to take it out.
[JimD] No, worse! It uses data inside the library files to determine what names they will honor. Definitely rip out bogus libraries.
[Heather] If anybody knows a way to ask a program which libraries it is potential-linking as well as dynamic-linking to, I'll be glad to split that datum off into a 2 cent tip.
[Leo] Ok I ended up getting xfstt (grabbed it from rpmfind.net) and using that as my external ttf server. Now (thankfully) everything seems to be working. I followed Ben's directions as to setting it up, and since I got the rpm it already put the script inside /etc/rc.d/init.d/ for me.
Sorry for any pain this thread has caused... but thanks so much for the help... I'd bake you all a cake, but that'll end up doing a lot more harm than good...
[Ben] No pain, at least none here. <chuckle> Since we're scattered all over the place, you'd just have to eat it yourself. Just think of all those calories! You're right; better skip it.
[Heather] Yeah, we probably all like dif't flavors too. But I'll eat a local slice in your name if you like.
[Leo] thanks again - leo
[Ben] Glad we could help, Leo.
[Heather] Yeah, enjoy your newfound font-dom.
Meet the Gang 1 2 3 4 5 6 7 8 9 10 11 12 |