Subject:
RE: Fonts revisited
From:
Greg Haerr ####@####.####
Date:
19 Jan 2000 20:40:15 -0000
Message-Id: <C1962B36D9BBD311B0F80060083DFEFB04147B@SYS.CenSoft.COM>
: The low level screen device font functions has a *way* to constrained
interface
: to do proper text handling.
:
Yep. It was quick, and it allowed Microwindows to stay
very small by basically treating text as bitmaps, and using
existing entry points (Drawpixel) to draw any color text,
with or without background.
Further, when the in-core font structure was developed,
it took just the basic informationm, without ascent or
descent values, and stuck it into ram.
I've got no fundamental problem with enhancing text
output quite a bit, but I'd like to try to keep it small
for people that don't care as much, while still allowing
alot of functionality for those that can. I'll comment on
this following:
: Some of the problems include:
:
: - GetTextBits() doesn't support returning ascent or descent values.
We might want to agree on some additional "basic" values that
could be in every font, and add them.
: - No support (or easy way of faking) kerning or ligatures.
: - No support for drawing multiple characters at a time for font
renderers
: that support it.
This is definitely a speed issue. High speed text rendering will
require this. Perhaps the current low level api should be extended
for strings now, instead of a single character. This, though, complicates
the internationalization storage format (UTF-8 vs UNICODE)?
: - No easy way of adding features like anti-aliasing.
This could very easily be added as a g_antialias flag, much like
the g_usebackground flag. In a future version, I wanted to have
all these global flags placed in the GC structure, and kept
per GC, rather than set before each window draw, as now.
: - GdText() is constrained to narrow fonts (less than 16 pixels wide?)
This is fixed with a submission I received this morning. I can
fwd it to you, but basically, convbdf changed to allow any
input text width, and the stack-based maximum bitmap size
was quadrupled, allowing characters up to 48 bits wide. (this
is very easily changed)
: - No support for requesting font widths for scalable fonts.
I assume you mean that you want to have the system scale
a font to a specific height/width?
:
: Possible solution:
:
: I suggest to add two calls modelled after GdText() and GdTextSize() to the
: screen driver, and only use the generic GdText() and GdTextSize() for
bitmap
: fonts...
This presents some big issues, although it's generally a good idea.
First, how will the low level GdText actually output it's dots? If
it uses psd->DrawPixel and other psd-> routines, then it's probably
not a big problem, except for the clipping. Now, we could add
the clipping routines to call as additional psd-> routines, so they
could be up-called by the low level driver. My biggest concern
is that the low-level driver try to bypass the psd-> routines when
drawing. If this happens, then you just broke all offscreen drawing
and blitting... and we can't do that.
:
: At the same time, being able to set a flag to determine whether or not you
: want antialiasing *if provided* by the font renderer would be nice :-) It
: is trivial to implement basic antialiasing with T1lib (allthough it will
: probably be slow ;)
Add g_antialias to the devdraw.c globals and have another
SetGC call to set/unset it. This value can be passed to the
low level drivers.
:
: It would be nice to support setting other flags too, like requested font
size,
: slanting, modes (italics, bold, underline, overline, strikethrough).
Whether or
: not the renderer or font supports the misc. modes could be indicated via
: a query functions (which will *not* be something I write until I've got
the
: actual rendering with T1lib working).
Strike my above comment. Perhaps we need a "standard" font
description structure, that includes things like height, width,
slanting, modes, character set, antialias, etc. Then, this structure
is filled in with defaults and possibly modified by other SetGC
calls, and passed to _every_ font routine, instead of just a font
number. So essentially a font number (handle) can be used
to dereference one of these structures.
:
: I'm ready to write it, including an implementation that uses T1lib instead
: of bitmap fonts, but I'd like some feedback first ;) I'll provide compile
: time options to turn all of the T1lib support off, of course.
Cool. Take a shot at it.
Regards,
Greg
