Re: [Plplot-devel] gd driver and dlopen() flags

[Andrew R. <aro...@ya...>]

At 12:24 PM 17/09/02 -0700, Alan W. Irwin wrote:

>(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?  

The combination of enviro-variables, and concatenation of paths and file
names, together with the logic of deciding if you had an absolute path or
not, was just *really* quick coding to get it "out the door" and into
testing - I always envisaged that it would change once people started
experimenting with it. I was more surprised than Alan when the original
code worked first go, considering I wrote it in a total unix-vacuum !

The way I originally saw things *ultimately* heading, and it can still be
subject to change/debate, was to have the font path "searchable", so
multiple directories could be specified with the standard path separator,
whatever that might be. For example, under DOS it's ';', so the path
searched for include files on my machine looks like:

/;CPLUS_INCLUDE_PATH%%DJDIR%/lang/cxx;%DJDIR%/include;%GRX20%/include;%PLPLO
T_HOME%/include;%FREETYPE_INC%

Is it ':' in unix ?

>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)?

It would make life a lot easier, which is why I didn't do it originally,
and had not gotten around to doing it yet. I just thought it might be a
little quicker/easier for the end-user for making changes to the fonts than
messing around with the environmental variables all the time. I have no
attachment to it, so wont miss it if it goes. 


>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?

It's very unfortunate that micro$oft took their core fonts of the web, and
even more disappointing that there isn't a standard symbol font on linux.
But don't forget, freetype reads a lot more than just truetype fonts - it
also does type1, type42 etc... and I think a free type1 symbol font is
included by adobe in acrobat, so that might be a potential source perhaps ?

>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
>http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4.3
/freetype-notes.html.

Just a real brief comment here so as to encourage people adding freetype
support. Some of the current problems with the GD driver appeared as a
result of the palette manipulations to get the anti-aliased freetype fonts
working. If you could "make do" with non-anti-aliased freetype fonts,
adding freetype support to drivers is *much* simpler, if not trivial.

-Andrew