nanogui: Thread: fonts in nanox

i have been playing about with nanox some more, and i have
been thinking it would be nice to have some sort fo dynamic 
fontness. this is how i see we do it:

the client requests a font
 - whether that bea wild stab in the dark or from
   a list obtained from the server....

the server looks in it's font cache and say hrmm do i 
have this loaded?
 - yes, update last accessed time
 - no, load font into memory

i then think it would be possible to unload fonts  that
haven' been used for a while.

if this hasn't been planned to be done anyone, i'm happy
to start work on it. 

chris-who-would-like some-nice-fonts

======================================================
| Chris Ross ( Boris` )         ####@####.#### |
|                          http://www.darkrock.co.uk |
`----------------------------------------------------' 

On Monday, December 06, 1999 3:15 AM, Chris Ross  wrote:
: i have been playing about with nanox some more, and i have
: been thinking it would be nice to have some sort fo dynamic 
: fontness. this is how i see we do it:
: 
: the client requests a font
:  - whether that bea wild stab in the dark or from
:    a list obtained from the server....
: 
: the server looks in it's font cache and say hrmm do i 
: have this loaded?
:  - yes, update last accessed time
:  - no, load font into memory
: 
Yes, this is relatively easy to do, but a couple things need to happen:

	o most important, we need a standard font naming scheme.  Yes,
this could be kluged into just passing the filename (without path) for the
time
being, but then there's no standard way to name fonts.

	o we add another couple entry points in the screen driver interface,
LoadFont()
and UnloadFont.  These routines just read a disk file in the internal format
into 
an alloc'd area of the screen driver, and return.

	Currently, the font is passed as a number (0-MAXFONT) that is
defined in device.h.  The additional fonts would be added above these
compiled-
in numbers.

	Microwindows currently doesn't depend on any operating system
support
for file i/o.  So this option should likely remain a compile-time support
option, for 
operating systems without file i/o or filesystems.

	o you might want to make sure that we have converters for all your
favorite fonts.  I used Ben Pfaff's converter for bdf files, and wrote one
for 
any windows truetype of bitmapped font.  These converters create in-core
font structures in C to be linked in.




: i then think it would be possible to unload fonts  that
: haven' been used for a while.

	Yep. I propose that the application that calls GrLoadFont also
call GrUnloadFont.

: 
: if this hasn't been planned to be done anyone, i'm happy
: to start work on it. 

Go ahead and take a hack at it.  If you need help, let me know.

Greg

======================================================
| Chris Ross ( Boris` )         ####@####.#### |
|                          http://www.darkrock.co.uk |
`----------------------------------------------------' 

On Mon, 6 Dec 1999, Greg Haerr wrote:

> On Monday, December 06, 1999 3:15 AM, Chris Ross  wrote:
> : i have been playing about with nanox some more, and i have
> : been thinking it would be nice to have some sort fo dynamic 
> : fontness. this is how i see we do it:
> : 
> : the client requests a font
> :  - whether that bea wild stab in the dark or from
> :    a list obtained from the server....
> : 
> : the server looks in it's font cache and say hrmm do i 
> : have this loaded?
> :  - yes, update last accessed time
> :  - no, load font into memory
> : 
> Yes, this is relatively easy to do, but a couple things need to happen:
> 
> 	o most important, we need a standard font naming scheme.  Yes,
> this could be kluged into just passing the filename (without path) for the
> time
> being, but then there's no standard way to name fonts.
> 
> 	o we add another couple entry points in the screen driver interface,
> LoadFont()
> and UnloadFont.  These routines just read a disk file in the internal format
> into 
> an alloc'd area of the screen driver, and return.
> 
> 	Currently, the font is passed as a number (0-MAXFONT) that is
> defined in device.h.  The additional fonts would be added above these
> compiled-
> in numbers.
> 

i think we should use a system similar to x.,,...? would this be okay?


> 	Microwindows currently doesn't depend on any operating system
> support
> for file i/o.  So this option should likely remain a compile-time support
> option, for 
> operating systems without file i/o or filesystems.
> 

true - but we could have a devfileio.c which has hooks for fs io
so os's that support itcan, and those that can't, dont. 
for those that can't we could compile in certain limited files.

> 	o you might want to make sure that we have converters for all your
> favorite fonts.  I used Ben Pfaff's converter for bdf files, and wrote one
> for 
> any windows truetype of bitmapped font.  These converters create in-core
> font structures in C to be linked in.
> 

i'm going to take a look at the xfs andwrite a curt down version
to link into the nanox server and microwindows - i will add support
for bitmapped fonts etc thats allready there...

> 
> 
> 
> : i then think it would be possible to unload fonts  that
> : haven' been used for a while.
> 
> 	Yep. I propose that the application that calls GrLoadFont also
> call GrUnloadFont.
> 

 we could make it so that when the app
requests a font the server loads it automatically, that way
the app need not know how to load and unload fonts....

> : 
> : if this hasn't been planned to be done anyone, i'm happy
> : to start work on it. 
> 
> Go ahead and take a hack at it.  If you need help, let me know.
> 
> Greg
> 
> 

will do.

> -----Original Message-----
> From: Chris Ross ####@####.####
> Sent: 07 December 1999 13:10
> To: Greg Haerr
> Cc: nanogui
> Subject: RE: fonts in nanox
>
>  we could make it so that when the app
> requests a font the server loads it automatically, that way
> the app need not know how to load and unload fonts....

In which case, won't you want GrListFont which returns a linked list of
font information, or similar, so you can add a "Browse for Font" dialog
to some apps.  Maybe not now, but something to consider for the
future....

	-Darran

--
 Darran D. Rimron            European Research & Development Manager
Real Data Services, 117-119 Marlborough Road, Romford, Essex, RM7 8AR
 ####@####.####                      http://www.getreal.co.uk/
 Phone:44-1708-70-44-33 Fax:44-1708-74-88-59 Mobile:44-7931-37-59-39

======================================================
| Chris Ross ( Boris` )         ####@####.#### |
|                          http://www.darkrock.co.uk |
`----------------------------------------------------' 

On Tue, 7 Dec 1999, Darran D. Rimron wrote:

> 
> > -----Original Message-----
> > From: Chris Ross ####@####.####
> > Sent: 07 December 1999 13:10
> > To: Greg Haerr
> > Cc: nanogui
> > Subject: RE: fonts in nanox
> >
> >  we could make it so that when the app
> > requests a font the server loads it automatically, that way
> > the app need not know how to load and unload fonts....
> 
> In which case, won't you want GrListFont which returns a linked list of
> font information, or similar, so you can add a "Browse for Font" dialog
> to some apps.  Maybe not now, but something to consider for the
> future....
> 
> 	-Darran
> 
> --
>  Darran D. Rimron            European Research & Development Manager
> Real Data Services, 117-119 Marlborough Road, Romford, Essex, RM7 8AR
>  ####@####.####                      http://www.getreal.co.uk/
>  Phone:44-1708-70-44-33 Fax:44-1708-74-88-59 Mobile:44-7931-37-59-39
> 
> 

if we request a font it would be nice to get an idea what availble to us,
and a client side font dialog would need the list func.

chris

: i think we should use a system similar to x.,,...? would this be okay?

Too complicated.  I think we should try to keep this a "small"
project.  The X Window Font Specification (XWFS?) is too large
as it is.  I still think that a filename in a GrLoadFont is probably
the best bet.  However, for those wanting font characterstics
(this is only really useful for human font picking, _not_ computer
programs picking fonts), we could either store information
about font size, etc in the font name, like X does, or we could
have a GrQueryFonts that loads them all up, gets their info,
unloads them all, and puts it all up in a (yet non-existent) listbox...



: 
: 
: > 	Microwindows currently doesn't depend on any operating system
: > support
: > for file i/o.  So this option should likely remain a compile-time
support
: > option, for 
: > operating systems without file i/o or filesystems.
: > 
: 
: true - but we could have a devfileio.c which has hooks for fs io
: so os's that support itcan, and those that can't, dont. 
: for those that can't we could compile in certain limited files.

That's exactly how we do it now, with the exception of the font loading.


: i'm going to take a look at the xfs andwrite a curt down version

What's xfs?


: to link into the nanox server and microwindows - i will add support
: for bitmapped fonts etc thats allready there...

We should probably stay with the in-core font structure that
supports fixed and proportional fonts.  This was designed to keep
core costs down, as most indices are bytes and font width
pixmaps are kept as shorts...


: 
: > 
: > 
: > 
: > : i then think it would be possible to unload fonts  that
: > : haven' been used for a while.
: > 
: > 	Yep. I propose that the application that calls GrLoadFont also
: > call GrUnloadFont.
: > 
: 
:  we could make it so that when the app
: requests a font the server loads it automatically,

Yes, exactly.  That's what GrLoadFont does - request a font.

Greg

: if we request a font it would be nice to get an idea what availble to us,
: and a client side font dialog would need the list func.

That functionality can go into a special font lister widget, rather than the
base
graphics engine

======================================================
| Chris Ross ( Boris` )         ####@####.#### |
|                          http://www.darkrock.co.uk |
`----------------------------------------------------' 

On Tue, 7 Dec 1999, Greg Haerr wrote:
> What's xfs?
> 

the X Font Server