Subject:
RE: Scalable font support ...
From:
Rod Boyce ####@####.####
Date:
16 Mar 2000 01:06:25 -0000
Message-Id: <9DCCE20055ACD311BBE200104B08D83422FC96@EXCHWENZ01>
This is a great Idea but I would also like to see the current system to stay
as well.
My bend on this is for an embedded system. EG keep it as small as possible.
The embedded stuff I do does not generally have a disk drive of any type.
Perhaps a font management system similar to the current device driver system
would be a good idea as then by changing which font system is compiled in
will change how the font manager system works. Extra thin for people with
an embedded (small PDA) fetish other methods for everybody else.
This is just my 0.2 cents worth.
Regards,
Rod Boyce
-----Original Message-----
From: Greg Haerr ####@####.####
Sent: Thursday, 16 March 2000 11:52
To: Martin Jolicoeur; Morten Rolland
Cc: ####@####.####
Subject: Re: Scalable font support ...
: 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
---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail:
####@####.####
