[comp.windows.x] XLFD matching

Kimbrough@dsg.csc.ti.COM (Kerry Kimbrough) (02/27/90)

It seems that the spec doesn't really get down and define how OpenFont is supposed
to match font names containing wildcards. Are we to assume that ? and * are
to be treated as they are in Unix file name matching?

ekberg@ti-csl.csc.ti.COM (02/27/90)

Kerry,

 > It seems that the spec doesn't really get down and define how OpenFont is
 > supposed to match font names containing wildcards. Are we to assume that ?
 > and * are to be treated as they are in Unix file name matching?


From the X11R4 protocol specification describing OpenFont:

    This request loads the specified font, if necessary, and associates
    identifier fid with it.  The font name should use the ISO Latin-1 encoding,
    and uppercase and lowercase do not matter.  The interpretation of
    characters ``?'' (octal value 77) and ``*'' (octal value 52) in the name is
    not defined by the core protocol, but is reserved for future definition.  A
    structured format for font names is specified in the X Consortium standard
    ``X Logical Font Description Conventions''.

    Fonts are not associated with a particular screen and can be stored as a
    component of any graphics context.

This says to me that X11R4 version of OpenFont should treat the ``*'' and ``?''
characters as ordinary characters, but that the X11R5 version may specify
alternate meanings, such as the one that you suggest.

  -- tom (aisle C-4Q), ekberg@csc.ti.com

ken@hpcvlx.cv.hp.com (Ken Bronstein) (02/28/90)

Much of the the semantics for XLFD are not documented (or still being
debated) especially in light of scalable font technology.  I can't
speak for the SUN implementation in detail BUT the wild cards are
intended to be resolved with the first matching font,  where the
order of the fonts is reflected by the order of the returned names
from the XListFonts function.  As expected * matches any string, while
? matches any character.

Note that worse semantic debates can be made regarding the meaning of
requesting fonts of point size zero with outline font files; or other
stuff that is now being hammered out in the MIT X font working group.

daniel@mirsa.inria.fr (Daniel Dardailler) (02/28/90)

From article <2845074091-1038891@RIGI>, by Kimbrough@dsg.csc.ti.COM (Kerry Kimbrough):
> It seems that the spec doesn't really get down and define how OpenFont is supposed
> to match font names containing wildcards. Are we to assume that ? and * are
> to be treated as they are in Unix file name matching?

OpenFont is not supposed to match anything.
You must first use ListFonts with matching patterns and THEN use LoadFont
with a real fontname (one of those returned by ListFonts).
I'm currently working on a high level function (named ObtainFont), that 
will mask these tough mechanisms.

   Daniel Dardailler                   |      Email : daniel@mirsa.inria.fr  
   BULL  Centre de Sophia Antipolis    |      Phone : (33) 93 65 77 71       
         2004, Route des Lucioles      |      Telex :      97 00 50 F        
         06565 Valbonne CEDEX  France  |      Fax   : (33) 93 65 77 66      
				       |

rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (03/01/90)

    It seems that the spec doesn't really get down and define how OpenFont is
    supposed to match font names containing wildcards.

The XLFD isn't supposed to "define" the semantics of OpenFont, it's supposed
to lay down conventions for its use.

    Are we to assume that ? and * are
    to be treated as they are in Unix file name matching?

The Protocol specification says explicitly:

The interpretation of characters ``?'' (octal value 77) and ``*''
(octal value 52) in the name is not defined by the core protocol,
but is reserved for future definition.

In a strict sense, you should treat the use of ? and * as implementation
dependent.  Most R3 and R4 based servers implement pattern matching, but
there are still some R2 based servers out there that don't.  However, I
should note that the ANSC X3H3.6 committee working on ANSI standardization
of the protocol has resolved that these should do pattern matching.