nanogui: Small "bug" in FreeType 1 support (engine/font_freetype.c)
Subject:
Re: [nanogui] Small "bug" in FreeType 1 support (engine/font_freetype.c)
From:
"Paul Bartholomew" ####@####.####
Date:
12 Jul 2005 03:04:11 +0100
Message-Id: <BAY108-F29B7F771D02B704F74D14DEFDF0@phx.gbl>
>I don't have the code in front of me, but the background
>may still need to be drawn, is this handled in drawchar()?
I'm not sure where the background would be drawn (probably 'up' a level from
'drawchar()'), but it doesn't appear that the change I suggest ('return'
from 'drawchar()' if width/height is zero) would affect that.
If you don't return, it continues on, mallocs a zero-length bitmap array,
and ends up calling GdArea() with that (possibly NULL) bitmap pointer, and a
width/height of "0". I assume GdArea will do nothing if width/height are
"0".
So, returning before the malloc() should have no effect on the output.
BTW, my interpretation of how this FT1 code is working for 'space'
characters is that the code 'above' drawchar() will adjust x/y by a certain
amount (from the space character metrics). So, even though the 'drawchar'
code does nothing (the actualy *bitmap* for a 'space' is zero width/height),
space characters still occupy space (it's not as if returning from
'drawchar' will result in words all crammed together).
- Paulb
>From: "Greg Haerr" ####@####.####
>To: "Paul Bartholomew" ####@####.####
>Subject: Re: [nanogui] Small "bug" in FreeType 1 support
>(engine/font_freetype.c)
>Date: Mon, 11 Jul 2005 16:00:54 -0600
>
>: It can be argued that a malloc of zero bytes is 'legal', but I wouldn't
>be
>: surprised if certain implementations consider it an error.
>
>Many implementations will return NULL in this case, definitely
>not what we want.
>
>
>
>:
>: I think the code in drawchar should be changed to return if either
>: width/height are zero:
>
>Agreed, I don't have the code in front of me, but the background
>may still need to be drawn, is this handled in drawchar()?
>
>Regards,
>
>Greg
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ####@####.####
>For additional commands, e-mail: ####@####.####
>
