Conference bulova::decw_jan-89_to_nov-90

    
    Doesn't the font need to be LOADed to return a Font ID?  I think that
    the documentation is just not specific enough.  It makes sense that the
    LOAD returns an ID, since the load can also be used by the server to
    maintain a reference count on the number of connections using the
    font... the LIST doesn't.  It would seem to me that a font ID doesn't
    need to exist for a given font unless it's referenced by a LOAD.
    
    Just a guess.
    
    

Thanks for the reply!

>It would seem to me that a font ID doesn't need to exist for a given
>font unless it's referenced by a LOAD. 
    
>Just a guess.

That's a reasonable guess, but if you just do an XQueryFont it returns 
the fid, too.  Since our doc and Scheifler says it should be 
identical, I'm going to qar it.

Bruce

    
    Come on, XQueryFont takes the "font_ID" as an input parameter - thus
    it can ONLY be used on a LOADed font.  That is, you MUST have done
    a XLoadFont or XLoadQueryFont to be able to get the FID to use as
    input to the Query.
    
    So the fact that XQueryFont returns a FID does not imply that fonts
    that haven't been LOADed have a FID...
    
    

>Come on, XQueryFont takes the "font_ID" as an input parameter - thus
>it can ONLY be used on a LOADed font.  That is, you MUST have done a
>XLoadFont or XLoadQueryFont to be able to get the FID to use as input
>to the Query. 

Except when it takes a gccontext of the default gc.  I don't know who 
loads it, but since I don't, I was just trying to use the fontid from 
ListFontsWithInfo to compare with QueryFont on the default to figure 
out the name reliably.  Anyway, Scheifler says ListFontsWithInfo 
returns "identical to what XLoadQueryFont would return except that the 
per-character metrics are not returned."  Even if you have loaded a 
font ListFontsWithInfo returns a null FID.

If they really want to enforce "no FID without a known load by the 
querying process" then it should be more explicit.  I agree that using 
a FID not returned from a load would not be a good idea, but it 
appears to be the only unique identifier other than the full name.  As 
an identifier it can be used to differentiate as well as signify the 
font to a GC, so I don't think it should be quite so hidden.

Bruce

Notice that if you pass in the GC, you get the GCid back, not the fontid.  This
is in the Digital Press book.  There is no way you can get the server to give you
a font id.  If you don't have it already, you don't get it.

Burns

>Notice that if you pass in the GC, you get the GCid back, not the fontid.

If you pass the gc context of the gc it returns the full XFontStruct, 
including the font id which you don't know because you didn't create 
the default gc.  You can even get the name from a property!

#include <stdio.h>
#include <X11/Xlib.h>
#include <X11/Xatom.h>

main()
{
    Display    *dpy;
    Screen     *screen;
    GC          gc;
    GContext    gcc;
    XFontStruct *gcfont;
    int		prop;

    if ((dpy = XOpenDisplay(NULL)) == NULL) {
	printf("can't open %s\n", XDisplayName(NULL));
	exit(1);
    }
    screen = XScreenOfDisplay(dpy,0);

/* get gc context from gc */
    gcc = XGContextFromGC(DefaultGCOfScreen(screen));

/* do query font against the gc context to get the XFontStruct */
    if ((gcfont = XQueryFont(dpy,gcc))== NULL) {
	printf("cannot return gcfont\n");
	exit(1);
    }

/* get the XA_FONT property */
    if(XGetFontProperty(gcfont,XA_FONT,&prop)==FALSE){
	printf("couldn't get gcfont property\n");
	exit(1);
    }

/* translate the atom */
    printf("font name=%s\n",XGetAtomName(dpy,prop));
}

Sorry...you actually have to pass the GCID, not the GC.  However, the
structure you get back will contain the GCID, not the fontid.  The font does
not *have* an ID unless you opened it.

Burns

>Sorry...you actually have to pass the GCID, not the GC.  However, the
>structure you get back will contain the GCID, not the fontid.  The font does
>not *have* an ID unless you opened it.

The sample program in .6 passes the GC context (I don't know if that 
is the same as GCID) and returns the fontid, or at least the same 
number you get if you do a QueryFont on "fixed".  Part of the 
confusion is that X is taking care of the default gc.  Since a 
fontid is returned I assume it is loading the default font somewhere.

Bruce

    At the risk of belaboring this discussion beyond what anyone cares
    about, please try to USE the fontid returned by the program in .6.
    For example, try to put it into the font of another GC.  I will
    investigate the code in Xlib when I get a chance, but I really don't
    believe that an id for "fixed" exists.
    
    Burns
    

    I just checked the Xlib code.  XQueryFont simply copies the id that you
    passed in as the second argument into the id field of the output
    structure.  That means if you pass in a GC, you get a GC back.
    
    Burns
    

>That means if you pass in a GC, you get a GC back.
    
That's true.  What baffles me is that if you use the returned (gc) id
as the font id in XQueryTextExtents, for instance, it returns the same
values as if you do a LoadQueryFont and pass a "real" font id. 

Trying to use it as the font id in xlibintro, however gave a 
resounding
X error event received from server:  BadFont - parameter not a Font

I wonder how many other places you can use a GContext id instead of a 
font id and get good results? (rhetorical question)

Also, when it failed to load the "font" into the GC in xlibintro the 
string was still drawn, I assume in the default "fixed" font.  How
does "fixed" ever get loaded when it is just used directly from the
default value in a gc? 

Thanks for your patience.

Bruce

>That's true.  What baffles me is that if you use the returned (gc) id
>as the font id in XQueryTextExtents, for instance, it returns the same
>values as if you do a LoadQueryFont and pass a "real" font id. 

That's because the protocol defines QueryTextExtents as taking a "FONTABLE",
meaning it can be either a GC or a Font.  Many of the single font requests
allow this, but it is documented at least in the protocol.  It does not get
used much because of the difference between a GContext and a GC.  GC is what
is used in most drawing requests and is really a pointer to a client-side
data structure.  GContext is the actual ID which the client passes to the
server.  Applications don't usually have that.

>Trying to use it as the font id in xlibintro, however gave a 
>resounding
>X error event received from server:  BadFont - parameter not a Font>
>
>I wonder how many other places you can use a GContext id instead of a 
>font id and get good results? (rhetorical question)

See above.

>Also, when it failed to load the "font" into the GC in xlibintro the 
>string was still drawn, I assume in the default "fixed" font.  How
>does "fixed" ever get loaded when it is just used directly from the
>default value in a gc? 

The server knows about "fixed" as a special case and opens it right at the
beginning of the world.   Remember that the server has
data structures for all these resources that clients talk to the server about.
In general, as soon as the server gets an ID from a client, it turns that ID
into an address.  In the case of "fixed", it has a data structure, but it never
has an ID for it because the client can never talk about that font directly.
All the server has to do is to stick the font address into the GC structure
whenever a GC is created.

>Thanks for your patience.

No problem...it is a confusing subject.

Burns