On Tue, 17 Sep 2002, Maurice LeBrun wrote:
> Here's the list with descriptions after I tried them all, sorry for any
> inaccuracies, I'm not a typographer. :)
> #FONT_TEST=arib____.ttf # bold script
> #FONT_TEST=arir____.ttf # roman script
> #FONT_TEST=chvor___.ttf # double-stroked
> #FONT_TEST=chvr____.ttf # bold roman
> #FONT_TEST=cogb____.ttf # bold sans serif small caps
> #FONT_TEST=cogr____.ttf # sans serif small caps
> #FONT_TEST=helb____.ttf # bold sans serif
> #FONT_TEST=helbi___.ttf # bold italic sans serif
> #FONT_TEST=helcb___.ttf # bold compact sans serif
> #FONT_TEST=helcbi__.ttf # bold compact italic sans serif
> #FONT_TEST=helci___.ttf # italic compact sans serif
> #FONT_TEST=helcr___.ttf # roman compact sans serif
> #FONT_TEST=heli____.ttf # italic sans serif
> #FONT_TEST=helr____.ttf # roman sans serif
> #FONT_TEST=starbats.ttf # bogus
> #FONT_TEST=starmath.ttf # bogus
> #FONT_TEST=timb____.ttf # roman bold
> #FONT_TEST=timbi___.ttf # italic bold
> #FONT_TEST=timi____.ttf # italic
> #FONT_TEST=timr____.ttf # roman
> I'm providing this info here since RH 7.3 will probably be a good "reference"
> system for at least the next year or so.
Thanks, Maurice, for this additional information and for your changes to
gd.c and plfreetype.c. Here are some additional comments/questions.
(1) My apologies for not looking at the font logic more thoroughly. When I
first tested this I just set up the defaults for my Debian system
(first-tester perquisite, ;-)) and it worked immediately (much to my
amazement since I know very little about freetype or fonts), and I never
actually tried the environment variable approach.
(2) Now that I have looked at the logic, I believe it needs changing some
more. I think Joao's system may be typical; a "parent" path to get to the
area where fonts occur with subdirectories/font files you would like to try.
The current logic (once some additional bogus logic is fixed) says if there
is a slash *anywhere* in the font file environment variable than treat it as
a complete path plus file name and ignore the font path altogether. Instead,
at least for the Unix side of things I would prefer to concatanate the font
path and font name string *always* except for the one narrow exception where
there is a *leading* slash on the font name. This way you can comfortably
and flexibly deal with subdirectories in the font name, but if you really
want to specify absolute path+font file name, you are allowed to do so.
Does everybody here thinks this is a good idea for the Unix/Linux side of
things? Andrew, would you chip in here with what you would like to do on the
DJGPP/ MSDOS side of things? Also, Andrew, your code commentary suggested
you could specify font names from the command line. Would you confirm
that is no longer the case (which I think is a good thing since font names
are so long)?
Assuming we are in agreement on conditions for concatanation with the path
(at least on the Unix/Linux side) the code commentary should be
appropriately changed. Furthermore, I think the current Unix + DJGPP +
MSDOS logic is still completely bogus since FT->font_name[i] doesn't have an
assigned value when it is checked!
So I would like to replace
if ((strchr(FT->font_name[i],'/')) ||
if ((strchr(a,'/')) ||
if (strchr(a,'/')!=NULL && *strchr(a==0)
Note, I am right at the bleeding edge of my C skills here about dealing
with pointers for the
if (strchr(a,'/')!=NULL && *strchr(a,'/')==0)
statement so please correct that if wrong. The point is that test should
succeed only if there is a leading "/" for the environment variable string,
a. The only thing I have done to the DJGPP and MSDOS logic is replace the
FT->font_name[i] which has not been assigned a value, yet with the
environment variable string, a.
(3) What is the Unix standard for file name length when you are potentially
dealing with the complete path + file name? I am uncomfortable with the
small (80-character) size of FT->font_name at the moment, and would like to
change it to something much larger and preferably the standard if somebody
could tell me what that is.
(4) It is probably obvious to everybody at this point, but Maurice's script
was just to test fonts. For production use, the various font-name variables
would normally point to *different* fonts to define a mapping between
the five PLplot font slots and any particular TrueType font you choose.
Here is Andrew's code commentary on this as well as a comparison with what is
currently done with ps.c.
* Next we go through and fill out the FT->font_name entries with
* values for the four possible "cfont" settings. The plplot documentation
* defines these a little differently from the PS.C driver:
* Font Plplot name ps.c name plfreetype ms-dos/unix
* ---- ----------- --------- -----------------
* 1 normal "Times-Roman" arial
* 2 roman "Times-Roman" times
* 3 italic "Times-Italic" times-italic
* 4 script "Helvetica" comic
* 5 greek symbol
* Under plplot, the "normal" font is actually a sans-serifed font, while
* ps.c defines it as times-roman, a serifed font. For the freetype
* implementation I will define sans-serifed font, arial.
Here is the list of truetype fonts on my Debian system. These were picked
up automatically from the MS font site (before it shut down, although there
is a replacement now at http://corefonts.sourceforge.net/)
Some of those obviously have RH7.3 counterparts, but for some reason there
doesn't seem to be a one-to-one mapping between the two. (I don't
understand this since the source, the free MS core fonts, should presumably
be the same in both cases.) For example, RH7.3 has Helvetica, but I don't,
and I have some comic fonts, but RH 7.3 does not. Are they equivalent? I
also notice that neither my system nor RH 7.3 have symbol fonts so that
leaves the question of the best font to plug into the PLplot greek font
slot. Any ideas?
Maurice, I was glad to see your enthusiasm for the PLplot freetype interface
to fonts. There are still some obvious problem areas that need to be worked
out (e.g., the font selection code problems discussed above as well as the
current inability to rotate the fonts (try the -ori 0.2 argument to get a
spectacularly wrong-looking example). Nevertheless, I am equally
enthusiastic about the potential of this code and would like to see its use
spread from gd.c to other bitmap drivers. For instructions on how to make
the appropriate driver changes, see