Subject:
Re: client/server protocol speedup
From:
"Greg Haerr" ####@####.####
Date:
31 Mar 2000 06:21:00 -0000
Message-Id: <02b701bf9ad7$cf403140$15320cd0@gregh>
: In order to simplify, I have been thinking of the following:
:
: Each font is identified by:
:
: foundry,font-name/family-name,attributes
:
: Foundry and attributes are optional. If you use a unique
: font-name like "Times New Roman", this maps to the exepceted
: font directly if no attributes are specified. If attributes
: are used, they select a font within the "Times" family, as
: defined by the configuration file.
I think something more simple is even better, while still allowing
extreme specificity. Have a single string which is the facename,
and a set of attributes which also specify foundry and/or family
name (explained shortly). However, we allow aliasing from the
facename, so that more "facename strings" can be converted into
equivalent "facename+attributes" from an alias file.
For example, we keep the GrCreateFont call:
GR_FONTID GrCreateFont(char *name, int pixelsize, PMWLOGFONT pf)
an MWLOGFONT would contain the following (passing NULL would
specifiy defaults, unless overriden by expanded facename from the alias
file):
struct MWLOGFONT {
BOOL italic, underline;
int weight; // font weight - light, normal, bold, extrabold etc
int pitch; // default, monospace, proportional
int family; // FF_DONTCARE, FF_SERIF, FF_SANSSERIF etc
int foundry; // FF_RASTER, FF_TRUETYPE, FF_ADOBE etc
int charset; // ascii, iso8859, ansi, pc850, etc
int width; // width of font for use in selection - optional
};
Now, here's the idea: REMEMBER that Microwindows using either T1LIB or FREETYPE
must end up coming up with a filename, unless using a compiled-in font.
GrCreateFont ALWAYS returns a valid font, and uses the MWLOGFONT
only as hints. Depending on how the filenames are stored, a font selection
routine can be coded to be more or less complex. In fact, the user application
may want to take a part in examining the MWLOGFONT struct and
coming up with a filename. Of course, the alias file helps in this process,
but, ultimately, it just sets values in the MWLOGFONT structure. Having
multiple string values for facename, foundry and family will make the font
selection routine needlessly complicated for smaller systems. Having
said this, there's nothing wrong with having a rendering routine parse
string values from the facename or alias file into the MWLOGFONT struct.
With the above design, the user application always specifies fonts in the
same manner, without regard to the translate-to-filename mechanism that
somebody may want for the font selector. For instance, the above struct
could be filled out and then translated to the long-X11 description format,
if the fonts were stored as their X11 name. Or, on simpler systems, the
same user API routine would specify hints that were mostly ignored and
just the passed facename used as the font filename.
The foundry member being an int rather than a string also allows the user
program to hint that only a raster font or only a truetype font should be
searched for. Since known foundries are fairly well known, adobe, bitstream
et al are also specified with minimal translation for small systems.
Comments?
Greg
