nanogui@linuxhacker.org
nanogui@linuxhacker.org
: Yes, These are just parameters to GdText. In the case of freetype (I can't
speak
: for T1lib), it doesn't need to perform a procedure call at the time each is
set ...
T1lib is the same way
: These parameters are used at the time of rendering i.e. probably in the GdText
: routine ...
Yep, the same with both
:
: The MWFONT structure could be passed to GdText, but if you don't have the
: GdFontSet* routines then how higher level interface would change these
parameters
: before calling GdText ? By setting the values in the structures directly ?
I see your point, and after looking at the example below, I agree with
you, for simplicity. Perhaps the GrSetFontAntiAliasing routines
etc are just local to the client, and hidden from the user. But then
that means that the MWFONT struct's got to be passed with GrText
every time it's called... So maybe you're idea is better. I'm just trying
to keep the font API entry point count down....
:
: Here is a typical higher-level usage I would see (in pseudo-code):
:
: LoadFont() <- this would set default parameters (Ex: kern=yes, aa=no, ...)
: SetSize(20)
: SetAngle(45)
: DrawText(X1, Y1)
: SetAngle(0)
: SetAntialiasing(yes)
: SetPalette()
: DrawText(X2, Y2)
: ...
:
: UnloadFont()
I like the above, it's simple. In Nano-X, most of the above parms
should be settable in a GC, and the GC passed to DrawText.
:
: > I talked with Vidar about this I think and he said that sometimes you
: > may not be able to get a bitmap per character. Is this true? What if
: > we can't get a bitmap with a font renderer? I thought Vidar's T1
implementation
: > couldn't get a bitmap... But of course then we've got big clipping
problems.
:
: I think he said the opposite. You can always have a bitmap ..
Good. If we can always get the bitmap, then things will go well with all
the font stuff.
Regards,
Greg
nanogui@linuxhacker.org