CLIM mail archive
[Prev][Next][Index][Thread]

defining "virtual" fonts

    Date: Wed, 8 May 1991 16:02 EDT
    From: Richard Lamson <rsl@max-fleischer.sf.dialnet.ila.com>

	Date: Fri, 19 Apr 91 10:25:02 CDT
	From: George Williams <george@hsvaic.boeing.com>

	Is there an equivalent in CLIM 1.0 (I don't have CLIM yet, it's on
	order) to the Symbolics function si:define-character-style-families?
	I want to be able to define a font face name and family of styles, and
	have them mapped to "real" fonts (i.e., fonts that are installed on my
	machine).

    Sure.  Depends exactly what you want to do, of course, as to what the right way
    to do this.  Here are the primitives:

      (clim:define-text-style-mappings device character-set
	    . style-specs)

    will define the various style specifications for the given device.  The syntax is
    pretty straightforward; see the source for GENERA-IMPLEMENTATION.LISP for a
    simple example.

    Of course, to use this you need to get the device object.  Once you have your root
    window, you get it with CLIM::STREAM-DISPLAY-DEVICE-TYPE, but you can't use that
    at load time, in general, because you don't want to create your root window just
    by loading your software, so you probably shouldn't use DEFINE-TEXT-STYLE-MAPPINGS
    (it's mostly for implementors of ports, where the implementor will put a display
    device into a variable, like the Genera si:*b&w-device* or whatever it's called).

    All is not lost, however.  There is a function named CLIM:ADD-TEXT-STYLE-MAPPING,
    which takes a device, a character set, a text style and a font.  This function is
    intended to use at runtime, after you have your streams in hand.  The device is
    gotten as above.  The character set is probably CLIM:*STANDARD-CHARACTER-SET* (if
    you have a non-standard character you can call CLIM::CHAR-CHARACTER-SET-AND-INDEX
    on it, ignoring the second value).  [Character sets are currently ignored, but if
    you want to continue to have working code in the future, you should use them.]
    The text style must be a text style object, not a list.  The result can be a font
    name or a cons (:STYLE . text-style), which is an "indirect style".

    For example, you can do the following to a Genera-based window:

      (let ((device (clim::stream-display-device-type root)))
	(clim:add-text-style-mapping
	  device clim:*standard-character-set*
	  (parse-text-style '(:eurex :italic :huge)) 'fonts:eurex24i)
	(clim:add-text-style-mapping
	  device clim:*standard-character-set*
	  (parse-text-style '(:eurex :italic :normal)) 'fonts:eurex12i))

Since CLIM internally deals in point sizes, it may be better to
specify the size in points rather than as a "logical" size, that is,
'(:EUREX :ITALIC 24) and '(:EUREX :ITALIC 12).

    There is currently a bug in 1.0 for Genera whereby it doesn't load Genera screen
    fonts automatically.  Alternatively, you can load the font yourself and pass in
    the font itself instead of its name.

    The CLX implementation requires that you pass in X font objects rather than names.
    Unfortunately, getting font objects instead of font names requires that you have
    the X display object in hand.  There is no advertised way to get this currently,
    but you can get the CLIM::DISPLAY slot out of the root window.

    I will put the fact that you can't give names instead of font objects to
    ADD-TEXT-STYLE-MAPPING on the bug list, as well as the fact that you have to parse
    text styles before passing them in to ADD-TEXT-STYLE-MAPPING.

I would not call anything having to do with ADD-TEXT-STYLE-MAPPING and
CLIM:DEFINE-TEXT-STYLE-MAPPINGS a bug, nor would I depend on them
continuing to operate the way they do today.  They are not in the CLIM
1.0 documentation precisely because we did not really believe in the
interfaces.  Why not?  Well, those interfaces don't even work for some
display devices, such as PostScript.  What is needed is some careful
thought about what the interfaces should really look like for *all*
display devices.  Only then should the interfaces be advertised in the
documentation.

With the above warning, what Richard says is accurate and will work for
the present in CLIM 1.0, but may stop working at some point in time.

**Important Note**
One more thing that everyone should be aware of: if you are using
something that is not documented in the CLIM 1.0 documentation, you run
the risk of losing in the future.  Anything not in the documentation
must be considered internal and subject to change without warning, *even
if it exported from the CLIM package*.

0,,
References:
Main Index | Thread Index