Ok so here's what's going on :) I've been looking at ttmkfdir and its 3 open bugs (bug 209616, bug 235354 and bug 262945). So in theory, we could very well fix those bugs, but the license is a bit of an issue _and_ mkfontscale is supposed to be a complete replacement for ttmkfdir. Digging further, I see that now the only user of ttmkfdir is xfs's init script. (So, not even xfs...) Now to fix all this, there are a couple solutions : 1) clean up xfs's init script so that ttmkfdir can be dropped. I'm pretty sure that the x-modular and fonts eclasses do all that crap perfectly well in our font ebuilds' pkg_postinst and that most (if not all) the init's code can be ripped out. 2) remove xfs completely. I'll make it clear that I'm in favor of option #2 but with help I wouldn't mind #1 so much. Now that the situation is clear, I'd really like some input as to why people would still be using xfs these days? (Mike, you use it, don't you?) AFAICT, xfs uses libXfont to load its font and offer them to the server. But the server _also_ uses libXfont now for all its font needs. So both should be seeing the exact same fonts. A corollary question is: which apps/toolkits still use server-side fonts? Even "old" apps such as xterm now use libXft to render bitmap fonts which completely bypasses server-side fonts. So there, I really see no valid reason to use xfs anymore and I'd like to see it go. Thoughts, ideas, comments? Thanks
Bumb! Bug mail got lost in the interwebs.
I am in favor of #2. I cant imagine use of xfs nowdays.
i'm in favor of keeping xfs as i use it on my systems. run one font server and my networked systems pull from that. if upstream was killing off xfs and not maintaining it, that's one thing. but i dont think that's the case ?
(In reply to comment #3) > i'm in favor of keeping xfs as i use it on my systems. run one font server and > my networked systems pull from that. Your network boxes don't have any apps that use cairo/gtk, qt or even libXft? > if upstream was killing off xfs and not maintaining it, that's one thing. but > i dont think that's the case ? It is unmaintained. Although unmaintained in X land means it'll hang around for another decade but it is on its way out. In fact, it's not even part of the latest "katamari" release. Cheers
i run all the normal gui programs on the networked machine. their xorg.conf points to tcp/vapier:7100 for fonts.
(In reply to comment #2) > I am in favor of #2. > I cant imagine use of xfs nowdays. > I use xfs to serve fonts to vnc server run on headless machine. So that my xinetd.d/vnc has the line server_args = -inetd -query localhost -once securitytypes=none -fp tcp/localhost:7100 Machine often runs several concurrent instances of vnc servers (on different display) and it is very convinient to have a centralized font server. I do not have X server installed.
(In reply to comment #5) > i run all the normal gui programs on the networked machine. their xorg.conf > points to tcp/vapier:7100 for fonts. AFAICT, all your server side fonts are useless since gtk and Qt don't use them anymore. Could you try disabling xfs on your networked machines to confirm this? Thanks
(In reply to comment #6) > Machine often runs several concurrent instances of vnc servers (on different > display) and it is very convinient to have a centralized font server. I do not > have X server installed. Like Mike, if you use cairo or qt apps, then your font server is most likely useless. Please try turning it off. Thanks
Ok so I've continued digging into this. As far as Gtk/Gnome-y apps are concerned, pango is the library that handles text. It does indeed provide a rendering backend that uses server-side fonts (where xfs can be used) but it is clearly marked as deprecated and potentially broken. Gtk, for instance, doesn't use that backend at all. It uses the cairo backend which uses client-side fonts. Other apps, such as metacity, use the pango's libXft backend which also uses client-side fonts. Bottom line, gtk apps don't touch xfs, that's for sure. As a side-project, I've started auditing portage to see if any package really uses the old server-side rendering backend. Next stop, Qt 4 :) Cheers
And Qt 4 uses fontconfig and FreeType to draw fonts. So again, no server-side fonts. Server-side fonts are now a way of the past and xfs is just as useless. So unless either of you have compelling arguments (ie, names of apps and toolkits that you use and still can't use client-side fonts), xfs will go away. Thanks
it made my life easier with networked nodes, but if it isnt supported anymore, there isnt much the X team can do by itself
(In reply to comment #11) > it made my life easier with networked nodes What you need to understand is that xfs doesn't serve fonts. It serves pre-rendered font pixmaps to the server. But if your client apps are run on your app server, newer toolkits will use fonts available on the app server and render them like any other graphical element on the network node. So in the end, lightweight X nodes just shouldn't need _any_ fonts if all the apps use modern toolkits, because the network nodes' X server will never be _asked_ what fonts it has and can render. So please, try turning it off and see if anything breaks. I'm willing to help you out. Thanks
Right now I have the following X resource: xterm*font:-*-courier-*-r-*-*-*-180-*-*-*-*-*-* After turning of xfs I get the following when I am running xterm: Warning: Cannot convert string "nil2" to type FontStruct xterm: cannot load font -*-courier-*-r-*-*-*-180-*-*-*-*-*-* xterm: cannot load font -*-courier-*-r-*-*-*-180-*-*-*-*-*-*
(In reply to comment #13) > After turning of xfs I get the following when I am running xterm: > > Warning: Cannot convert string "nil2" to type FontStruct > xterm: cannot load font -*-courier-*-r-*-*-*-180-*-*-*-*-*-* > xterm: cannot load font -*-courier-*-r-*-*-*-180-*-*-*-*-*-* You need to set a correct FontPath in your xorg.conf. You do not need xfs for that. Thanks
The font path is correct: X is started with -fp tcp/192.168.1.1:7100 -query 192.168.1.1. Otherwise it would not have worked in the first place.
(In reply to comment #15) > The font path is correct: X is started with -fp tcp/192.168.1.1:7100 -query > 192.168.1.1. Otherwise it would not have worked in the first place. ... Well start X with -fp /usr/share/fonts/whatever instead. Or don't set -fp at all. How do you expect it to work _without_ xfs if you force xfs on? Thanks
We are talking about a remote setup! On the user's box (X server side): # find /usr/share/fonts/ /usr/share/fonts/ /usr/share/fonts/75dpi /usr/share/fonts/75dpi/fonts.dir /usr/share/fonts/75dpi/encodings.dir All the programs, fonts and so on are installed on the headless box (X client side).
(In reply to comment #17) > All the programs, fonts and so on are installed on the headless box (X client > side). I'm a little confused, could you further describe how your systems are configured and where/how apps are launched? Thanks
Sorry if I did not offer enough context. I thought it was the kind of setup that is under discussion here (e.g. comment #5). A user's box (x86) should be as minimal as can be. It is supposed to start an X server and offer remote login to the headless box (amd64). /var/lib/portage/world (annotated): app-editors/vim # I am more comfortable with it than with nano app-portage/gentoolkit # for revdep-rebuild app-text/rcs # for dispatch-conf media-gfx/sane-backends # saned: access local scanner from headless box sys-kernel/gentoo-sources # no comment sys-power/acpid # power off button x11-apps/setxkbmap # keymap for X server x11-base/xorg-server # X server (VIDEO_CARDS="nvidia intel") All fonts are installed on the headless box and served by xfs so that the user's X server can use them. I already tried some major programs (e.g. firefox and openoffice) and they do not access xfs (verified by iptables logging rule). But xterm fails. I wonder where it gets _any_ font from.
(In reply to comment #19) > Sorry if I did not offer enough context. I thought it was the kind of setup > that is under discussion here (e.g. comment #5). True, I just wanted to make sure we had the same things in mind :) > All fonts are installed on the headless box and served by xfs so that the > user's X server can use them. > > I already tried some major programs (e.g. firefox and openoffice) and they do > not access xfs (verified by iptables logging rule). That indeed confirms that "modern" apps just don't use server-side fonts. > But xterm fails. I wonder where it gets _any_ font from. As far as I can tell, xterm deps on libXft so it _should_ be able to use client-side fonts like firefox and OOo. But I guess that's a configuration issue. I'm a Gnome fella, so I can't really help. @Thomas, care to shed some light here on what xterm can and cannot do? Maybe we should change xterm's configuration to use client-side fonts by default? Thanks
From the command-line, one can use the -fa option to tell xterm to use a given font-family with Xft. That's the faceName resource setting, which of course a packager could use. (whether xfs is obsolete appears to depend on which niche of users I'm talking to, and is not worth spending time discussing).
(In reply to comment #21) > From the command-line, one can use the -fa option to tell xterm > to use a given font-family with Xft. That's the faceName resource > setting, which of course a packager could use. Thanks for the tips, I'll point users to this comment next time this pops up. > (whether xfs is obsolete appears to depend on which niche of users > I'm talking to, and is not worth spending time discussing). xfs was created to avoid completely blocking the server when an app requested server-side fonts. Now that the server no longer blocks, xfs is just useless. And since almost no app uses server-side fonts exclusively... Really, I'm all ears but no-one has convinced me that xfs had a legitimate use with _today's_ applications. Cheers
Setting faceName works! Thanks. My resources now are: xterm*faceName:Bitstream Vera Sans Mono xterm*faceSize:12 xterm*faceSize1:6 xterm*faceSize2:8 xterm*faceSize3:10 xterm*faceSize4:12 xterm*faceSize5:14 xterm*faceSize6:16 But there are some font resources defined by packages (xterm among them): # grep -li font /usr/share/X11/app-defaults/* /usr/share/X11/app-defaults/KOI8RXTerm /usr/share/X11/app-defaults/Mwm /usr/share/X11/app-defaults/UXTerm /usr/share/X11/app-defaults/XFontSel /usr/share/X11/app-defaults/XLock /usr/share/X11/app-defaults/XmLock /usr/share/X11/app-defaults/XScreenSaver /usr/share/X11/app-defaults/XSm /usr/share/X11/app-defaults/XTerm Should this not be changed in a similar way? Upstream bug?
A patch would be useful for the *XTerm stuff if there were a TrueType font that provides the glyphs. No one's mentioned one. Offhand, I don't recall that the other applications work with Xft. That's a separate issue.
(In reply to comment #24) > A patch would be useful for the *XTerm stuff if there > were a TrueType font that provides the glyphs. > No one's mentioned one. It doesn't have to be a TrueType font or any other vector font. As long as the rendering is done client-side, that's fine. > Offhand, I don't recall that the other applications work > with Xft. That's a separate issue. Indeed, I'll try to look into them. Thanks
And all 3 packages are now masked. If an application or a toolkit still relies on server-side fonts, it should be either fixed or just treecleaned. The RENDER extension has been available for the better part of this century and so have libXft, cairo and many other libraries. Thanks
I know I'm late but I must express strong opposition to removing X font server from portage: There are tons of application which use old plain server site fonts (xterm, xmag, gv, xscreensaver etc.). There are users using no big and fat desktop environment (like GNOME or KDE), they choose their application according other criteria than widget toolkit (and font handling). There are users feeling raster fonts looks better in small sizes on current poor-resolution screens than rasterized vector fonts (e.g. having 4 80x25 xterms on 88 DPI 1024x768 screen is very handy with *-fixed-*-iso10646-1 than any vector font, at least for my eyes). There are people running thin X clients or other network-spreaded systems where XFS is very easy way how to distribute fonts without configuring font paths in each X server separately. If you ask for a test, I did it accidentally---After some upgrade (we have heterogenous network with Debians and Gentoos) X server failed to connect to XFS via IPv6. That resulted in really crapped X thin clients where some application did not started or used bad fonts. I understand that superior pango with font substitution and advanced type setting is future of text drawing, but there are reasons why we still need to support old server site fonts.
(In reply to comment #27) > I know I'm late but I must express strong opposition to removing X font server > from portage: > > There are tons of application which use old plain server site fonts (xterm, > xmag, gv, xscreensaver etc.). > > There are users using no big and fat desktop environment (like GNOME or KDE), > they choose their application according other criteria than widget toolkit (and > font handling). > > There are users feeling raster fonts looks better in small sizes on current > poor-resolution screens than rasterized vector fonts (e.g. having 4 80x25 > xterms on 88 DPI 1024x768 screen is very handy with *-fixed-*-iso10646-1 than > any vector font, at least for my eyes). No one is planning to remove old server-side font rendering. It's part of the core X11 protocol, it'll always be supported (as best as we can of course). > There are people running thin X clients or other network-spreaded systems where > XFS is very easy way how to distribute fonts without configuring font paths in > each X server separately. Xfs doesn't stream font files, it streams pre-rendered font "textures". Xfs was designed at a time when the server completely froze for several seconds when doing this rendering. Doing this CPU-intensive phase in a separate process only froze the application that requested the font. The server is now able do this without blocking, so the original need for xfs is completely gone. As for setting up font paths, we're working on improving the situation by using Xorg's "catalogue" feature (see bug #185264). With this in place, you'll just have to emerge fonts to see it in Xorg directly without mucking with xorg.conf. It should help deploying thin-clients. But again, using apps that use client-side font rendering completely removes the need for any fonts on the thin clients... > If you ask for a test, I did it accidentally---After some upgrade (we have > heterogenous network with Debians and Gentoos) X server failed to connect to > XFS via IPv6. That resulted in really crapped X thin clients where some > application did not started or used bad fonts. > > I understand that superior pango with font substitution and advanced type > setting is future of text drawing, but there are reasons why we still need to > support old server site fonts. And again, no-one's removing old fonts support. Just xfs. Thanks
Soo, half year later, whats the progress?
