From xemacs-m  Mon Apr 21 14:21:30 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id OAA27043
	for <xemacs-beta@xemacs.org>; Mon, 21 Apr 1997 14:21:28 -0500 (CDT)
Received: by crystal.WonderWorks.COM 
	id QQcmgr20771; Mon, 21 Apr 1997 15:21:28 -0400 (EDT)
Date: Mon, 21 Apr 1997 15:21:28 -0400 (EDT)
Message-Id: <QQcmgr20771.199704211921@crystal.WonderWorks.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Kyle Jones <kyle_jones@wonderworks.com>
To: xemacs-beta@xemacs.org
Subject: Re: Impossible to use 'terminal' font in XEmacs/mule
In-Reply-To: <86hgh0kzg3.fsf@kramer.in.aventail.com>
References: <86pvvov2q4.fsf@kramer.in.aventail.com>
	<9704211513.AA24209@fornet.gvc.dec.com>
	<86ohb8v0o7.fsf@kramer.in.aventail.com>
	<QQcmge18104.199704211606@crystal.WonderWorks.COM>
	<86d8ro8iar.fsf@kramer.in.aventail.com>
	<9704211639.AA24314@fornet.gvc.dec.com>
	<QQcmgl19447.199704211745@crystal.WonderWorks.COM>
	<86iv1gl0p8.fsf@kramer.in.aventail.com>
	<QQcmgm19814.199704211811@crystal.WonderWorks.COM>
	<86hgh0kzg3.fsf@kramer.in.aventail.com>
X-Mailer: VM 6.28 under 20.2 XEmacs Lucid (beta1)
X-Face: /cA45WHG7jWq>(O3&Z57Y<"WsX5ddc,4c#w0F*zrV#=M
        0@~@,s;b,aMtR5Sqs"+nU.z^CSFQ9t`z2>W,S,]:[+2^
        Nbf6v4g>!&,7R4Ot4Wg{&tm=WX7P["9%a)_da48-^tGy
        ,qz]Z,Zz\{E.,]'EO+F)@$KtF&V

William M. Perry writes:
 >  I think that if I explicitly set a font for a face, it should be honored
 > for an ascii environment.  _Especially_ if I specify the ENCODING.  End of
 > story.
 > 
 > This is sure as hell wrong:
 > 
 > (set-face-font 'default
 > 	       "-bitstream-terminal-medium-*-*-*-*-*-*-*-*-*-dec-dectech"
 > 	       (current-buffer))
 > "-bitstream-terminal-medium-*-*-*-*-*-*-*-*-*-dec-dectech"
 > (face-font-name 'default (selected-window))
 > "-bitstream-terminal-medium-*-*-*-*-*-*-*-*-*-dec-dectech"
 > 
 > And the actual font being used is the global default font.

You're fighting against the design of the system.  Under MULE
font specifiers seem to work more like image specifiers.  A font
instance has to make sense under a particular charset for it to
be permitted, just as image instance have to make sense on device
types and tag sets.  If it doesn't make sense, then the spec for
a less local domain is tried.

It would be good if this fit better into the specifier system.  I
think the charset would have to be in the device tag-set of the
specifier, but I'd have to think about it more to be sure.

But the point is that under the system as it is currently designed
what you want is a new charset, or perhaps to make the 'ascii
character accept more registries.  I would prefer that you create
a new charset, cuz I doubt that I ever want to see those T-bars in
a non-Web-page context.  I don't know of any apps that create new
charsets, so as an Added Bonus you get to try it and tell us if it
works. :-)

