nanogui: request for font utilities


Previous by date: 10 May 1999 16:38:03 -0000 Re: Developers, Alex Holden
Next by date: 10 May 1999 16:38:03 -0000 Re: request for font utilities, Ben Pfaff
Previous in thread: 10 May 1999 16:38:03 -0000 Re: request for font utilities, Ben Pfaff
Next in thread: 10 May 1999 16:38:03 -0000 Re: request for font utilities, Ben Pfaff

Subject: RE: request for font utilities
From: Greg Haerr ####@####.####
Date: 10 May 1999 16:38:03 -0000
Message-Id: <01BE9AD1.71BB1140.greg@censoft.com>

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
> 

Previous by date: 10 May 1999 16:38:03 -0000 Re: Developers, Alex Holden
Next by date: 10 May 1999 16:38:03 -0000 Re: request for font utilities, Ben Pfaff
Previous in thread: 10 May 1999 16:38:03 -0000 Re: request for font utilities, Ben Pfaff
Next in thread: 10 May 1999 16:38:03 -0000 Re: request for font utilities, Ben Pfaff


Powered by ezmlm-browse 0.20.