Subject:
Re: Scalable font support ...
From:
"Greg Haerr" ####@####.####
Date:
15 Mar 2000 22:57:35 -0000
Message-Id: <04f901bf8ed1$1321e240$3017dbd0@censoft.com>
: Agree.
: T1lib and freetype should be easily removable from microwindows for those
who
: don't want them ...
Will do. I'm going to add freetype tonight.
Currently, my plan is to have only a single font renderer compiled in.
We could later add support for the older compiled in fonts _and_
a t1 or freetype. But that's rev 2
:
:
: How & when would you load font files then ? Through a "database" text
file
: mapping IDs, names and font files ?
I propose something simple. (Isn't that what I always propose on this
list?)
We pass a string identifier in GdSelectFont. This string can be descriptive
or not, but it's used to just as a string descriptor from applications
programs
to the lower level, where the lower level can do whatever it wants. The
current
defines FONT_DEFAULT_GUI, can change from
#define FONT_DEFAULT_GUI 3
to
#define FONT_DEFAULT_GUI "defaultgui"
and be strcmp'd at the lower level to work.
Other strings would be parsed according to the font engine
that is loaded. So "times" could either directly load "times.ttf" for
truetype, or "times.afm" for T1. The flags word would
also be checked to for italic/bold, and possibly come up with
other filenames to load. Ideally, the font engine enumerates all fonts
that might match, gets their hdr data, and then loads the one it feels
is the best match.
In addition, in rev 2, we support a separate fontalias file that
gives more specific instructions to a font engine regarding this
string name. With a table like this:
Times bitstream-*-Times-12-*-x-x
etc
The font engine could translate times to bitstream of a certain size, etc.
In rev 1, we keep it simple, and the coder specifies the string name
and size that gets him the font desired, with the included font engine.
:
: I agree. I understand that in your case you can't do that since a web page
can
: come up with any/many font faces.
: But in my case, I know that I will use, say, only 3 font files in the
: application. So I can load these fonts at boot time without any speed cost
...
: See ?
Loading a font at "boot" time is equivalent to executing a call
to GrSetFont or GdSelectFont with the desired font parms, and never
releasing it.
:
: With truetype fonts, we could use what is called "the postscript name"
embedded
: in the file to name the font. But since you abstract the font technology
behind
: that, what would happen if you have, say, times.ttf AND times.pfb in the
font
: path and you specify GdSelectFont("Times" ...) ?? Will it choose the
truetype
: one or the postscript one ? And where would you take the font name if the
font
: is a bitmap font ?
In rev 1, we get only 1 font engine, so the problem goes away.
:
: I'm curious how you would handle font "names/family" instead of font
filenames
: ....
:
: Also, in truetype technology, stuff like bold and italic specify different
font
: files, not just different font rendering. Ex: times.ttf timesb.ttf,
timesi.ttf,
: timesbi.ttf respectively for times normal, times bold, times italic, times
: bold-italic .... It can't be properties of the same font name ... You have
to
: change the font file each time... If you don't handle font
loading/unloading by
: hand in the app. , it could mean a real mess for the middle-layer engine
in
: managing font filenames, the way you specify it ...
Martin, do you have code for Freetype to enumerate TTF files and get
their hdrs? I see this as the answer to this.
Regards,
Greg
