Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!tut.cis.ohio-state.edu!bloom-beacon!SUN.COM!dshr
From: dshr@SUN.COM (David Rosenthal)
Newsgroups: comp.windows.x
Subject: Re: special server mechanism (deemed unnecessary)
Message-ID: <8812112322.AA07917@devnull.sun.com>
Date: 11 Dec 88 20:12:53 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 30

> Part of the toolkit philosophy is that for any resource type there is some
> value that is guaranteed to work.

What exactly does "guaranteed to work" mean in this context?  Will produce
intelligible results?  In that case,  something needs to be said about
the encoding.

> Currently to support this with fonts,
> it resorts to the totally unreliable expedient of using "fixed" as the
> default font.
> 
Since the toolkit app almost certainly assumes that "guaranteed to work"
means "has ISO Latin 1 encoding",  a simple change from the string "fixed"
to whatever the string is that selects an ISO8859-1 encoding but no
other font properties will do the trick.  Note that this is not
"guaranteed to work",  but in the cases where it will fail the toolkit
application will fail too,  because its assumption about usable
encodings is false.

> This could be provided by either expanding the protocol to allow a
> GContext anyplace it allows a Font (as it does in XQueryFont), or having
> some special resource ID to refer to the default font, as someone else
> suggested.
> 
I've got news for you.  It'll be quite a while before there's a protocol
rev.  You have to learn to live with things the way they are.  Fortunately,
in this case its really easy.  Nevertheless,  the first of your ideas is
pretty good.... 

	David.