plplot-devel — Technical discussion about PLplot development

[Plplot-devel] dyndrivers == fast links

[Maurice L. <mj...@ga...>]

Doing extensive plplot development in the dyndriver model for the first time,
I really notice the fast link times.  I can do "make cdemos" after every
change to the library and have it finish in ~1 sec.  Very cool.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

[Plplot-devel] precision problems in c_plmtex()

[Maurice L. <mj...@ga...>]

In writing the new store-strings-as-strings-in-plmeta capability, I came
across some code in plmtex() that has been giving me fits.  Not only does it
have precision problems, but it's inconsistently written, so that under some
circumstances a quantity is rounded, and under others, it's truncated.

The big picture: to really get the string store capability (in plmeta)
correct, I need to write it out at the normalized device coordinate level,
i.e. (floating point) bounds from 0 -> 1.  Only at the render level is
it converted to physical (mm) and then device (pixel) coordinates.  So
my task was to generalize the monster if-else in plmtex() as well as the
code in plptex, plxytx, plztx and insert a new layer just above plstr()
that does all its stuff in normalized device coords.

Aside: this is a good prototype for things to come, since we eventually
want to do more things at the normalized device coordinate level.

So it looks like fixing plmtex() is going to involve some off-by-one pixel
changes to the output, by what I'm seeing in the ps output.  Just a heads-up
b/c I know others (especially Alan) will be affected by this change.  I'll try
to time it with another change I have planned that may affect low order bit
precision as well.

A look at the if-else in plmtex() reveals:

    if (plP_stsearch(side, 'b')) { 
        vert = 0; 
        xdv = plsc->vpdxmi + (plsc->vpdxma - plsc->vpdxmi) * pos; 
        ymm = plP_dcmmy(plsc->vpdymi) - disp * chrht; 
        x = plP_dcpcx(xdv); 
            ^^^^^^^^^^^^^^^  rounded to PLINT
        refx = x - shift * plsc->xpmm; 
                   ^^^^^^^^^^^^^^^^^^^  precision problem! truncated, not rounded
        y = refy = plP_mmpcy(ymm); 
    } 
    else if (plP_stsearch(side, 't')) { 
        vert = 0; 
        xdv = plsc->vpdxmi + (plsc->vpdxma - plsc->vpdxmi) * pos; 
        ymm = plP_dcmmy(plsc->vpdyma) + disp * chrht; 
        x = plP_dcpcx(xdv); 
            ^^^^^^^^^^^^^^^  rounded to PLINT
        refx = x - shift * plsc->xpmm; 
                   ^^^^^^^^^^^^^^^^^^^  precision problem! truncated & added
        y = refy = plP_mmpcy(ymm); 
    } 
    else if (plP_stindex(side, "LV") != -1 || plP_stindex(side, "lv") != -1) { 
        vert = 0; 
        xmm = plP_dcmmx(plsc->vpdxmi) - disp * chrht; 
        ydv = plsc->vpdymi + (plsc->vpdyma - plsc->vpdymi) * pos; 
        x = plP_mmpcx(xmm); 
            ^^^^^^^^^^^^^^^  rounded to PLINT
        refx = x - plP_mmpcx(shift); 
                   ^^^^^^^^^^^^^^^^  rounded!  Both inconsistent with the
above code AND a precision problem!  Because you should add first, then round,
rather than the other way around.

        y = refy = plP_dcpcy(ydv); 
    } 
    else if (plP_stindex(side, "RV") != -1 || plP_stindex(side, "rv") != -1) { 
        vert = 0; 
        xmm = plP_dcmmx(plsc->vpdxma) + disp * chrht; 
        ydv = plsc->vpdymi + (plsc->vpdyma - plsc->vpdymi) * pos; 
        x = plP_mmpcx(xmm); 
            ^^^^^^^^^^^^^^   ditto
        refx = x - plP_mmpcx(shift); 
                   ^^^^^^^^^^^^^^^^^ ditto
        y = refy = plP_dcpcy(ydv); 
    } 
    else if (plP_stsearch(side, 'l')) { 
        vert = 1; 
        xmm = plP_dcmmx(plsc->vpdxmi) - disp * chrht; 
        ydv = plsc->vpdymi + (plsc->vpdyma - plsc->vpdymi) * pos; 
        x = refx = plP_mmpcx(xmm); 
        y = plP_dcpcy(ydv); 
            ^^^^^^^^^^^^^^ rounded
        refy = y - shift * plsc->ypmm; 
                   ^^^^^^^^^^^^^^^^^^^  truncated & added
    } 
    else if (plP_stsearch(side, 'r')) { 
        vert = 1; 
        xmm = plP_dcmmx(plsc->vpdxma) + disp * chrht; 
        ydv = plsc->vpdymi + (plsc->vpdyma - plsc->vpdymi) * pos; 
        x = refx = plP_mmpcx(xmm); 
        y = plP_dcpcy(ydv); 
            ^^^^^^^^^^^^^^ rounded
        refy = y - shift * plsc->ypmm; 
                   ^^^^^^^^^^^^^^^^^^^  truncated & added
    } 

The correct way should be to add the offset (in the proper coordinate system),
then round. 

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

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

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

On Tue, 17 Sep 2002, Maurice LeBrun wrote:
> But even simpler would be:
>
> if (a[0] == '/')
>
> :)

That's too easy; C is supposed to be hard....;-)

Andrew has already made this change (plus looking for "~" at the head of the
string which I think is a good idea as well).

> 80 chars is way too short.  A limit like 1024 chars is much more appropriate.

Done.

Alan

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

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

On Wed, 18 Sep 2002, Andrew Roach wrote:

> 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[..]
> Is it ':' in unix ?

I think that is an excellent idea so please just go ahead.  In Unix/Linux it
is standard to have colon-separated paths.

Meanwhile, I have good news: your overnight (for me) change to gd.c solved
the colour problem completely.  Also, I have just made a subsequent change
so the path+fontfile name can be 1024 characters as Maurice suggested. So
the only outstanding issue I am aware of is -ori 0.1 (say) works fine for
the Hershey fonts, but does not work for freetype, yet.

> [...]It's very unfortunate that micro$oft took their core fonts of the
web[...]

It does seem to be a somewhat poorly thought-out move by MS.  It hurts their
users, and at the same time doesn't hurt Linux very much at all.  The fonts
were licensed in such a way that anybody could redistribute them freely in
unchanged form so there is at least one project at
http://corefonts.sourceforge.net/ that is doing exactly that. I suppose
there is a bit of a transition pain for Linux MS font packages to move from
using the MS web server to the new corefonts site, but such package updates
can be done pretty automatically for most distributions.

> [...]
> 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 ?

No question that fonts on Linux currently have few standards for paths or
file names. Nevertheless, suitable fonts are available on Linux; it is just
a matter of finding them.

From http://freetype.sourceforge.net/freetype2/index.html freetype
apparently supports the following font formats:

TrueType fonts (and collections)
Type 1 fonts
CID-keyed Type 1 fonts
CFF fonts
OpenType fonts (both TrueType and CFF variants)
SFNT-based bitmap fonts
X11 PCF fonts
Windows FNT fonts
BDF fonts (including anti-aliased ones)
PFR fonts
Type42 fonts (limited support)

I had never heard of "X11 PCF" before, but from
http://pfaedit.sourceforge.net/pcf-format.html we have the following
definition: "The pcf (portable compiled format) file format is a binary
representation of a bitmap font used by the XServer." So I think that means
freetype has access to *all* bitmap X fonts. For example my
/usr/X11R6/lib/X11/fonts/100dpi/ directory is filled with pcf files
including what looks like symbol files. So I forsee lots of interesting
PLplot experimentation with trying out an enormous variety of fonts going
far beyond just the truetype fonts.

Thanks, Andrew, for making this all possible.

Alan

Re: [Plplot-devel] python does not compile in suse-8.0

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

On Wed, 18 Sep 2002, Joao Cardoso wrote:

> But I didn't realize that "swig" was called in a normal build.

We want to keep generated files out of CVS so that is why our CVS users need
swig-1.3.11 (or 1.3.12 or 1.3.13).  But our ordinary users won't need it
since for the tarball release I will include the python interface files
(single and double-precision versions) generated by swig. So it's the same
deal as for the configure file generated by autoconf, and the tcl interface
files generated by perl.

Alan

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

Re: [Plplot-devel] python does not compile in suse-8.0

[Joao C. <jc...@fe...>]

On Tuesday 17 September 2002 21:01, Alan W. Irwin wrote:
> Joao:
>
> Sorry I forgot to respond to this until now.
>
> What version of swig are you using? Anything earlier than 1.3.11 will n=
ot
> work.  See the plplot-devel thread with Maurice on this, culminating in=
 his
> latest experiments with the version numbers (1.3.11-1.3.13) that curren=
tly
> work.

I'm using swig-1.3.9. That's the standard in suse-8.0, even with online=20
updates.

But I didn't realize that "swig" was called in a normal build... until I =
read=20
pkg_python.in :(

Thanks,
Joao

>
> Alan
>
> email: ir...@be...
> phone: 250-727-2902=09FAX: 250-721-7715
> snail-mail:
> Dr. Alan W. Irwin
> Department of Physics and Astronomy,
> University of Victoria, P.O. Box 3055,
> Victoria, British Columbia, Canada, V8W 3P6
> __________________________
>
> Linux-powered astrophysics
> __________________________
>
> On Mon, 16 Sep 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
> > I'm a kind of bug reporter, now :)
> >
> > Building Python modules.
> >
> > # Start fresh (--force) each time since previous build may
> > # be for an installation rather than for present plplot/tmp location.
> > python setup.py build --force --build-temp=3D"./" --build-lib=3D"./" =
--flat
> > running build
> > running build_ext
> > building 'plplotcmodule' extension
> > plplotcmodule.c:627: warning: `PySequence_Fast_GET_ITEM' redefined
> > /usr/include/python2.2/abstract.h:1004: warning: this is the location=
 of
> > the previous definition
> > plplotcmodule.c: In function `_wrap_pltr0':
> > plplotcmodule.c:663: `$1' undeclared (first use in this function)
> > plplotcmodule.c:663: (Each undeclared identifier is reported only onc=
e
> > plplotcmodule.c:663: for each function it appears in.)
> > plplotcmodule.c: In function `_wrap_pltr1':
> > plplotcmodule.c:783: `$1' undeclared (first use in this function)
> > plplotcmodule.c:783: `$input' undeclared (first use in this function)
> > plplotcmodule.c: In function `_wrap_pltr2':
> >
> > ... etc
> >
> > # rpm -q python
> > python-2.2-105
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Plplot-devel mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: AMD - Your access to the experts
> on Hammer Technology! Open Source & Linux Developers, register now
> for the AMD Developer Symposium. Code: EX8664
> http://www.developwithamd.com/developerlab
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > (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.

Agreed.  I vaguely noted that the current solution wasn't optimal, but like
you was trying to just get it working so I could play with it.  Having access
to an alternate font rendering engine is really nice, and is helping me debug
something I've been wanting to add for a long time -- storing strings as
strings in the metafile.  Then in principle you can do all kinds of cool
things with them in the renderer.

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

The second test won't ever succeed since the pointer value can't be zero.
But you could do pointer arithmetic:

if ( strchr(a,'/') && ( (strchr(a,'/') - a) == 0 ) )

(subtracting pointers is safe).  Also note it's good style (arguable but most
agree) to omit the test against NULL in the first expression.

But even simpler would be:

if (a[0] == '/')

:)

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

80 chars is way too short.  A limit like 1024 chars is much more appropriate.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] python does not compile in suse-8.0

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

Joao:

Sorry I forgot to respond to this until now.

What version of swig are you using? Anything earlier than 1.3.11 will not
work.  See the plplot-devel thread with Maurice on this, culminating in his
latest experiments with the version numbers (1.3.11-1.3.13) that currently
work.

Alan

email: ir...@be...
phone: 250-727-2902=09FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Mon, 16 Sep 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

>
> I'm a kind of bug reporter, now :)
>
> Building Python modules.
>
> # Start fresh (--force) each time since previous build may
> # be for an installation rather than for present plplot/tmp location.
> python setup.py build --force --build-temp=3D"./" --build-lib=3D"./" --fl=
at
> running build
> running build_ext
> building 'plplotcmodule' extension
> plplotcmodule.c:627: warning: `PySequence_Fast_GET_ITEM' redefined
> /usr/include/python2.2/abstract.h:1004: warning: this is the location of
> the previous definition
> plplotcmodule.c: In function `_wrap_pltr0':
> plplotcmodule.c:663: `$1' undeclared (first use in this function)
> plplotcmodule.c:663: (Each undeclared identifier is reported only once
> plplotcmodule.c:663: for each function it appears in.)
> plplotcmodule.c: In function `_wrap_pltr1':
> plplotcmodule.c:783: `$1' undeclared (first use in this function)
> plplotcmodule.c:783: `$input' undeclared (first use in this function)
> plplotcmodule.c: In function `_wrap_pltr2':
>
> ... etc
>
> # rpm -q python
> python-2.2-105
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

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

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

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

#ifdef DJGPP
            if ((strchr(FT->font_name[i],'/')) ||
                (strchr(FT->font_name[i],'\\')) )
#elif MSDOS
            if (strchr(FT->font_name[i],'\\'))
#else
            if (strchr(FT->font_name[i],'/'))
#endif
                strcpy(FT->font_name[i],a);

by

#ifdef DJGPP
            if ((strchr(a,'/')) ||
                (strchr(a,'\\')) )
#elif MSDOS
            if (strchr(a,'\\'))
#else
            if (strchr(a,'/')!=NULL && *strchr(a==0)
#endif
                strcpy(FT->font_name[i],a);


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

Andale_Mono.ttf              Impact.ttf
Arial.ttf                    Times_New_Roman.ttf
Arial_Black.ttf              Times_New_Roman_Bold.ttf
Arial_Bold.ttf               Times_New_Roman_Bold_Italic.ttf
Arial_Bold_Italic.ttf        Times_New_Roman_Italic.ttf
Arial_Italic.ttf             Trebuchet_MS.ttf
Comic_Sans_MS.ttf            Trebuchet_MS_Bold.ttf
Comic_Sans_MS_Bold.ttf       Trebuchet_MS_Bold_Italic.ttf
Courier_New.ttf              Trebuchet_MS_Italic.ttf
Courier_New_Bold.ttf         Verdana.ttf
Courier_New_Bold_Italic.ttf  Verdana_Bold.ttf
Courier_New_Italic.ttf       Verdana_Bold_Italic.ttf
Georgia.ttf                  Verdana_Italic.ttf
Georgia_Bold.ttf             Webdings.ttf
Georgia_Bold_Italic.ttf      ms-fonts
Georgia_Italic.ttf

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

Alan

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

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

On Tue, 17 Sep 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > I confirm there is a colour problem ...
>
> Hey, how does one view multiple-page png files under Linux?  Neither xv nor
> gqview seem to support it.

png is only a single-page format as far as I have ever been able to determine
from the documentation of the standard.  Thus, you have to use familied files
to see all the PLplot pages associated with a given example, e.g.,

./x08c -dev png -fam -fflen 2 -o test.png

(no -fsiz is necessary).

kview definitely supports viewing multiple files, e.g.,

kview test.png.??

and I presume the same command-line syntax would work for xv and gqview.

Alan

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

[Joao C. <jc...@fe...>]

On Tuesday 17 September 2002 03:35, Alan W. Irwin wrote:
> On Tue, 17 Sep 2002, Joao Cardoso wrote:
> > There is something strange with the last x08c.c that I have just cvs
> > commited; colors look strange under the png driver, either with -drvo=
pt
> > optimize or not. But I thing that it has nothing to do with the macro
> > definition.
>
> I will look at this.
>
> > It looks like freetype does not find the specifyed fonts. Can anyone =
give
> > me a hint?
>
> You have to set some environment variables to inform plfreetype where t=
he
> fonts are; I know it is clumsy, but it should work for now until we can=
 get
> better PLplot freetype font finding under Linux (perhaps with Keith
> Packard's fontconfig if/when it becomes standard part of distros?).
>
> The environment variables are mentioned in plfreetype.c.  The relevant
> names are largely self-documenting and are
>
> PLPLOT_FREETYPE_FONT_PATH (trailing slash required)
> PLPLOT_NORMAL_FONT
> PLPLOT_ROMAN_FONT
> PLPLOT_ITALIC_FONT
> PLPLOT_SCRIPT_FONT
> PLPLOT_SYMBOL_FONT
>
> I have the standard X11 fonts, including type1 and trutype fonts:
> > #: xset q
> > ...
> > Font Path:
> > ...,/usr/X11R6/lib/X11/fonts/TTF,/usr/X11R6/lib/X11/fonts/truetype,/u=
sr/X
> >11R6/lib/X11/fonts/Type1,/usr/X11R6/lib/X11/fonts/URW,...
>
> So I believe you could set PLPLOT_FREETYPE_FONT_PATH to
> /usr/X11R6/lib/X11/fonts/ and then set the other names to TTF/Arial.ttf=
 (or
> whatever is appropriate for your system for normal, roman, italic, scri=
pt,
> and symbol fonts).  Please let us know if that works for your situation=
=2E

Thanks, it works (after I changed in plfreetype.c, around line 518

#elif MSDOS
        if (strchr(FT->font_name[i],'\\'))
#else
=09  //if (strchr(FT->font_name[i],'/')) ??? jc: what ???
=09  if (!strchr(a,'/'))
#endif

I have set=20

echo $PLPLOT_FREETYPE_FONT_PATH $PLPLOT_NORMAL_FONT
$PLPLOT_ROMAN_FONT $PLPLOT_ITALIC_FONT $PLPLOT_SCRIPT_FONT
$PLPLOT_SYMBOL_FONT

/usr/X11/lib/X11/fonts/TTF/
arial.ttf
times.ttf
timesi.ttf
comic.ttf
symbol.ttf

Now, with this techology in plplot, we need to discuss how we are going t=
o use=20
it. The text/font treatment must be discussed before we all start adding=20
truetype rendering to our prefered drivers :!

Joao
>
> Alan
>
>
>
> -------------------------------------------------------
> Sponsored by: AMD - Your access to the experts on Hammer Technology!
> Open Source & Linux Developers, register now for the AMD Developer
> Symposium. Code: EX8664 http://www.developwithamd.com/developerlab
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > On Tue, 17 Sep 2002, Joao Cardoso wrote:
 > 
 > > There is something strange with the last x08c.c that I have just cvs commited;
 > > colors look strange under the png driver, either with -drvopt optimize or
 > > not.
 > 
 > I confirm there is a colour problem for the first gray scale (plotsh3d)
 > plot, but then after that as it cycles through the remaining plotfc3d,
 > plotsh3d, and plot3d plots, everything is fine.  I have given more details
 > to Andrew, and I hope he will be able to solve this colour problem for the
 > png device.

Hey, how does one view multiple-page png files under Linux?  Neither xv nor
gqview seem to support it.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

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

[Maurice L. <mj...@ga...>]

Maurice LeBrun writes:
 > #FONT_TEST=arib____.ttf 
 > #FONT_TEST=arir____.ttf 
 > #FONT_TEST=chvor___.ttf 
 > #FONT_TEST=chvr____.ttf 
 > #FONT_TEST=cogb____.ttf 
 > #FONT_TEST=cogr____.ttf 
 > #FONT_TEST=helb____.ttf 
 > #FONT_TEST=helbi___.ttf 
 > #FONT_TEST=helcb___.ttf 
 > #FONT_TEST=helcbi__.ttf 
 > #FONT_TEST=helci___.ttf 
 > #FONT_TEST=helcr___.ttf 
 > #FONT_TEST=heli____.ttf 
 > #FONT_TEST=helr____.ttf 
 > #FONT_TEST=starbats.ttf 
 > #FONT_TEST=starmath.ttf 
 > #FONT_TEST=timb____.ttf 
 > #FONT_TEST=timbi___.ttf 
 > #FONT_TEST=timi____.ttf 
 > #FONT_TEST=timr____.ttf 

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.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

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

[Maurice L. <mj...@ga...>]

OK, to play with this under RH7.3, assuming you've got the png driver built
and ttfonts-1.0-9.noarch.rpm installed:

 - copy the following script to ~/bin/pl_fontsetup
 - uncomment the line for FONT_TEST you want to see in action
 - run:

source ~/bin/pl_fontsetup; ./x01c -dev png -drvopt text,smooth -o test.png; xv test.png

(sh/bash syntax)

The last set of variable def's below (commented out) are needed before my
fixes to plfreetype.c.

#!/bin/sh 
 
export PLPLOT_FREETYPE_FONT_PATH=/usr/share/fonts/default/TrueType/ 
 
#FONT_TEST=arib____.ttf 
#FONT_TEST=arir____.ttf 
#FONT_TEST=chvor___.ttf 
#FONT_TEST=chvr____.ttf 
#FONT_TEST=cogb____.ttf 
#FONT_TEST=cogr____.ttf 
#FONT_TEST=helb____.ttf 
#FONT_TEST=helbi___.ttf 
#FONT_TEST=helcb___.ttf 
#FONT_TEST=helcbi__.ttf 
#FONT_TEST=helci___.ttf 
#FONT_TEST=helcr___.ttf 
#FONT_TEST=heli____.ttf 
#FONT_TEST=helr____.ttf 
#FONT_TEST=starbats.ttf 
#FONT_TEST=starmath.ttf 
#FONT_TEST=timb____.ttf 
#FONT_TEST=timbi___.ttf 
#FONT_TEST=timi____.ttf 
#FONT_TEST=timr____.ttf 
 
export PLPLOT_NORMAL_FONT=$FONT_TEST 
export PLPLOT_ROMAN_FONT=$FONT_TEST 
export PLPLOT_ITALIC_FONT=$FONT_TEST 
export PLPLOT_SYMBOL_FONT=$FONT_TEST 
export PLPLOT_SCRIPT_FONT=$FONT_TEST 
 
#export PLPLOT_NORMAL_FONT=${PLPLOT_FREETYPE_FONT_PATH}$FONT_TEST 
#export PLPLOT_ROMAN_FONT=${PLPLOT_FREETYPE_FONT_PATH}$FONT_TEST 
#export PLPLOT_ITALIC_FONT=${PLPLOT_FREETYPE_FONT_PATH}$FONT_TEST 
#export PLPLOT_SYMBOL_FONT=${PLPLOT_FREETYPE_FONT_PATH}$FONT_TEST 
#export PLPLOT_SCRIPT_FONT=${PLPLOT_FREETYPE_FONT_PATH}$FONT_TEST 

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

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

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > The environment variables are mentioned in plfreetype.c.  The relevant names
 > are largely self-documenting and are
 > 
 > PLPLOT_FREETYPE_FONT_PATH (trailing slash required)
 > PLPLOT_NORMAL_FONT
 > PLPLOT_ROMAN_FONT
 > PLPLOT_ITALIC_FONT
 > PLPLOT_SCRIPT_FONT
 > PLPLOT_SYMBOL_FONT
 > ...
 > So I believe you could set PLPLOT_FREETYPE_FONT_PATH to
 > /usr/X11R6/lib/X11/fonts/ and then set the other names to TTF/Arial.ttf (or
 > whatever is appropriate for your system for normal, roman, italic, script,
 > and symbol fonts).  Please let us know if that works for your situation.

Actually the logic is bogus wrt this, the sense is reversed.  I now have this
working as expected under RH7.3 and am committing my fixes.  Pretty cool stuff.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

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

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

On Tue, 17 Sep 2002, Joao Cardoso wrote:

> There is something strange with the last x08c.c that I have just cvs commited;
> colors look strange under the png driver, either with -drvopt optimize or
> not.

I confirm there is a colour problem for the first gray scale (plotsh3d)
plot, but then after that as it cycles through the remaining plotfc3d,
plotsh3d, and plot3d plots, everything is fine.  I have given more details
to Andrew, and I hope he will be able to solve this colour problem for the
png device.

BTW, that pltfc3d demo is really quite impressive. I am looking forward to
putting it up on the website once the png driver problems are straightened
out.

Yes, I like all these examples of various plots of the same 3D function
collected together in x08c.  But now there are 4 different ways to plot each
view, you might want to experiment with plssub to see if those 4 ways (mesh
plot, plotsh3d, plotfc3d, plotfc3d with mesh) could be put on 4 subpages
(plssub(2,2)) within each page.  But we could also stick with the 16 pages
we have at the moment.  It is up to you.  I will follow whatever further
changes you decide to make to x08c with the other (tcl, python, java)
interfaces to plplot when I have time.

Alan

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

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

On Tue, 17 Sep 2002, Joao Cardoso wrote:

> There is something strange with the last x08c.c that I have just cvs commited;
> colors look strange under the png driver, either with -drvopt optimize or
> not. But I thing that it has nothing to do with the macro definition.

I will look at this.

> It looks like freetype does not find the specifyed fonts. Can anyone give me a
> hint?

You have to set some environment variables to inform plfreetype where the
fonts are; I know it is clumsy, but it should work for now until we can get
better PLplot freetype font finding under Linux (perhaps with Keith
Packard's fontconfig if/when it becomes standard part of distros?).

The environment variables are mentioned in plfreetype.c.  The relevant names
are largely self-documenting and are

PLPLOT_FREETYPE_FONT_PATH (trailing slash required)
PLPLOT_NORMAL_FONT
PLPLOT_ROMAN_FONT
PLPLOT_ITALIC_FONT
PLPLOT_SCRIPT_FONT
PLPLOT_SYMBOL_FONT

I have the standard X11 fonts, including type1 and trutype fonts:
>
> #: xset q
> ...
> Font Path:
> ...,/usr/X11R6/lib/X11/fonts/TTF,/usr/X11R6/lib/X11/fonts/truetype,/usr/X11R6/lib/X11/fonts/Type1,/usr/X11R6/lib/X11/fonts/URW,...

So I believe you could set PLPLOT_FREETYPE_FONT_PATH to
/usr/X11R6/lib/X11/fonts/ and then set the other names to TTF/Arial.ttf (or
whatever is appropriate for your system for normal, roman, italic, script,
and symbol fonts).  Please let us know if that works for your situation.

Alan

Re: [Plplot-devel] New API: plotfc3d()

[Maurice L. <mj...@ga...>]

Joao Cardoso writes:
 > 
 > Hi,
 > 
 > I have cvs commited changes to plot3d.c, plplot.h and x08c.c to add a new 3d 
 > plot function, which is built upon plotsh3d() and provides magnitude coloring 
 > 3d plots.

Looks great, thanks.

 > I have also changed x08c.c to show the new capabilities. BTW x08c.c is 
 > becoming a bit tedious to see, shouldn't we shorten it?

I think it's ok.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

[Plplot-devel] New API: plotfc3d()

[Joao C. <jc...@fe...>]

Hi,

I have cvs commited changes to plot3d.c, plplot.h and x08c.c to add a new=
 3d=20
plot function, which is built upon plotsh3d() and provides magnitude colo=
ring=20
3d plots.
I have also changed x08c.c to show the new capabilities. BTW x08c.c is=20
becoming a bit tedious to see, shouldn't we shorten it?

Joao

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

[Joao C. <jc...@fe...>]

On Monday 16 September 2002 21:20, Alan W. Irwin wrote:
> On Mon, 16 Sep 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
> > I found that gdImagePalettePixel() is really a macro:
> >
> > #define gdImagePalettePixel(  im, x, y )   (im)->pixels[(y)][(x)]
> >
> > So, putting it above  gd.c:plD_gd_optimise(), makes the unknown symbo=
l
> > error to disappear, but the seg fault still happens:
> >
> > [jcard@feup] ./x01c -dev png -o po.png
> > Plplot library version: 5.1.0
> > Opened po.png
> > Segmentation fault
>
> I have now fixed this problem (but not the macro problem which I am lea=
ving
> to Andrew for final decision since I don't know whether or not that mac=
ro
> would actually work with libgd 1.8.4 with -drvopt optimise).

There is something strange with the last x08c.c that I have just cvs comm=
ited;=20
colors look strange under the png driver, either with -drvopt optimize or=
=20
not. But I thing that it has nothing to do with the macro definition.

>  But if you
> cvs update and work around the gdImagePalettePixel problem by adding th=
e
> macro, I think you will find the above problem will be gone.

Yes, its gone.
But I get warnings from freetype:

#:~/plplot/tmp> ./x01c -dev png -o po.png -drvopt text,smooth
Plplot library version: 5.1.0
Opened po.png

*** PLPLOT WARNING ***
Possible error defining one of the freetype compatible fonts.

*** PLPLOT WARNING ***
Possible error defining one of the freetype compatible fonts.

*** PLPLOT WARNING ***
Possible error defining one of the freetype compatible fonts.

*** PLPLOT WARNING ***
Possible error defining one of the freetype compatible fonts.

*** PLPLOT WARNING ***
Possible error defining one of the freetype compatible fonts.

*** PLPLOT ERROR ***
Loading a font in freetype
Program aborted

It looks like freetype does not find the specifyed fonts. Can anyone give=
 me a=20
hint? I have the standard X11 fonts, including type1 and trutype fonts:

#: xset q
=2E..
Font Path:=20
=2E..,/usr/X11R6/lib/X11/fonts/TTF,/usr/X11R6/lib/X11/fonts/truetype,/usr=
/X11R6/lib/X11/fonts/Type1,/usr/X11R6/lib/X11/fonts/URW,...

By the way, does anybody knows the (linux/X11) name of the standard 35=20
postcript fonts, the ones that *postscript* printers have by default?

Joao

>
> BTW, Andrew, I have just checked your recent changes, and eveything see=
ms
> to be fine; x08c gives good results with
> no drvopt and with
> -drvopt text,smooth,24bit and
> -drvopt text,smooth.
>
> Alan
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Tcl wierdness (was Re: [Plplot-devel] python works fine on RH 7.3)

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > I also found there was an itcl installation problem on RH7.3.  Once we
 > are on the same page with respect to the python interface, could you look
 > into that?  The error messages were:
 > 
 > no files matched glob patterns "*.tcl *.itcl *.itk *.ith *.itm"
 >     while executing
 > "glob *.tcl *.itcl *.itk *.ith *.itm"
 >     ("eval" body line 1)
 >     invoked from within
 > "eval glob $args"
 >     (procedure "auto_mkindex" line 24)
 >     invoked from within
 > "auto_mkindex . *.tcl *.itcl *.itk *.ith *.itm"
 >     invoked from within
 > "if {[catch {package require Itcl}]} {
 > 
 > # Error including Itcl -- only include tcl files
 >     auto_mkindex . *.tcl
 > 
 > I currently have no idea where this is coming from and would be most
 > interested in whether the same installation error happens on your RH7.3
 > machine.

This really shouldn't be happening -- it means there were no *.tcl files
in the installed tcl directory.  Which doesn't make sense if you have
configured tcl in (and if you haven't, this won't be run).

<shrug> oh well, I silenced the unlikely error with a catch {} and also
took the opportunity to fix a year-old item on my todo list about tying
mktclIndex to the configuration info.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] build broken

[Maurice L. <mj...@ga...>]

Jo=E3o Cardoso writes:
 > This is a good thing.
 > Can we make also a libplplotf77 library from scstubs.o sfstubs.o?

One of these days, definitely.

 > That's fine. The only missing thing is to reunify tkwin_common.c and=
=20
 > tkwin.c, I believe.

I was going to do this, along the same lines as the reunified xwin.c an=
d
xwin_common.c.  Unfortunately it appears to be a bit more work than the=

former, so since the current situation is reasonable, I decided to leav=
e it
as-is for now.

--=20
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (=
RIST)

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

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

On Mon, 16 Sep 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> I found that gdImagePalettePixel() is really a macro:
>
> #define gdImagePalettePixel(  im, x, y )   (im)->pixels[(y)][(x)]
>
> So, putting it above  gd.c:plD_gd_optimise(), makes the unknown symbol
> error to disappear, but the seg fault still happens:
>
> [jcard@feup] ./x01c -dev png -o po.png
> Plplot library version: 5.1.0
> Opened po.png
> Segmentation fault

I have now fixed this problem (but not the macro problem which I am leaving
to Andrew for final decision since I don't know whether or not that macro
would actually work with libgd 1.8.4 with -drvopt optimise).  But if you cv=
s
update and work around the gdImagePalettePixel problem by adding the macro,
I think you will find the above problem will be gone.

BTW, Andrew, I have just checked your recent changes, and eveything seems
to be fine; x08c gives good results with
no drvopt and with
-drvopt text,smooth,24bit and
-drvopt text,smooth.

Alan

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

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

On Mon, 16 Sep 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> Plplot library version: 5.1.0
> plLoadDriver: Device not loaded!
> plLoadDriver: tag=3Dpng, drvidx=3D4
> plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so
> plLoadDriver: Local dlopen failed because of the following reason:
> ./drivers/gdd_drv.so: undefined symbol: gdImagePalettePixel

I am so glad to see this error message finally deliver something meaningful=
!

> [jcard@feup] rpm -q gd
> gd-1.8.4-238
>
> And gdImagePalettePixel() does not exists in the gd library.

I have investigated further, and it is an undocumented but small
macro in version 2.0.1 of libgd which I presume is not in 1.8.4 since
Joao's compiler didn't find it.

#define gdImagePalettePixel(im, x, y) (im)->pixels[(y)][(x)]

Andrew, I am not sufficiently familiar with libgd to know whether this macr=
o
would work for version 1.84.  If you know it would work, we could put this
macro definition into gd.c.  Alternatively, we could just drop
plD_gd_optimise with #ifdefine if the GD version is not greater than 2.
Please make whichever change you feel is appropriate.

Alan