nanogui: Fonts offset leads to wrong memory location -- genfont.c bug??
Subject:
Re: [nanogui] Fonts offset leads to wrong memory location -- genfont.c bug??
From:
"Greg Haerr" ####@####.####
Date:
21 Nov 2006 03:09:15 +0000
Message-Id: <145701c70d1a$63654340$6401a8c0@winXP>
: I realized that the C language files created with the convfnt32.exe tool
: generated a font structure like:
The convfnt32.exe is a very old tool. Much better to try to
convert source based .bdf files which could then
capture all information, including the proportional
width information. Convfnt32.exe works by reading
bits from the screen, not exactly a great way. Of course,
it could be enhanced by getting font information internally
and adding the width array from that information.
I'll write up the missing member data as a bug.
:
: My first attempt was replacing 'winArial8x22_offset' with the value 0. It
: indeed solved the problem, but it only worked for monospaced (fixed width)
: fonts.
Of course: the missing data points to the width table, which isn't
present.
:
: Single-stepping through the code, I located the source of the problem
(line
: 171 in genfont.c):
:
: /* get font bitmap depending on fixed pitch or not*/
: bits = pf->bits + (pf->offset? pf->offset[ch]: (pf->height * ch));
:
: So, when offset is 0, the actual offset value is not uset to calculate the
: bitmap address in memory, and everything works fine. However, any non-zero
: value would cause the calculation to lead to the wrong memory location.
Yes, and if you're lucky, no core dump.
:
: I was able to get things working by making the following change:
:
: //bits = pf->bits + (pf->offset? pf->offset[ch]: (pf->height * ch));
: bits = pf->bits + (pf->offset? ((unsigned short *)pf->offset)[ch] :
: (pf->height * ch));
:
: Now, I believe that the root of all problems was that the 'offset'
variable
: was declared as an 'unsigned long *', while 'bits' was an 'unsigned short
: *'. Actually, 'bits' is declared as a pointer to the MWIMAGEBITS type,
: which in turn is defined as an unsigned short. I'm not sure it is a good
: thing to have these two types mixed when doing pointer arithmetic.
No, this has nothing to do with pointer arithmetic, the
bits = pf->bits + ... means that we want to increment/index
the pf->bits pointer MWIMAGEBITS amount over. In other
words, this is used to find exactly the start of an MWIMAGEBITS
which happens to be the start of a proportional character. We
can't index it using a straight multiply because there isn't a
standard character width.
The pf->offset is declared as an 'unsigned long *' because that
allows font bitmap data longer than 64k. This was earlier declared
to be 'unsigned short *' but was buggy for large fonts.
:
: My question is: does this qualify as a bug? Shouldn't it be fixed in
: upcoming versions?
Nope, see above.
I'm just getting started with microwindows, so I don't
: feel confident enough for making changes in its core code, but this really
: seems the right thing to do.
No problem, but you're just lucky that the program started working.
The font still displays incorrectly, doesn't it?
Regards,
Greg
