[Gnome-print] Re: Device independent string output - font api thoughts
- From: Liam Quin <liam holoweb net>
- To: gnome-devel-list gnome org
- Cc: gnome-print helixcode com
- Subject: [Gnome-print] Re: Device independent string output - font api thoughts
- Date: Fri, 23 Jun 2000 08:43:41 -0400
I have paper notes on a font api, but here are a few quick thoughts...
iterators with callbacks can work well, e.g.
foreachGlyphInString(
gfont_instance initialFont,
gdevice_context context,
string theString,
int nChars,
font_status (* perGlyphFunction)(
font_instance,
context,
string,
current_position_in_string,
relative_x,
relative_y,
glyph,
void **argpp,
void *resultp
),
void *arg
);
where the callback function returns a font_status each time,
something like this:
enum {
error = 0, /* catch common programing error */
continue, /* continue processing with the next glyph */
stop, /* finished processing */
detatch /* continue processing but don't do callbacks */
}
The function can replace the arg by changing the pointer;
resultp is used to return a status code to the caller of
foreachglyph; if no status code was returned, 0 is used.
You can then use this api to do rendering of a word, or to
do hit detection, or word breaking. If you are doing
l e t t e r s p a c i n g , you can add (space * position_in_string)
to the x coordinate each time before rendering, so the underlying
library doesn't need to know about that.
I called it initialFont because there's no reason in principle
why it can't change partway through -- e.g. you could have a
parallel array of string offsets for font changes, or you could
maybe set font attributes such as "relative italic" or "small caps"
part way through.
My goal here is to hide the character-sequence to glyph-sequence
processing as much as possible, so that an OpenType or GX font
that has that information inside it can be used with the same code
that uses a Type 1 font where it's external, for example. The
device context argument might contain information on the target
device, or that might not be necessary if you use the "makefont"
model (ala PostScript) in which you make a concrete font instance
for a given (device, ppem, font-transformation-matrix) combination.
Sorry, this was longer than I expected, and I don't know how
helpful it will be, very much a first cut for one small part
of an api.
Ankh / Lee
--
Liam Quin - Barefoot in Toronto - liam@holoweb.net - http://www.holoweb.net/
Ankh on irc.sorcery.net http://valinor.sorcery.net/
Co-author, The XML Specification Guide, Wiley, 1999
Forthcoming: The Open Source XML Database Toolkit
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]