nanogui: client/server protocol speedup


Previous by date: 30 Mar 2000 19:11:51 -0000 Re: IPC client/server comm., Greg Haerr
Next by date: 30 Mar 2000 19:11:51 -0000 Microwindows.org site back up, Greg Haerr
Previous in thread: 30 Mar 2000 19:11:51 -0000 Re: client/server protocol speedup, Greg Haerr
Next in thread: 30 Mar 2000 19:11:51 -0000 Re: client/server protocol speedup, Greg Haerr

Subject: Re: client/server protocol speedup
From: Morten Rolland ####@####.####
Date: 30 Mar 2000 19:11:51 -0000
Message-Id: <38E3B2E4.41A24619@screenmedia.no>

####@####.#### wrote:
> 
> >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 :-)

Yes, X11 is good enough in this respect, although the aliasing is mostly
in reverse: Take a nice understandable name and make an ugly alias to it
so you can select the font in xfontsel.... What I think X11 lacks
is a common standard that makes an X-app more portable, and
a simpler way for an application to handle fonts.  This includes
how to select bold, or something more bold than regular.

> >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.

This is also possible with the above mentioned scheme, you just have to
request a full font name (which is most probably aliased into something
unreadable like a filename).

But if you *later* want a bold version of the font, then you can
ask for it, and voila!  This is very common practice on the web:

<FONT name="Times New Roman">Times New Roman can be <b>BOLD</b></font>

My syntax may be wrong here... but the idea is that one wants to select
a font, and then turn it into bold for a while, or italics... By
defining a binary flag to turn on bold, the API is very precise
about what is the *standard* way of requesting a bold font - a textual
appending of " Bold" can be defined, but the attributes scheeme
carves this in stone.

Now, the font alias list can also let you define a font like
"Times New Roman Not Bold At All", put it in its own family, and
when you request this font, you will get *it*, and no other (no
matter the attributes specified).  Thus get the same behaviour as
vidar suggests, too.

> If you start using binary attributes, storing a complete description of
> font attributes in configuration files etc. suddenly become a lot messier.

No, the configuration files are ascii, and the config API call will warn
you of an illegal attribute which is unusable by the applications (e.g. has
no associated flag).  The mostly half finished work on this looks really
nice imho, the first few lines of the config file could look like:

# Configuration file for nano-X, define fonts
#
# The following fonts are URW fonts and some aliases

#    Fndry Family Font-name             Attributes                       
Name(phys)
font URW BookmanL BookmanL-DemiBold     Demibold,Serif,Proportional      
b018015l
font URW BookmanL BookmanL-DemiBoldItal Demibold,Italic,Serif,Proportinal
b018035l
font URW BookmanL BookmanL-Ligh         Light,Serif,Proportional         
b018012l
font URW BookmanL BookmanL-LighItal	Light,Italic,Serif,Proportinal    b018032l

#          Family  Font-name   Attributes      Aliased to
font alias Bookman Bookman     DemiBold        URW,BookmanL-DemiBold
font alias Bookman Bookman     DemiBold,Italic URW,BookmanL-DemiBoldItal
font alias Bookman Bookman     Light           URW,BookmanL-Ligh
font alias Bookman Bookman     Light,Italic    URW,BookmanL-LighItal

> 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.

Yes... In a generic manner (like the <b> </b> example above), but
then the application would probably have to be updated anyway.
For a single font, the full name can be used to target the new
font regardless of the attributes.

> 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.

No, but stretching and varible weight are parametric attributes that needs
to be set with a separate function call just like the size of the font.
This is a feature for the web, for typesetting you *don't* want parametric
weight!  For this, the attribute concept is just fine, and the stuff needed
for CSS2 is an additional feature, not an alternative imho.  Also, not all
renderers may support it.

Using the attributes would increase the font cache reuse percentage --- with
applications that can say 35% weight would polute the font cache big time
in addition to not looking good most of the 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.

This is not quite true, if you select a font that is slanted, this will
translate into a font family name and attributes, and if you change the
attributes, a new font in the family (e.g. non-slanted) will be selected.

This means:

Select font "Times Roman Italic"   ===> Font-family="Times", Attr="Italic"
Clear Italics flag ===> Font-family="Times", Attr="Roman"

Is this what you meant?

Regards,
Morten Rolland, Screen Media

Previous by date: 30 Mar 2000 19:11:51 -0000 Re: IPC client/server comm., Greg Haerr
Next by date: 30 Mar 2000 19:11:51 -0000 Microwindows.org site back up, Greg Haerr
Previous in thread: 30 Mar 2000 19:11:51 -0000 Re: client/server protocol speedup, Greg Haerr
Next in thread: 30 Mar 2000 19:11:51 -0000 Re: client/server protocol speedup, Greg Haerr


Powered by ezmlm-browse 0.20.