Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!kimba!hvr
From: hvr@kimba.Sun.COM (Heather Rose)
Newsgroups: comp.windows.x
Subject: Re: XView application without olcursor?
Message-ID: <132803@sun.Eng.Sun.COM>
Date: 11 Mar 90 00:32:18 GMT
References: <5452@crdgw1.crd.ge.com> <132555@sun.Eng.Sun.COM> <5818@crdgw1.crd.ge.com> <132607@sun.Eng.Sun.COM> <5863@crdgw1.crd.ge.com>
Sender: news@sun.Eng.Sun.COM
Reply-To: hvr@sun.UUCP (Heather Rose)
Organization: Sun Microsystems, Mountain View
Lines: 89

In article <5863@crdgw1.crd.ge.com> barnett@grymoire.crd.ge.com (Bruce Barnett) writes:
>In article <132607@sun.Eng.Sun.COM> hvr@sun.UUCP (Heather Rose) writes:
>|All the X11 servers do not use the standard utility bdftosnf to
>|compile the font files?  The XView source includes rules for compiling
>|the fonts for X11R3 based servers.  
>
>
>In one case we had a X terminal from company "Q"
>This required us to have a machine from that company to compile
>the fonts into the right mode. The system that is providing boot
>service for our X terminals is an Encore. It's version of native font
>formats were not the same as the format neded by that particular terminal.
>
>Also - as I said - I had to FTP the fonts to a Mac and convert them
>myself - using a Mac utility. (Finder - not A/UX).

I do not know enough about X11 fonts to be able to say for sure what is
going on; however, I will guess from the described behavior that when an
X11 font is compiled, it is compiled into a form that is not readily 
understood by an arbitrary X11 server.  I suppose the problem could be solved by
specifying one format for the loadable fonts---something like specifying
the format of pixmaps so every X11 server may read an X11 pixmap.

I would also guess that this problem could be solved by the font server which
would read one format such as .bdf files or something else which would
allow scalable fonts such as the F3 format in Open Fonts.  I would also guess
that since a font server would need to send font glyphs to several different
X11 servers, it would have to specify some standard format such as a pixmap
that each server would be guaranteed to understand.  If it did not, I don't
see any point in doing it in the first place.

>Our world is not heterogenous.
>|>The point is - OpenLook fonts are currently non-standard.
>|>The mechanism needed to download the fonts are non-standard.
>|
>|How so?  We provide them in the same format as any other X11 supplied font.
>|We provide the same rules for compiling them as any other X11 font.  We also
>|add the font to the font database in the same way as any other X11 font.
>
>|OK.  Perhaps what you mean by "non-standard" is that X11 servers that came
>|out before X11R4 do not download the OpenLook fonts by default?  That you
>|need to run bdftosnf or xset at all...
>
>Yes.
>
>Another question I have - is HP/Apollo, IBM, Apple and DEC going to 
>provide OpenLook fonts standard with each of their X servers?

Ask HP/Apollo, IBM, Apple and DEC.  I won't even try to guess what other
companies might be releasing in future products.

>I can believe that a lot of these users might try an XView
>application - and get a fatal error because the olcursor font wasn't
>there. 

Given the useful information some other people have given us concerning
pixmaps, it is reasonable to consider as an alternate implementation of the
OPEN LOOK glyphs.  When we looked at this issue originally, we found fonts
to be more flexible and better performing than pixmaps, so we chose to use
this method instead.  Given the portability issues with X11 fonts, this is
an issue in an heterogeneous environment.

However, supporting both pixmaps and fonts will double the text space for
rendering since you need to deal with either the case of a pixmap or a font 
for each case.  Granted this is averaged over a number of clients (when 
using shared libraries which is not the common case), but any increase in
library size is still an increase in library size.  We've been trying to
make it smaller...a penny saved is a penny earned.

Realistically, by the time we could release a version of the XView library
that implemented this change, the font server issue would be solved, and 
all this work would have been for naught (in my guestamation).

However, if this is very important to you, we do supply the source to the
olgx support library.  The XView library will be using olgx in the next
major release to render all it's OPEN LOOK glyphs.  So, if you would like
to make changes to this library to use pixmaps instead of fonts, you are
free to do so.  And since Sun supplies binaries compiled with shared libraries,
you could replace our version of olgx with yours (as long as you do not
break any of the interfaces) and everything would run just as it's supposed
to.  One of the distinct advantages of shared libraries...

If you do modify olgx, please send us the suggested fix.  It is our policy to
try to integrate any changes to the XView source someone may make.

__________________________________________________________________
Heather Rose
Window Systems Group                      internet:  hrose@sun.com
Sun Microsystems, Inc.                        uucp:  ...!sun!hrose