From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bio.cse.psu.edu ([130.203.12.17]) by hawkwind.utcs.utoronto.ca with SMTP id <25101>; Tue, 15 Jun 1999 17:58:37 -0400 Received: (qmail 7755 invoked by uid 991); 15 Jun 1999 00:10:04 -0000 Message-ID: <19990615001004.7754.qmail@g.bio.cse.psu.edu> Date: Mon, 14 Jun 1999 20:10:04 -0400 To: "Mark H. Wilkinson" cc: Sam Fans , Bengt Kleberg Subject: Re: 9libs, new sam release, experimental wily release In-reply-to: Your message of "Mon, 14 Jun 1999 20:46:50 BST." <199906142046.20514.9libs.badum@kremvax.demon.co.uk> Date: Mon, 14 Jun 1999 20:10:04 -0400 From: Scott Schwartz "Mark H. Wilkinson" writes: | > * In libXg, "fontfile" is specified by the X client app. In general | > that cannot work: unlike in Plan 9, the X terminal usually won't | > share any filesystem with the machine on which the X app is | > running, so *no* filename can be valid for "-p9font". The fix is | > to store the unicode font map in an X property which is set by your | > xinitrc. | | By this, do you mean the case where you're logging into remote machines | and running sam & samterm on the remote machine? Yes. | ... but I guess you're after a | solution which is easier to manage, using the X server as shared storage. Yup. | That sounds reasonable, but I'd like to retain the existing mechanism | too: it works well in networks where the file system is common to all | machines to some degree. Of course. The patch does that. It checks to see if the fontfile starts with '.' or '/', and if so, reads that file. Otherwise it treats it as the literal contents of the font file. In either case, as before, it falls back to using a literal X font name if the previous steps don't resolve to a font file. | That would be great! I'll have them ready soon. I got diverted hacking on 9term today.