nanogui: client/server protocol speedup
Subject:
Re: client/server protocol speedup
From:
####@####.####
Date:
30 Mar 2000 13:34:33 -0000
Message-Id: <20000330132424.16362.qmail@nameplanet.com>
On Thu, 30 Mar 2000 12:28:24 +0000 Morten Rolland ####@####.####
wrote:
>Greg Haerr wrote:
>> Keeping stuff
>> as readable text is probably good, providing it doesn't start
>> looking like X font descriptors.
>
>Ugh. We don't want that, no -*-*-*-)
The X font descriptors may look ugly, but they're flexible. And because they
are ugly, X allows just the kind of aliasing you suggested (take a look at
font.aliases in your font directories). There are good reasons for using a
textual font descriptor too, even though it's good practice to hide them from
the user :-)
>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 was thinking of making the attributes pure binary flags:
Not the best way to do it, IMHO. The good thing about pure text font
descriptors (they don't have to be as ugly as X's ;) is that the format
can easily be extended, and that it is easy to store a unique descriptor for
a certain font from a certain foundry, with a given set of attributes.
If you start using binary attributes, storing a complete description of
font attributes in configuration files etc. suddenly become a lot messier.
It also pose the problem of having to update the application to be able to
let the user specify fonts that use new font attributes whenever the server
is updated.
>Various algorithms can be used to find the closest font in case
>no exact attributes matched. It can be argued that boldness and
>spacing should be encoded as integer fields later, so I'd say that
>we state that only *one* of the width and boldness can be specified
>at a time. In practical use, this should not be a problem.
As you seem to have found (based on your constant definitions), width and
"boldness" are two very distinct features of a font. "boldness" is what is
usually called the font *weight*, or how thick the lines of the font is.
For instance it wouldn't be possible to support full CSS2 rendering
without supporting both stretching a font in the x direction and changing
font weight at the same time.
>The API of choice (with the current FONTID scheme) would be:
>
>GR_FONTID font = GrCreateFont("adobe/Times",MWFATTR_BOLD|MWFATTR_ITALIC);
> ....
>GrChangeFont(font,"Helvetica",100,MWFATTR_BOLD);
>GrChangeFontSize(font,120);
>GrChangeFontAttr(font,MWFATTR_ITALIC,0);
> ....
>GrDestroyFont(font);
The example above has a huge problem that highlights the issue with pretending
attributes are separate from the font name: You can't just turn of italics (or
bold for that matter), and expect to have a non-slanted font, unless you
explicitly make sure that the font opened with GrCreateFont() isn't slanted,
and that italics is applied by software. Another reason why separating it
doesn't really make sense.
Regards,
Vidar Hokstad
--
Get your firstname@lastname email for FREE at http://NamePlanet.com
