Subject:
RE: request for font utilities
From:
Greg Haerr ####@####.####
Date:
6 May 1999 19:21:30 -0000
Message-Id: <01BE97C3.5C1C7BA0.greg@censoft.com>
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
>
