nanogui: Thread: request for font utilities

Currently, the nanogui project uses a hard-coded C structure for font display.
A utility, bdftobogl, written by debian is included to convert X .bdf files to
C structures.

Does anyone have any conversion utilities for the older windows 3.1 .FNT file
format to C?  I would like to convert some raster graphics fonts for use with nanogui
and not all my fonts are bdf format.

Greg

On Wed, 5 May 1999, Greg Haerr wrote:

> Currently, the nanogui project uses a hard-coded C structure for font display.
> A utility, bdftobogl, written by debian is included to convert X .bdf files to
> C structures.

Take a look at the w windowing system ... 
http://www.students.tut.fi/~t150315/

many things are already there...

alex

> 
> Does anyone have any conversion utilities for the older windows 3.1 .FNT file
> format to C?  I would like to convert some raster graphics fonts for use with nanogui
> and not all my fonts are bdf format.
> 
> Greg
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

Alexander Peuchert
####@####.####
http://www.peuchert.de ( not very interesting yet ;-) )

Alexander Peuchert ####@####.#### writes:

   On Wed, 5 May 1999, Greg Haerr wrote:

   > Currently, the nanogui project uses a hard-coded C structure for font display.
   > A utility, bdftobogl, written by debian is included to convert X .bdf files to
   > C structures.

   Take a look at the w windowing system ... 
   http://www.students.tut.fi/~t150315/

That uses a new font format, .wfnt.  Also, the font conversion utility
that comes with W only supports fixed-width fonts, whereas BOGL uses
proportional fonts.

What format do we want NanoGUI to read fonts in?  I've been looking at
a few choices:

	* .bdf
	  Advantages: well documented, simple format.
	  Disadvantages: not as compact as some other formats.

	* .pcf
	  Advantages: smaller than .bdf
	  Disadvantages: relatively complicated format, not documented

	* .wfnt
	  Advantages: simple
	  Disadvantages: not a standard format, not documented

I could have a bdf font reader pretty fast if that's what we want.

   > Does anyone have any conversion utilities for the older windows 3.1 .FNT file
   > format to C?  I would like to convert some raster graphics fonts for use with nanogui
   > and not all my fonts are bdf format.

The W readme says that WINE has a fnt2bdf program.  In addition,
there's a ttftobdf program that comes with freetype.
-- 
"To the engineer, the world is a toy box full of sub-optimized and
 feature-poor toys." --Scott Adams

Ben - 
	What a *great* idea.  I think we should definitely have a .bdf font
read incorporated into bogl.  Let me explain why bogl should have it rather than
nanogui:

	In building the device-independent layer for nanogui, which comprises of
the new screen-driver api (which is now completed and supports all the cursor
clipping I spoke of yesterday, complete with window clipping at the upper level), I was
looking at the problem of removing "bogl.h" from all the nanogui source, except
for one file, which stubs the screen driver api to bogl.  The "bogl_font" structure was
required to be know by some upper level routines, but yet it was defined in the low
level driver.  I thought of two possible scenarios:

	1. make an upper level structure that of course is device-independent that 
would exactly mirror the lower-level font structure.  This would require that all fonts
be implemented the same way at the lower level -or- writing extensive conversion
routines at the nanogui middle level.  but nanogui is nano, right?  Also we want
to support *any* low level graphics library, not just bogl.

	2. define a font type "typedef void *PFONT" for the time being, which
means that all the nanogui code can do is pass around a font pointer, not
knowing what it is.  I chose this route because soon the screen api will support
GetFont* routines that will allow the mid level to ask the lower level for widths, etc.
This means the lower level screen drivers might have to support a few more Get* entry
points, but I think this is worth it.

So - bogl definitely should handle reading in .bdf fonts.  The architecture should
work with the same bogl_font struct whether the font is compiled-in or read in, 
and there should be a compile-time option.  This means that you should "name" the
compiled in fonts, and let the mid level ask for fonts by name, and they will either get the
"fast" (compiled-in) or slower disk read in font or NULL depending on the compile time options.

If you want to take a first crack at it, I'd be happy to help with the api as I integrate
unmodified bogl libraries into nanogui.  At this point, I have v0.3 completed with the
screen driver interface, but I won't be able to check it un until early next week, when
I'll also have the mouse and keyboard apis done.

BTW - you have a bug in the *_pointer routine in all your bogl libs.  The bogl_pointer
routine reads a cursor from struct bogl_pointer, which uses ->hx and ->hy members.
These are adjusted in the first line in the proc:

	x1 -= pointer->hx

The hotspot adjustment code is bad because arrow.c lists a -1 offset for the 
hotspot on the mouse cursor.  This needs to be changed to not adjust for -1 hotspots,
or, preferably, 0,0 be used to indicate the actual cursor hotspot, which is what I did.

Now that I have full blown cursor clipping and line drawing working, I'm finding
a number of off-by-one bugs.

Greg

some comments follow:

On Thursday, May 06, 1999 11:51 AM, Ben Pfaff ####@####.#### wrote:
> Alexander Peuchert ####@####.#### writes:
> 
>    On Wed, 5 May 1999, Greg Haerr wrote:
> 
>    > Currently, the nanogui project uses a hard-coded C structure for font display.
>    > A utility, bdftobogl, written by debian is included to convert X .bdf files to
>    > C structures.
> 
>    Take a look at the w windowing system ... 
>    http://www.students.tut.fi/~t150315/
> 

	I've pulled all this down and will look at it.



> That uses a new font format, .wfnt.  Also, the font conversion utility
> that comes with W only supports fixed-width fonts, whereas BOGL uses
> proportional fonts.
> 
> What format do we want NanoGUI to read fonts in?  I've been looking at
> a few choices:
> 
> 	* .bdf
> 	  Advantages: well documented, simple format.
> 	  Disadvantages: not as compact as some other formats.

	I think we should go with the bdf format because many many folks
have their favorite font files in bdf format.



> 
> 	* .pcf
> 	  Advantages: smaller than .bdf
> 	  Disadvantages: relatively complicated format, not documented
> 
> 	* .wfnt
> 	  Advantages: simple
> 	  Disadvantages: not a standard format, not documented
> 
> I could have a bdf font reader pretty fast if that's what we want.
> 
>    > Does anyone have any conversion utilities for the older windows 3.1 .FNT file
>    > format to C?  I would like to convert some raster graphics fonts for use with nanogui
>    > and not all my fonts are bdf format.
> 
> The W readme says that WINE has a fnt2bdf program.  In addition,
> there's a ttftobdf program that comes with freetype.

This is what I was looking for, I'll grab the fnt2bdf converter, and bogl will use the
bdf file format.



> -- 
> "To the engineer, the world is a toy box full of sub-optimized and
>  feature-poor toys." --Scott Adams
> 

Greg Haerr ####@####.#### writes:

[...]
   So - bogl definitely should handle reading in .bdf fonts.  The architecture should
   work with the same bogl_font struct whether the font is compiled-in or read in, 
   and there should be a compile-time option.  This means that you should "name" the
   compiled in fonts, and let the mid level ask for fonts by name, and they will either get the
   "fast" (compiled-in) or slower disk read in font or NULL depending on the compile time options.
[...]

Yes, I will work on that.  Probably some working code later today or
this weekend maybe.

   BTW - you have a bug in the *_pointer routine in all your bogl libs.  The bogl_pointer
   routine reads a cursor from struct bogl_pointer, which uses ->hx and ->hy members.
   These are adjusted in the first line in the proc:

	   x1 -= pointer->hx

   The hotspot adjustment code is bad because arrow.c lists a -1 offset for the 
   hotspot on the mouse cursor.  This needs to be changed to not adjust for -1 hotspots,
   or, preferably, 0,0 be used to indicate the actual cursor hotspot, which is what I did.

Here, let me explain the rationale behind the cursor hotspot: the
hotspot is the point at which the user expects the pointer is
pointing.  For the standard arrow cursor, this is the pixel directly
to the upper-left of the arrow itself; i.e., it's not actually part of
the bitmap.  This is intentional.

The reason that the position of the cursor is adjusted for the hotspot
position is so that when the cursor type changes, the cursor won't be
pointing to a different spot on the screen.  i.e., if you change from
an arrow cursor to an I-beam for text, then the I-beam will be
centered over the place where the arrow was just pointing to.

   Now that I have full blown cursor clipping and line drawing working, I'm finding
   a number of off-by-one bugs.
-- 
"To the engineer, the world is a toy box full of sub-optimized and
 feature-poor toys." --Scott Adams

Greg Haerr ####@####.#### writes:

	   What a *great* idea.  I think we should definitely have a .bdf font
   read incorporated into bogl.  Let me explain why bogl should have it rather than
   nanogui:

Your wish is my command :-) I have written such a thing today, and you
can find the new version of bogl at
	ftp://cscw.msu.edu/bogl-19990507.tar.gz
Unfortunately it's way past my bedtime for finals week so I don't have
time to check it in to cvs properly.  Also it needs to have a little
more skeleton code added, but it works in the sense that it reads in a
.bdf and builds a struct bogl_font from it, with the proof that it
works in the bdftobogl program being rewritten using it.

It feels really good to get back to writing code...

Ben

My comments follow...

On Thursday, May 06, 1999 2:11 PM, Ben Pfaff ####@####.#### wrote:
> Greg Haerr ####@####.#### writes:
> 
> [...]
>    So - bogl definitely should handle reading in .bdf fonts.  The architecture should
>    work with the same bogl_font struct whether the font is compiled-in or read in, 
>    and there should be a compile-time option.  This means that you should "name" the
>    compiled in fonts, and let the mid level ask for fonts by name, and they will either get the
>    "fast" (compiled-in) or slower disk read in font or NULL depending on the compile time options.
> [...]
> 
> Yes, I will work on that.  Probably some working code later today or
> this weekend maybe.
> 

	Cool!


>    BTW - you have a bug in the *_pointer routine in all your bogl libs.  The bogl_pointer
>    routine reads a cursor from struct bogl_pointer, which uses ->hx and ->hy members.
>    These are adjusted in the first line in the proc:
> 
> 	   x1 -= pointer->hx
> 
>    The hotspot adjustment code is bad because arrow.c lists a -1 offset for the 
>    hotspot on the mouse cursor.  This needs to be changed to not adjust for -1 hotspots,
>    or, preferably, 0,0 be used to indicate the actual cursor hotspot, which is what I did.
> 
> Here, let me explain the rationale behind the cursor hotspot: the
> hotspot is the point at which the user expects the pointer is
> pointing.  For the standard arrow cursor, this is the pixel directly
> to the upper-left of the arrow itself; i.e., it's not actually part of
> the bitmap.  This is intentional.

	Well, I understand that, except that with negative hotspot
numbers, the graphics subsystem can't create proper "cursor clipping bounding
boxes" for the mouse cursor.  In other words, when graphics output
is being performed near the cursor, the cursor needs to be erased, graphics output
occurs, then the cursor is redrawn.   In all other operating systems, the 
cursor hotspot is part of the cursor image , that is, some part of the image's bounding
rectangle.  We would have to special case upper-level code to handle this case.

Another solution would be to move the cursor south-east one pixel in it's own
bitmap, and then make the hotspot 0,0.  This gives the effect you want:  that of
the hotspot not being the "tip" of the cursor.


> 
> The reason that the position of the cursor is adjusted for the hotspot
> position is so that when the cursor type changes, the cursor won't be
> pointing to a different spot on the screen.  i.e., if you change from
> an arrow cursor to an I-beam for text, then the I-beam will be
> centered over the place where the arrow was just pointing to.
> 
>    Now that I have full blown cursor clipping and line drawing working, I'm finding
>    a number of off-by-one bugs.

NanoX v0.3 is being released today, I have a number of things to talk about regarding
the coordinate system that nanoX and the graphics libraries need to use.  More on this
in another email...


> -- 
> "To the engineer, the world is a toy box full of sub-optimized and
>  feature-poor toys." --Scott Adams
> 

Greg Haerr ####@####.#### writes:

   > Here, let me explain the rationale behind the cursor hotspot: the
   > hotspot is the point at which the user expects the pointer is
   > pointing.  For the standard arrow cursor, this is the pixel directly
   > to the upper-left of the arrow itself; i.e., it's not actually part of
   > the bitmap.  This is intentional.

	   Well, I understand that, except that with negative hotspot
   numbers, the graphics subsystem can't create proper "cursor clipping bounding
   boxes" for the mouse cursor.  In other words, when graphics output
   is being performed near the cursor, the cursor needs to be erased, graphics output
   occurs, then the cursor is redrawn.   In all other operating systems, the 
   cursor hotspot is part of the cursor image , that is, some part of the image's bounding
   rectangle.  We would have to special case upper-level code to handle this case.

   Another solution would be to move the cursor south-east one pixel in it's own
   bitmap, and then make the hotspot 0,0.  This gives the effect you want:  that of
   the hotspot not being the "tip" of the cursor.

Either way is fine, I guess.  The reason I chose (-1,-1) for the
cursor hotspot originally was that that was the way I remembered
Microsoft doing it years and years ago in the Microsoft Mouse driver
for DOS, and now that I look it up in my ancient manual, I was right.
But emulating Microsoft is not exactly desirable most of the time :-)
It's fine with me however you want to change it.

> 	Well, I understand that, except that with negative hotspot
> numbers, the graphics subsystem can't create proper "cursor clipping bounding
> boxes" for the mouse cursor.  In other words, when graphics output

Umm.. the hot spot doesnt matter surely. Your hot spot can be the other side
of your desk even, its not drawn so doesnt need clipping ?

The DOS port is funny btw. Maybe we will get Gtk for DOS next 8)

Alan Cox ####@####.#### writes:

   > 	Well, I understand that, except that with negative hotspot
   > numbers, the graphics subsystem can't create proper "cursor clipping bounding
   > boxes" for the mouse cursor.  In other words, when graphics output

   Umm.. the hot spot doesnt matter surely. Your hot spot can be the other side
   of your desk even, its not drawn so doesnt need clipping ?

I assumed he meant that there was some other problem with the
hotspot.  Can you clarify, Greg?
-- 
"MONO - Monochrome Emulation
 This field is used to store your favorite bit."
--FreeVGA Attribute Controller Reference