[Plplot-devel] TrueType font configuration at build and run time for aqt.c

[Alan W. I. <ir...@be...>]

Per, I am changing the subject line to something more appropriate.  Comments
in context below.... Alan

On 2005-04-21 18:37+0200 Per Persson wrote:

> I noticed the following paragraph in the release notes:
> The driver is unicode-enabled, however it currently only supports the
> default OS X fonts which are not TrueType.
>
> That statement might be a misinterpretation of a comment I made some time 
> ago, let me try to clarify what I meant.
>
> I recommended that the driver only use the default fonts, by which I the 
> fonts that come preinstalled with OS X and thus are guaranteed to exist.
>
> AquaTerm, and hence the driver, support any font installed on OS X which may 
> be in a number of different formats including, but not limited to, TrueType. 
> BTW, TrueType was developed by Apple (and to some extent MS) in the 80s. 
> Sadly, while OS X is fully unicode aware, not all font families support the 
> full range of glyphs, particular the common ones such as Helvetica, Times and 
> Courier.

It is good that aqt.c has the possibility of TrueType fonts since they tend
to have a much richer set of characters than postscript fonts.  As a telling
example of this, compare results for ps.c (and probably aqt.c although I
don't have access to it) on example 23 with what is possible with gd.c
devices such as png that have access to TrueType fonts via plfreetype.c (See
http://plplot.sourceforge.net/examples/demo23.php for png results.) The
first 4 pages of that example are specifically optimized for type 1
postscript fonts so ps.c does well there, but as you get beyond those, there
are a lot of symbols missing compared to what is available for the TrueType
fonts.  And that example just scratches the surface of what is possible with
TrueType.  For example, with TrueType fonts you are also able to do a
variety of languages such as in
http://plplot.sourceforge.net/examples-data/demo24/x24.01.png.

As I see it, the current problem with aqt.c is it follows what is done for
ps.c and hard-codes the font names.  Furthermore, because they are
hard-coded you are forced to go with the lowest-common-denominator approach
(postscript fonts). But ps.c is a special case where there is not a lot of
choice other than postscript fonts (at least until Rafael is able to
implement his TrueType on-the-fly conversion idea for ps.c).

To increase flexibility, I think it would be better for aqt.c to follow the
font configuration model used by plfreetype.c.  That would allow your users
to ./configure the fonts (with default lowest-common-denominator postscript
font names but with TrueType fonts allowed for those users that have them
installed). The build-time font configuration would need to modify cf/aqt.ac
to do this following what is done for fonts in cf/plfreetype.ac.  Also, to
increase font flexibility at run time (as opposed to software build
configuration time) you might want to use environment variables (as we do
with plfreetype.c) to allow users to select fonts that are different from
the ones that are build-time configured.

Anyhow, that is my $0.02 worth on how Hazen or you could proceed to make the
TrueType fonts both build-time and run-time configurable for aqt.c when the
user happens to have them installed.  I think the results would be well
worth the effort.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________