Subject:
RE: Fonts revisited
From:
"Vidar Hokstad" ####@####.####
Date:
20 Jan 2000 14:59:41 -0000
Message-Id: <20000120150054.30721.qmail@mail.relight.com>
On Wed, 19 Jan 2000 13:38:18 -0700 Greg Haerr ####@####.#### wrote:
>: 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.
This would help, but wouldn't solve all the issues with libraries like T1lib,
since we would still loose the (very good) support for ligatures and kerning
etc., that improve rendering quality a lot.
>: - 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)?
I suggest that GdText() is changed to use a low level function for drawing
strings in whatever encoding the font uses, and that any i18n support is
added in GdText() or above, so that the low level function doesn't have to
bother about those issues at all.
>: - 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.
That isn't the main issue. The main issue is that GetTextBits() return
a monochrome bitmap, while antialiasing with 2x2 or 4x4 subsampling require
either 5 or 17 colors. I got around this rewriting GdText() to not use
GetTextBits()... See below.
>: - 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?
I want the font renderer to scale it *if it supports it*. Whether anyone
wants to support scaling for bitmap fonts or not is another issue ;)
>: 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.
I suggest that we require the low level renderer to use the psd->*()
functions or the Gd*() functions. My T1lib support now uses GdArea()
(since I use antialiasing, and T1lib can return something that works
with GdArea(), that was the easiest ;)
>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 agree. We need to sets of attributes: The font attributes, which include
things like whether it's fixed or not, what size it has (if it isn't scalable),
whether it is a normal, bold, italics etc. font (some fonts come in separate
versions for each style), and the font family. In addition we need the current
rendering parameters, which ought to include the scaling factor (if a scalable
font), the current style, etc. The latter set could go in the GC.
We then need a function to query, with wildcards, for fonts matching a specific
set of font properties.
>: 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.
I have, and I can assure everyone that it looks *great* - the antialiasing
makes the fonts look much better than it does with my X Windows setup :)
I'll clean it up a bit, and make a patch available.
Regards,
Vidar
