nanogui: Nano-X: Problem with Drawing big ttf fonts to pixmaps
AW: [nanogui] Nano-X: Problem with Drawing big ttf fonts to pixmaps
Andreas Schwinghammer ####@####.####
7 Jan 2014 14:31:35 -0000
I hope you arrived 2014 very well.
To my Problem:
Wayne´s solution put me into the rigth way and I could work with it.
It´s only a little bit arkward.
I thank you for your offer to help me to debug nano-X for my problem.
But at the moment I haven´t got enough time to do this.
I hope I can come back to you if I have more time for this.
Von: Greg Haerr ####@####.####
Gesendet: Sonntag, 22. Dezember 2013 04:32
An: Andreas Schwinghammer
Betreff: Re: [nanogui] Nano-X: Problem with Drawing big ttf fonts to pixmaps
> I want to draw a character to a pixmap. To get the dimensions for this pixmap I use the width of the character.
> After I create the Font using GrCreateFont() I use GrGetFontInfo()-Function for getting the character information.
> The drawing itself works. I only get the wrong character widths => so I have the wrong pixmap width.
> My problem, if I want a font with a height > 255pts, I get some characters with a width > 255pts.
> In MWFONTINFO structure there is "widths" defined as MWUCHAR (unsigned char).
> But I think I need unsigned int for my problem
Andreas, I'm not sure whether you've got the problem solved with Wayne's
help, but I wanted to comment nonetheless:
If you change the widths declaration from MWUCHAR to unsigned short,
you may also have to update the MWFONTPROCS GetFontInfo routine
as well, depending on the font processor. For most bitmap fonts, these
are handled by drivers/genfont.c::gen_getfontinfo(), which uses the
MWCFONT structure, sometimes with the automated font conversion tool
convbdf. The MWCONT struct has an additional unsigned char *width
that needs to be changed. You will also have to make sure that the
auto-converted .bdf -> .c fonts are regenerated by running "make realclean".
On the other hand, if you're using freetype fonts, that driver
need changing as it dynamically writes the widths array.
> My issue for getting the right width is to change this to another data typ (f.e. unsigned int).
> I tried this, but it ran to an error
> "nxclient xxxxxxx: Wrong packet type 40 (expected 17)" (in client.c CheckBlockType(short packettype))
This error is the result of improperly marshalled data
between client and server, which is done by the GetFontinfo
routines in nanox/client.c and nanox/srvnet.c. When the client
is expecting to read the MWFONTINFO struct preceded by
the GrGetFontInfo code 17 (in nanox/nxproto.h), it's getting
a 40 instead. This can be debugged by looking at your application
code and seeing what GrXXX call was made immediately preceding
the GrGetFontInfo() call.
You can uncomment the DPRINTF HandleClient in nanox/srvnet.c::GsHandleClient()
to help see the routines being handled by the server.
In quickly looking at all of this, I can't see how changing the
MWFONTINFO struct size causes this error. Of course, you're
recompiling both client and server, I presume.
> What I have to do to get the right font widths for my characters?
It looks like using GrGetGCTextSize will work for you.
To answer your later question as to why, the GrGetGCTextSize function
returns the height/width in GR_SIZE (int) values, while the GrGetFontInfo
function returns widths in a byte array, to save size with the thought
that there wouldn't be a need for drawing wide > 255 glyphs on flat screens.
In retrospect, probably not a great decision.
If you're interested, I'll help you debug making GrGetFontInfo work using
unsigned short rather than MWUCHAR for widths.
> Many thanks