Subject:
Re: Scalable font support ...
From:
"Greg Haerr" ####@####.####
Date:
15 Mar 2000 20:45:47 -0000
Message-Id: <043401bf8ebe$a803b950$3017dbd0@censoft.com>
: A void * is probably a bad idea in a user API. If we need a struct, it
: will have to contain all (usefull) information for all fonts supported.
: Maybe it should have a bitfield for capabilities, or at least a well
: defined set of values that indicate that the value is N.A. ?
I will work on an api for this for 0.88pre4, available soon. I agree
that we shouldn't use a void *, but instead am leaning towards Martin's
original suggestion that we have GdSetFont* routines to set parameters.
For items that could work as a bitset in a flag, like kerning and
antialiasing,
perhaps a flag word with GdText is the way to go. I'm trying to keep
the font api and nanox protocol down in size, rather than having
a new opcode for every possible feature. Then if we want to support
another binary feature for fonts, we just or in another flag.
This would leave only the following for new functions:
G[rd]SetFontSize (I implemented this last night)
G[rd]SetFontRotation
and the following flags:
MWTEXT_KERNING
MWTEXT_ANTIALIAS
:
: Personaly I'd like to see a set of functions that hides all the
: details as much as possible and provides a set of functions
: suitable for the applications no matter what kind of
: font we are using (The new font API should be able to handle the
: old bitmapped fonts as well, for small systems BTW)
Agreed
:
: Thanks, this is good news!! How about the min/max macros - can we
: toss'em out too? :-)
Sure - have they caused you trouble? What else?
:
: > : void GdFontSetPath(char* path)
: > : FONTID GdFontLoad(char* filename)
: > : void GdFontUnload(FONTID font)
:
: This is a kind of administration that should or could be
: automatic, as a client app don't want to mess around with
: details like path/file-names (think of portability
: between different architectures). I don't want *my*
: applications to have to do this, at least.
I agree that the application shouldn't load/unload fonts,
but instead specify by name and other info.
:
: You may want to include stretching of fonts for the
: esthetically bewildered...
That's what StretchBlt if for, I'm going to add that one day soon.
:
: The 'SetAngle' function; will it specify slanting of
: individual characters, or rotation for the entire
: rendered string? (I could use all of 90, 180 and 270
: degrees rotation - also handeling anything inbetween
: is acceptable too:-).
I think it should work for the entire G[rd]Text string...
: For selecting fonts, how about:
:
: PMWFONT = GdSelectFont("bitstream","Times","bold","italic",16,...);
How about
PMWFONT = GdSelectFont("Times", height, flags, ...)
the flags param takes bold, italic, underline
Do we really want a separate family from facename? I like your
idea that we have a set of "known" facenames that could ultmately
be aliased in a setup file later. If that parameter is specified, it
is used to select the font. Then the other parms are used to size
and shape it. If the facename isn't specified, then the other
parms are used to select a font as well.
: I will work this out with Greg, and what will probably happen is that
: there will be GdArea support that the font renderer can call for
: optimized operations. Or maybe there will be a different version
: that supports alpha transparency.
Yes
Having to set up a memory
: target for each rendered text is a bad idea IMHO, so I'd like to
: continue to use GdArea for this.
Well, there is a subtle reason why I added two PSD's to the
blitters: with some screen devices, now including both X11 screen
driver and the VGA 4 planes driver, it isn't really about moving
pixels, but instead "areas" on a screen that may not be memory mapped.
Having a second PSD allows an arbitrary driver to be developed, and
in fact, this is required for X11 and VGA 4 planes.
Having said that, I think that the Blitters could call the equivalent of the
GdArea call in the lowest level, IF they were running pixel-to-pixel copies.
This would allow an upper level routine to call the lowest
part of the blitter directly without having to create another PSD.
I'll work on this.
It also performs clipping very
: nicely. It is the psd->DrawArea that needs to be merged with
: the blitter at a low level, agreed?
Yes.
: > My idea is that it would call a screen-driver dependent font drawing
: > routine, and pass the PMWFONT to that driver, along with the
: > struct with the font characteristics.
:
: Where would clipping be done, then?
I'm thinking of rewriting GdArea so that it's almost exactly like
GdBlit, except that it uses a void * instead of a PSD for the second
parameter.
It will also perform all clipping. I will remove ALL the translation
garbage,
and put that into another routine, that the caller can call BEFORE GdArea,
if translation is required. In this way, we the best of all worlds. We can
run fast, we can have translation (slow) if we need it, and we can share the
lower level blitter with the area draw routines.
The next step for the screen driver will probably be three new "area"
routines
that are basically sub-blitter entry points:
CopyBit, TransparentBlit, AlphablendBlit
These will want to be implemented for all screen drivers bitsperpixel. I
will
enlist your help to get them all working, after I get the structure done ;-)
Regards,
Greg
