myDSL Extensions (deprecated) :: Has anyone built an msttcorefonts.dsl?



Quote (sci_fi @ Aug. 03 2005,17:07)
Perhaps the above font path element error is the culprit. What to do? I will change over to a different XF86Config-4 file as an experiment and let you know.

The font path error you're seeing just indicates that that particular font path in your XF86Config-4 isn't valid. In this case it's specifying a socket connection to a local font server process that your are not actually running. All the other specified font paths should remain valid.

For what it's worth, I'm not seeing the TT fonts in Firefox GTK+2 either. This worked in an older attempt at my corefonts package that dumped everything into the regular Debian locations (/usr and /etc) so I'm guessing GTK+2 is looking in those spots to build its font lists. If you can wait until next week, I can probably get this problem sorted out this weekend. Stay tuned.

Hello Kopsis:

Thanks for the update and your efforts on this. No problem waiting until the weekend. You know how it is. One sort of gets obsessed with making things right.

Must be something to do with FF gtk2, since OpenOffice finds the fonts just fine.

BTW. I found a typo in the generic VESA XF86Config-4 file. In the mouse(2) section the word "protocol" is spelled "protocal". Changing that fixed my boot up mouse(2) warnings.

Still fiddling with the keyboard errors.

Thanks again. I'll post if I get anywhere wrt keyboard problems.

sci_fi

Quote (sci_fi @ Aug. 04 2005,07:15)
You know how it is. One sort of gets obsessed with making things right.

Amen to that! A feeling I know all too well :)

For what it's worth the problem is definitely GTK2 specific and it is because the GTK2 extension is relying on defoma (DEbianFOntMAnager) for font information. The msttcorefonts extension isn't using defoma because that would require that I include defoma (which means draging a recent version of Perl along with it) and that it do the whole mkwriteable thing -- something I didn't want to force on folks with low memory systems.

Since GTK2 already includes defoma and forces a mkwriteable, what I'll do is add a script that GTK2 users can run to do the additional setup (once I figure out what that is). I also need to experiment with TrueType font server daemons (like xfstt). I think it may be possible to use these fonts with DSL's standard Kdrive X server if you have a font server daemon running to process them. Might be a good solution for those who don't want to go the full XFree86 route.

Ok, I had a few free minutes so I did a little digging :)

There's a chance that making the MS TrueType fonts available to GTK2 apps may be as simple as doing:
Code Sample

sudo ln -s /opt/msttcorefonts/TrueType /usr/share/fonts/msttcorefonts

and then doing the "Update to GTK2" thing. I can't test this tonight, but if anyone wants to take a shot and post their results, I'd welcome it. Even if that doesn't do it, the fix is going to be something along those lines so I'll mod the scripts to build a .dsl instead of a .tar.gz and include the necessary links into /usr. Yeah, that means mkwriteable, but it looks like TrueType fonts only work with XFree86.dsl so that's a non-issue.

I tried getting KDrive (aka Xvesa, aka Xfbdev) to pull fonts from an xfstt font server daemon, but no joy. Looks like the tiny DSL X server wasn't built with font server support  :angry:

So what to do about folks who can't or don't want to run XFree86? Here's my thoughts:

I can modify my font extraction scripts to actually generate two extensions -- one that has the real TrueType fonts and another that has them converted to bitmap (.pcf.gz) fonts at relatively common point sizes (6, 8, 10, 11, 12, 14, 16, 20, 24, 32, 48?). I've tested that with a couple that I converted manually and it actually works! The fonts aren't scalable so if you need a point size that isn't available it looks ugly ... but for supported point sizes the fonts look just like their TrueType counterparts. Not a perfect solution, but it at least give users a chance of viewing web pages and documents the way the authors created them :)

The resulting extension will take somewhere between 6 and 10 MB but will be a .tar.gz extension so if you have an HD (or flash) for /opt it won't take any RAM.

Anyone have any thoughts on that? Would it be a worthwhile exercise or will all the folks that need fonts be happy to run XFree86? I'll probably build this regardless just because I have some use for it, but feedback before I do is certainly welcome.

Any chance of adding this path to the XF86Config-4 file,
under the list of font paths?

/opt/msttcorefonts/TrueType

??

Kent

Next Page...
original here.