gnuplot-beta — Developers and beta testers of new gnuplot code

Re: [GD-DEVEL] Re: gd2 & fontconfig/freetype fail to find fonts on Mac OS X (macports)

[Ethan M. <merritt@u.washington.edu>]

I wrote>
> In fact, contrary to the documentation, passing 0 to gdFTUseFontConfig()
> seems to enable fontconfig all by itself, so it is unsafe to use this for
> a test either.
>
> Is that correct?
> If so, is there a work-around?
> Can we expect a fix?

And here is the fix, courtesy of Mojca Miklavec.
Tested using gnuplot and "set term png font '...'"

Can this please be included in 2.0.36?

	regards,

		Ethan

--- gdft.c.sav  2009-04-13 13:38:18.000000000 -0700
+++ gdft.c      2009-04-13 13:38:52.000000000 -0700
@@ -1661,7 +1661,7 @@ static char * font_path(char **fontpath,
 BGD_DECLARE(int) gdFTUseFontConfig(int flag)
 {
 #ifdef HAVE_LIBFONTCONFIG
-       fontConfigFlag = 1;
+       fontConfigFlag = flag;
        return 1;
 #else
        return 0;



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: [GD-DEVEL] Re: gd2 & fontconfig/freetype fail to find fonts on Mac OS X (macports)

[Ethan M. <merritt@u.washington.edu>]

On Monday 13 April 2009 09:10:23 Pierre Joye wrote:
> On Mon, Apr 13, 2009 at 5:56 PM, Ethan Merritt <merritt@u.washington.edu> wrote:
>> Is it true that libgd now looks for fontconfig?
> no, only if you tell it to do so.

I now see that Mojca has pointed out the function gdFTUseFontConfig(),
which I did not know about.   This looks very promising, and I think we should
use it to try both the old (GDFONTPATH) and new (fontconfig) mechanisms when
looking for a user-specified font.

However, I coded up a quick test patch for gnuplot's gd driver and ran into
the following problem.  Perhaps I am doing something wrong:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
        /* First try the old GDFONTPATH mechanism for locating fonts */
        gdFTUseFontConfig(0);
        err = gdImageStringFT(NULL, &brect[0], 0,
                png_state.ttffont, (double)png_state.default_ttfsize,
                0.0, 0, 0, "test");

        /* If that didn't work, try again using fontconfig mechanism */
        if (err && gdFTUseFontConfig(1)) {
            err = gdImageStringFT(NULL, &brect[0], 0,
                png_state.ttffont, (double)png_state.default_ttfsize,
                0.0, 0, 0, "test");
            fprintf(stderr,"fontconfig %s font %s\n",
                err ? "did not find" : "found",
                png_state.ttffont);
        }

        /* If we still haven't found the font, punt to the internal non-TTF default set */
        if (err) {
            fprintf(stderr,"%s when opening font \"%s\", using internal non-scalable font\n",
                        err, png_state.ttffont);
	}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

This works great the first time through.  If the font is not found by file-name in
GDFONTPATH, then it switches over to use fontconfig and correctly finds the font.

However, on subsequent calls it fails if you do in fact provide a file name.
As best as I can make out,  gdFTUseFontConfig(1) enables the fontconfig mechanism
but gdFTUseFontConfig(0) does not disable it again.  

In fact, contrary to the documentation, passing 0 to gdFTUseFontConfig() seems to
enable fontconfig all by itself, so it is unsafe to use this for a test either.

Is that correct? 
If so, is there a work-around?
Can we expect a fix?

	Ethan



> On Mon, Apr 13, 2009 at 5:56 PM, Ethan Merritt <merritt@u.washington.edu> wrote:
> > Now I'm confused.
> > Is it true that libgd now looks for fontconfig?
> >
> >
> > ----------  Forwarded Message  ----------
> >
> > Subject: [GD-DEVEL] Re: gd2 & fontconfig/freetype fail to find fonts on Mac OS X (macports)
> > Date: Monday 13 April 2009
> > From: Ryan Schmidt <rya...@ma...>
> > To: Mojca Miklavec <moj...@gm...>
> >
> > On Apr 13, 2009, at 01:47, Mojca Miklavec wrote:
> >
> >> I'm using Mac OS X 10.5 with GD installed via Macports
> >> (http://gd2.darwinports.com/) and as many others (I think both linux
> >> and mac users), I have problem using some deafult fonts inside gnuplot
> >> when using GD library to generate plots.
> >
> > Please do not refer to that web site for information about MacPorts.
> > That web site is not affiliated with the MacPorts project. For
> > information about MacPorts, go to
> >
> > http://www.macports.org/
> >
> > For more information on the web site that is not related to our
> > project, please read:
> >
> > http://trac.macports.org/wiki/DarwinPorts
> >
> >
> >>> gnuplot
> >>> set term png
> >> Terminal type set to 'png'
> >> Could not find/open font when opening font "arial", using internal
> >> non-scalable font
> >> Options are 'nocrop medium size 640,480 '
> >>
> >> Please note that this only happens with recent (maybe only
> >> development) version of gnuplot. I'm working with 4.3 from CVS. In
> >> past, gnuplot simply ignored the fact the GD was not able to find
> >> trutype fonts, it's only recently that it issues a warning.
> >>
> >> But the font in available on computer of course and "fc-list arial"
> >> returns this (+ dozens of translations):
> >>
> >> Arial:style=Bold Italic
> >> Arial:style=Italic
> >> Arial:style=Regular
> >> Arial:style=Bold
> >>
> >> Following instructions on http://www.libgd.org/DOC_INSTALL_OSX I
> >> tried to set
> >>     export GDFONTPATH=$HOME/Library/Fonts:/Library/Fonts:/System/
> >> Library/Fonts
> >> and afterwards it worked OK.
> >>
> >> But the main question is: why doesn't GD find the font out-of-the-box,
> >> without having to give it a hint about GDFONTPATH? It may be a problem
> >> with configuration in macports that ships this library, but it
> >> probably makes more sense to ask here first. I can try to play a bit
> >> with installation following your instructions and then ask on macports
> >> to change some bits in configuration if needed.
> >
> > What I understand from reading that DOC_INSTALL_OSX page you
> > referenced above is that setting GDFONTPATH is only necessary if
> > fontconfig cannot be found. But the gd2 port does declare a
> > dependency on the fontconfig port so it should be there.
> >
> > If there is something I need to change in the gd2 port or the
> > fontconfig port related to this, please copy me on the replies; I am
> > not subscribed to the gd-devel mailing list.
> >
> >
> >
> > --
> > GD Devel Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> > -------------------------------------------------------
> >
> > --
> > Ethan A Merritt
> > Biomolecular Structure Center
> > University of Washington, Seattle 98195-7742
> >
> > ------------------------------------------------------------------------------
> > This SF.net email is sponsored by:
> > High Quality Requirements in a Collaborative Environment.
> > Download a free trial of Rational Requirements Composer Now!
> > http://p.sf.net/sfu/www-ibm-com
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >
> 
> 
> 
> -- 
> Pierre
> 
> http://blog.thepimp.net | http://www.libgd.org
> 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: [GD-DEVEL] Re: gd2 & fontconfig/freetype fail to find fonts on Mac OS X (macports)

[Mojca M. <moj...@gm...>]

On Mon, Apr 13, 2009 at 17:56, Ethan Merritt wrote:
> Now I'm confused.
> Is it true that libgd now looks for fontconfig?

Hello,

I'm sorry if I caused any confusion. Thanks to the main developer of
GD for clearing it out, after adding the following command to gd.trm
    gdFTUseFontConfig(1);
gnuplot stoped complaining about "arial not found".

See:
http://lib.gd/Font#int_gdFTUseFontConfig.28int_flag.29_.28FUNCTION.29

Would it be possible to fix gnuplot in that respect? I'm not sure
where this command should go, and I'm not sure how to make sure that
providing comlete path to some font will still work, but it would be
really nice to both prevent throwing that error about font not found
and to enable searching for font system-wide.

Mojca

Re: [GD-DEVEL] Re: gd2 & fontconfig/freetype fail to find fonts on Mac OS X (macports)

[Pierre J. <pie...@gm...>]

no, only if you tell it to do so.

On Mon, Apr 13, 2009 at 5:56 PM, Ethan Merritt <merritt@u.washington.edu> wrote:
> Now I'm confused.
> Is it true that libgd now looks for fontconfig?
>
>
> ----------  Forwarded Message  ----------
>
> Subject: [GD-DEVEL] Re: gd2 & fontconfig/freetype fail to find fonts on Mac OS X (macports)
> Date: Monday 13 April 2009
> From: Ryan Schmidt <rya...@ma...>
> To: Mojca Miklavec <moj...@gm...>
>
> On Apr 13, 2009, at 01:47, Mojca Miklavec wrote:
>
>> I'm using Mac OS X 10.5 with GD installed via Macports
>> (http://gd2.darwinports.com/) and as many others (I think both linux
>> and mac users), I have problem using some deafult fonts inside gnuplot
>> when using GD library to generate plots.
>
> Please do not refer to that web site for information about MacPorts.
> That web site is not affiliated with the MacPorts project. For
> information about MacPorts, go to
>
> http://www.macports.org/
>
> For more information on the web site that is not related to our
> project, please read:
>
> http://trac.macports.org/wiki/DarwinPorts
>
>
>>> gnuplot
>>> set term png
>> Terminal type set to 'png'
>> Could not find/open font when opening font "arial", using internal
>> non-scalable font
>> Options are 'nocrop medium size 640,480 '
>>
>> Please note that this only happens with recent (maybe only
>> development) version of gnuplot. I'm working with 4.3 from CVS. In
>> past, gnuplot simply ignored the fact the GD was not able to find
>> trutype fonts, it's only recently that it issues a warning.
>>
>> But the font in available on computer of course and "fc-list arial"
>> returns this (+ dozens of translations):
>>
>> Arial:style=Bold Italic
>> Arial:style=Italic
>> Arial:style=Regular
>> Arial:style=Bold
>>
>> Following instructions on http://www.libgd.org/DOC_INSTALL_OSX I
>> tried to set
>>     export GDFONTPATH=$HOME/Library/Fonts:/Library/Fonts:/System/
>> Library/Fonts
>> and afterwards it worked OK.
>>
>> But the main question is: why doesn't GD find the font out-of-the-box,
>> without having to give it a hint about GDFONTPATH? It may be a problem
>> with configuration in macports that ships this library, but it
>> probably makes more sense to ask here first. I can try to play a bit
>> with installation following your instructions and then ask on macports
>> to change some bits in configuration if needed.
>
> What I understand from reading that DOC_INSTALL_OSX page you
> referenced above is that setting GDFONTPATH is only necessary if
> fontconfig cannot be found. But the gd2 port does declare a
> dependency on the fontconfig port so it should be there.
>
> If there is something I need to change in the gd2 port or the
> fontconfig port related to this, please copy me on the replies; I am
> not subscribed to the gd-devel mailing list.
>
>
>
> --
> GD Devel Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> -------------------------------------------------------
>
> --
> Ethan A Merritt
> Biomolecular Structure Center
> University of Washington, Seattle 98195-7742
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>



-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org

Fwd: [GD-DEVEL] Re: gd2 & fontconfig/freetype fail to find fonts on Mac OS X (macports)

[Ethan M. <merritt@u.washington.edu>]

Now I'm confused.
Is it true that libgd now looks for fontconfig?


----------  Forwarded Message  ----------

Subject: [GD-DEVEL] Re: gd2 & fontconfig/freetype fail to find fonts on Mac OS X (macports)
Date: Monday 13 April 2009
From: Ryan Schmidt <rya...@ma...>
To: Mojca Miklavec <moj...@gm...>

On Apr 13, 2009, at 01:47, Mojca Miklavec wrote:

> I'm using Mac OS X 10.5 with GD installed via Macports
> (http://gd2.darwinports.com/) and as many others (I think both linux
> and mac users), I have problem using some deafult fonts inside gnuplot
> when using GD library to generate plots.

Please do not refer to that web site for information about MacPorts.  
That web site is not affiliated with the MacPorts project. For  
information about MacPorts, go to

http://www.macports.org/

For more information on the web site that is not related to our  
project, please read:

http://trac.macports.org/wiki/DarwinPorts


>> gnuplot
>> set term png
> Terminal type set to 'png'
> Could not find/open font when opening font "arial", using internal
> non-scalable font
> Options are 'nocrop medium size 640,480 '
>
> Please note that this only happens with recent (maybe only
> development) version of gnuplot. I'm working with 4.3 from CVS. In
> past, gnuplot simply ignored the fact the GD was not able to find
> trutype fonts, it's only recently that it issues a warning.
>
> But the font in available on computer of course and "fc-list arial"
> returns this (+ dozens of translations):
>
> Arial:style=Bold Italic
> Arial:style=Italic
> Arial:style=Regular
> Arial:style=Bold
>
> Following instructions on http://www.libgd.org/DOC_INSTALL_OSX I  
> tried to set
>     export GDFONTPATH=$HOME/Library/Fonts:/Library/Fonts:/System/ 
> Library/Fonts
> and afterwards it worked OK.
>
> But the main question is: why doesn't GD find the font out-of-the-box,
> without having to give it a hint about GDFONTPATH? It may be a problem
> with configuration in macports that ships this library, but it
> probably makes more sense to ask here first. I can try to play a bit
> with installation following your instructions and then ask on macports
> to change some bits in configuration if needed.

What I understand from reading that DOC_INSTALL_OSX page you  
referenced above is that setting GDFONTPATH is only necessary if  
fontconfig cannot be found. But the gd2 port does declare a  
dependency on the fontconfig port so it should be there.

If there is something I need to change in the gd2 port or the  
fontconfig port related to this, please copy me on the replies; I am  
not subscribed to the gd-devel mailing list.



-- 
GD Devel Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


-------------------------------------------------------

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: gnuplot 4.2 fails to run gretl files

[Allin C. <cot...@wf...>]

On Sun, 12 Apr 2009, Ethan Merritt wrote:

> On Sunday 12 April 2009, Allin Cottrell wrote:
> > On Sun, 12 Apr 2009, snvv wrote:
> > > Problem:
> > > When I try to create a graph it fails
> > >
> > > Operating System:
> > > Operating System Debian sid
> > > gretl ver. 1.8.0
> > > gnuplot ver 4.2 patchlevel 5 ...
> > >
> > > gnuplot: using libgd png driver
> > > stderr: 'Could not find/open font when opening font "arial", using
> > > internal non-scalable font
> > > ' ...
> > > Additional comments
> > > The first line of the created gnuplot file is:
> > >
> > > set term png truecolor small size 680,400
> >
> > This is primarily a bug with the libgd installation, which can't
> > find the arial font.
>
> I wouldn't call that a libgd installation problem.

I mean that if a distribution is packaging libgd, they should
either patch it to look for fonts in the right place for that
distribution or set the appropriate environment variable, rather
than installing a semi-functional library.  Lots of people on
Debian and Debian-derived Linux variants run into the issue
of gnuplot being unable to respect a TrueType font setting when
using the libgd png driver.  IMO this should work "out of box".

Third-party programs such as gretl have to try to work around this
problem, but the work-arounds are error-prone.

Personally I would be very pleased to see the cairo-based png
driver in an official gnuplot release.  It has no problem with
fonts since it relies on fontconfig rather than an idiosyncratic
hard-wired font path.

Allin Cottrell

Re: gnuplot 4.2 fails to run gretl files

[Ethan M. <merritt@u.washington.edu>]

On Sunday 12 April 2009, Allin Cottrell wrote:
> On Sun, 12 Apr 2009, snvv wrote:
> > Problem:
> > When I try to create a graph it fails
> >
> > Operating System:
> > Operating System Debian sid
> > gretl ver. 1.8.0
> > gnuplot ver 4.2 patchlevel 5 ...
> >
> > gnuplot: using libgd png driver
> > stderr: 'Could not find/open font when opening font "arial", using
> > internal non-scalable font
> > ' ...
> > Additional comments
> > The first line of the created gnuplot file is:
> >
> > set term png truecolor small size 680,400
>
> This is primarily a bug with the libgd installation, which can't
> find the arial font.  

I wouldn't call that a libgd installation problem.

Gnuplot needs to try some default truetype font; it happens to use Arial
because that is very common.   The error message is telling you that
either (a) you don't have Arial installed at all and should pick a different
defaultfont (environmental variable GNUPLOT_DEFAULT_GDFONT)
or (b) you do have Arial installed but in a directory that is not part of
the font search path (environmental variable GDFONTPATH).

libgd can be correctly installed, but still you need to specify where 
your fonts are located.

> However, I think there's a case for saying 
> there's a minor gnuplot bug here: given the terminal setting
> quoted above, why is gnuplot giving the error message about arial?
> Isn't "small" a directive to use the libgd internal font?

There was a long thread arguing this point on the usenet group
recently.   People have old scripts that use the keyword "small".
When run with a modern gnuplot that supports scalable fonts,
(i.e. anything since the version 4.0) what should happen by default?
My perspective is that over the years there were many 
queries/complaints about enhanced text or text rotation not working
in PNG, caused by a failure to specify a scalable font.  This was
solved by having gd.trm try to find a scalable font by default, using
a couple of common font names.  Yes, this makes it harder to explicitly
request a built-in non-scalable font, but the recent usenet query was
honestly the first time I've ever seen such a request.

> (Off topic here, but gretl -- a third party caller of gnuplot --
> is getting confused by that error message; it doesn't expect it
> because previous gnuplot versions didn't emit it.)

I don't think there has ever been an expectation that error messages
will not change.  Some of them are emitted by one of the support 
libraries, not by the gnuplot code per se.

-- 
Ethan Merritt
(on the road)

Re: gnuplot 4.2 fails to run gretl files

[Allin C. <cot...@wf...>]

On Sun, 12 Apr 2009, snvv wrote:

> Problem:
> When I try to create a graph it fails
>
> Operating System:
> Operating System Debian sid
> gretl ver. 1.8.0
> gnuplot ver 4.2 patchlevel 5 ...

> gnuplot: using libgd png driver
> stderr: 'Could not find/open font when opening font "arial", using internal
> non-scalable font
> ' ...
> Additional comments
> The first line of the created gnuplot file is:
>
> set term png truecolor small size 680,400

This is primarily a bug with the libgd installation, which can't
find the arial font.  However, I think there's a case for saying
there's a minor gnuplot bug here: given the terminal setting
quoted above, why is gnuplot giving the error message about arial?
Isn't "small" a directive to use the libgd internal font?

(Off topic here, but gretl -- a third party caller of gnuplot --
is getting confused by that error message; it doesn't expect it
because previous gnuplot versions didn't emit it.)

Allin Cottrell

gnuplot 4.2 fails to run gretl files

[snvv <sn...@gm...>]

Problem:
When I try to create a graph it fails

Operating System:
Operating System Debian sid
gretl ver. 1.8.0
gnuplot ver 4.2 patchlevel 5

Error message:
get_gretl_charset: using UTF-8

Read datafile /usr/share/gretl/data/misc/anscombe.gdt
periodicity: 1, maxobs: 11,
observations range: 1-11

gnuplot: using libgd png driver
stderr: 'Could not find/open font when opening font "arial", using internal
non-scalable font
'
gretl_errmsg: 'Could not find/open font when opening font "arial", using
internal non-scalable font
'
Failed command: 'gnuplot "/home/snvv101/.gretl/gpttmp.VJWFZ6"'

Additional comments
The first line of the created gnuplot file is:

set term png truecolor small size 680,400


###############################


If I remove that line then I can produce the graph in gnuplot.

Obviously gretl does not accept set term png but either terminal
gnuplot> set term png
Terminal type set to 'png'
Could not find/open font when opening font "arial", using internal
non-scalable font
Options are 'nocrop medium '
gnuplot>
gnuplot> set terminal png
Terminal type set to 'png'
Could not find/open font when opening font "arial", using internal
non-scalable font
Options are 'nocrop medium '


Is it possible to configure gnuplot to accept set term png truecolor small
size 680,400?


Please note that Arial font exists in my system.
I have read somewhere that may the follow command solve the problem
export GDFONTPATH="/usr/share/fonts/truetype/thryomanes/" 
gnuplot> set term png font thryb___ 12

I tried them witout success.


Thank you
snvv
-- 
View this message in context: http://www.nabble.com/gnuplot-4.2-fails-to-run-gretl-files-tp23003097p23003097.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

tex4th: Possible Tool for Documentation Formating

[Philipp K. J. <ja...@ie...>]

A while back there was some talk on this
mailing list about tools to generate gnuplot 
documentation, in particular since support 
for latex2html seems to weak these days.

I just discovered tex4ht (for HyperText),
which apparently can translate (la)tex into
HTML, DocBook, and some other formats.

Her is the URL:
	http://www.cse.ohio-state.edu/~gurari/TeX4ht/

I have not used it much, but some (trivial)
tests I ran with it were encouraging. It might
be a viable alternative to latex2html. It seems
worth checking out.

Disclaimer: I am not affiliated with this tool
or its author in any way. I just discovered
it and thought it was interesting.

Best,

		Ph.

Re: gnuplot 4.3: drawing gnuplot binary

[Ethan M. <merritt@u.washington.edu>]

On Thursday 09 April 2009, Petr Mikulik wrote:
> The following two examples:
> 1.
>     set datafile binary filetype=gpbin
>     plot 'binary3' binary with image
> 2.
>     set datafile binary filetype=auto
>     plot 'binary3' binary with image
>
> stopped working after this patch:
>
>   2008-12-02  Ethan Merritt
>
>   * src/datafile.c (plot_option_binary plot_option_array):
>   Setting default suboptions for binary file input was documented, but
>   never implemented.  Now it is.
>
> Example 1 works OK in gnuplot 4.2.
> Example 2 worked in gnuplot 4.3 till 2.12.2008.
> Now it does not work in gnuplot 4.2 nor in new 4.3. 

The problem appears to be the following line, which is shown commented out.
I do not know why it was written that way, and I do not know what other 
effects may result from removing it.

gnuplot/src/datafile.c	2009-04-07 22:06:10.000000000 -0700
@@ -3229,7 +3229,8 @@ plot_option_binary(TBOOLEAN set_matrix, 
 
     if (!set_default && !set_matrix && df_num_bin_records_default) {
 	int_warn(NO_CARET, "using default binary record/array structure");
//	EAM - this seems cause problems.  Why is it here?
//	df_matrix_file = FALSE;
     }
 


-- 
Ethan Merritt
(on the road)

Re: gnuplot 4.3: drawing gnuplot binary

[Ethan M. <merritt@u.washington.edu>]

On Thursday 09 April 2009, Petr Mikulik wrote:
> The following two examples:
> 1.
>     set datafile binary filetype=gpbin
>     plot 'binary3' binary with image
> 2.
>     set datafile binary filetype=auto
>     plot 'binary3' binary with image
>
> stopped working after this patch:
>
>   2008-12-02  Ethan Merritt
>
>   * src/datafile.c (plot_option_binary plot_option_array):
>   Setting default suboptions for binary file input was documented, but
>   never implemented.  Now it is. 

I am confused.  As the commit comment indicates, prior to that patch
the command "set datafile binary filetype=XXX" was a no-op.  It did nothing. 
So if the command sequence worked before that, it did so by coincidence.

> Example 1 works OK in gnuplot 4.2.
> Example 2 worked in gnuplot 4.3 till 2.12.2008.
> Now it does not work in gnuplot 4.2 nor in new 4.3. However, it is
> unclear what format gnuplot expects when there is no format determined
> from file's extension.

Exactly.  What is the format of this file?  

> There are warnings: 
>   plot 'binary3' binary with image
>          warning: Unrecognized filetype; try "show datafile binary
> filetypes"

ummmm.  Actually, for me that command works fine in current cvs.
It only fails if I first issue a "set datafile binary filetype=foo" command.
That is consistent with the "set datafile binary filetype=foo" command being a 
no-op prior to the patch you point to. 

>          warning: using default binary record/array structure
> But what is it "default binary record structure"?
> I think the default filetype should be "gnuplot binary" (compatibility
> reasons).

Fine with me. 
But what exactly is the "gnuplot binary" filetype, and how does one specify or 
recognize it?


-- 
Ethan Merritt
(on the road)

Re: gnuplot 4.2: splot with image broken on X11

[Ethan M. <merritt@u.washington.edu>]

On Thursday 09 April 2009, Petr Mikulik wrote:
> The following commands in demo/ do not work in gnuplot 4.2 and X11
> terminal:
>     splot 'triangle.dat' with image
> or
>     splot 'binary3' binary with image
>
> Note that the output is drawn correctly for other terminals.
> Note that the output is correct on X11 for "plot ... with image".
>
> It seems to be caused by:
>
> 2008-06-22  Ethan Merritt
>
> * src/gplt_x11.c: Consolidate the fillstyle code into a single routine
> that is called both by fillbox and filledpolygon processing. This fixes a
> bug in which the fillstyle border was not applied to filled curves.

Hmm, yes.
That patch collapsed two 'identical' sections of code into a single shared
subroutine.  But closer inspection reveals that they were not quite identical
after all.  I'll fix it, but of course it's too late for 2.4.5

-- 
Ethan Merritt
(on the road)

gnuplot 4.3: drawing gnuplot binary

[Petr M. <mi...@ph...>]

The following two examples:
1.
    set datafile binary filetype=gpbin
    plot 'binary3' binary with image
2. 
    set datafile binary filetype=auto
    plot 'binary3' binary with image

stopped working after this patch:

  2008-12-02  Ethan Merritt

  * src/datafile.c (plot_option_binary plot_option_array):
  Setting default suboptions for binary file input was documented, but
  never implemented.  Now it is.

Example 1 works OK in gnuplot 4.2.
Example 2 worked in gnuplot 4.3 till 2.12.2008. 
Now it does not work in gnuplot 4.2 nor in new 4.3. However, it is
unclear what format gnuplot expects when there is no format determined
from file's extension. There are warnings:
  plot 'binary3' binary with image
         warning: Unrecognized filetype; try "show datafile binary 
filetypes"
         warning: using default binary record/array structure
But what is it "default binary record structure"?
I think the default filetype should be "gnuplot binary" (compatibility
reasons).

---
PM

gnuplot 4.2: splot with image broken on X11

[Petr M. <mi...@ph...>]

The following commands in demo/ do not work in gnuplot 4.2 and X11
terminal:
    splot 'triangle.dat' with image
or
    splot 'binary3' binary with image

Note that the output is drawn correctly for other terminals.
Note that the output is correct on X11 for "plot ... with image".

It seems to be caused by:

2008-06-22  Ethan Merritt

* src/gplt_x11.c: Consolidate the fillstyle code into a single routine
that is called both by fillbox and filledpolygon processing. This fixes a
bug in which the fillstyle border was not applied to filled curves.

---
PM

Re: gnuplot documentation and picins

[Mojca M. <moj...@gm...>]

On Mon, Apr 6, 2009 at 23:47, Ethan Merritt wrote:
> On Monday 06 April 2009 14:05:57 Mojca Miklavec wrote:
>> Hello,
>>
>> I'm trying to build gnuplot documentation (with "make pdf"), but it
>> requires a package picins.sty that has been removed from TeX Live a
>> while ago due to not-free-enough licence. As far as I could see the
>> package has not been used at all: removing the line
>> "\usepackage{picins}" didn't do any harm at all and the documentation
>> has been built normally (though I didn't inspect the resulting PDF in
>> details).
>
> I am using texlive, and for me the picins.sty file works fine.
> It is still easily available, even if it isn't bundled with texlive.

It's definitely easily available, there's no doubt about it.

>> Would it make sense to remove that line or do something else to
>> prevent problems? (Maybe some developers are still using tetex and
>> don't experience the problem, but sooner or later it will strike
>> back.)
>
> It is needed in order to include figures in the pdf documentation.
> That is the "make pdffigures" target.

OK, I knew I was missing something.

> I have tried another package as a replacement (sorry, can't rememeber
> which one it was) but the results were not very satisfactory.
> But if you can suggest other packages to try, I am willing.

I need to check the results first.

One idea that comes to my mind first before exploring other packages
is to include the source (either the file itself, or only the contents
with explanation) of the package into manual (to copy macros instead
of saying \usepackage{picins}). One probably needs to ask the author,
but I don't think that author would object.

I understand the licence as
    "I'm using this package, so please don't make changes that could
destroy my old documents."
rather than
    "This is absolutely copyrighted. You may not do anything with it."

But that needs your opinion first. I wonder how different
distributions compile the documentation by default (if they compile it
at all).

Mojca

Re: gnuplot documentation and picins

[Ethan M. <merritt@u.washington.edu>]

On Monday 06 April 2009 14:05:57 Mojca Miklavec wrote:
> Hello,
> 
> I'm trying to build gnuplot documentation (with "make pdf"), but it
> requires a package picins.sty that has been removed from TeX Live a
> while ago due to not-free-enough licence. As far as I could see the
> package has not been used at all: removing the line
> "\usepackage{picins}" didn't do any harm at all and the documentation
> has been built normally (though I didn't inspect the resulting PDF in
> details).

I am using texlive, and for me the picins.sty file works fine.
It is still easily available, even if it isn't bundled with texlive.

> Would it make sense to remove that line or do something else to
> prevent problems? (Maybe some developers are still using tetex and
> don't experience the problem, but sooner or later it will strike
> back.)

It is needed in order to include figures in the pdf documentation.
That is the "make pdffigures" target.

I have tried another package as a replacement (sorry, can't rememeber
which one it was) but the results were not very satisfactory.
But if you can suggest other packages to try, I am willing.

	Ethan

gnuplot documentation and picins

[Mojca M. <moj...@gm...>]

Hello,

I'm trying to build gnuplot documentation (with "make pdf"), but it
requires a package picins.sty that has been removed from TeX Live a
while ago due to not-free-enough licence. As far as I could see the
package has not been used at all: removing the line
"\usepackage{picins}" didn't do any harm at all and the documentation
has been built normally (though I didn't inspect the resulting PDF in
details).

Would it make sense to remove that line or do something else to
prevent problems? (Maybe some developers are still using tetex and
don't experience the problem, but sooner or later it will strike
back.)

Thanks,
   Mojca

Re: Octave 3.1.55: printing to pdf

[Ben A. <bpa...@ma...>]

On Apr 5, 2009, at 2:14 PM, Ethan A Merritt wrote:

> On Sunday 05 April 2009, Ben Abbott wrote:
>>
>> On Apr 5, 2009, at 3:47 AM, Petr Mikulik wrote:
>>
>>> Printing to pdf (via gnuplot backend) is broken in Octave 3.1.55
>>> even though
>>> gnuplot accepts "set term pdf" via "pdfcairo" terminal.
>>>
>>>
>>>> plot(1:100); print a.pdf -dpdf
>>>
>>> error: gnuplot_drawnow: the gnuplot terminal, "pdf", is not  
>>> available.
>>> error: called from:
>>> error:
>>> /opt/octave/octave-3.1.55/share/octave/3.1.55/m/plot/
>>> gnuplot_drawnow.m at
>>> line 72, column 7
>>>
>>>
>>> It seems that gnuplot_drawnow.m requires exact match of terminal
>>> names in
>>> 3.1.55. However, gnuplot names the pdf terminal "pdf" or "pdfcairo"
>>> according to the library it was compiled against. In both cases "set
>>> term
>>> pdf" works.
>>>
>>> I think gnuplot_drawnow.m should test presence of "pdfcairo" if
>>> "pdf" has
>>> not been found.
>>>
>>> If I try
>>> 	print zz.png -dpngcairo
>>> 	print zz.pdf -dpdfcairo
>>> it produces these two files:
>>> 	pngcairo:zz.png
>>> 	pdfcairo:zz.pdf
>>> Why the prefix there?
>>>
>>> ---
>>> PM
>>
>> Petr,
>>
>> For "set term png" if there is no "png" present does gnuplot
>> substitute "pngcairo" as well?
>
> yes
>
>> I notice the cairo terminals default options are different from the
>> non-cairo terminals. Specifically, there is no default font-name
>> specified, in GPVAL_TERMOPTIONS, for the cairo terminals. This will
>> interfere with the rendering of different font-sizes when the
>> anonymous font-name "*" is associated to an Octave text object.
>
> The cairo terminals default to font "Sans".
> Why does this make a difference?

Octave would prefer to specify the font-name and font-size for all  
text objects. Unfortunately, Octave has no way to determining that  
font-names are available to a particular gnuplot terminal. If a font- 
name is specified that a terminal does not have access to, errors/ 
warnings result. In addition, the text generally does not show up.

To alleviate this, the current implementation of Octave uses an  
anonymous default font-name, "*". When this anonymous font-name is  
associated with a text object,  neither the font-name or font-size are  
passed on to gnuplot. The exceptions to this are the x11 and wxt  
terminals which apparently have no problem with the fontname "*".

> Would you like this to be echoed back by "show term"?
> All gnuplot terminals should accept a font-size request with a blank  
> font
> name as referring to the current (perhaps default) font.
> E.g.
>     set term png enhanced font ",11"
>     set title "Big Title" font ",20"
> should give you the default font in size 11 points, and a title in the
> same font with size 20 points.

Ok! I'll prepare a changeset to fix how Octave handles a font-name of  
"*".

Thanks for the information. This will simplify things quite a bit.

Ben

Re: Octave 3.1.55: printing to pdf

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 05 April 2009, Ben Abbott wrote:
> 
> On Apr 5, 2009, at 3:47 AM, Petr Mikulik wrote:
> 
> > Printing to pdf (via gnuplot backend) is broken in Octave 3.1.55  
> > even though
> > gnuplot accepts "set term pdf" via "pdfcairo" terminal.
> >
> >
> >> plot(1:100); print a.pdf -dpdf
> >
> > error: gnuplot_drawnow: the gnuplot terminal, "pdf", is not available.
> > error: called from:
> > error:
> > /opt/octave/octave-3.1.55/share/octave/3.1.55/m/plot/ 
> > gnuplot_drawnow.m at
> > line 72, column 7
> >
> >
> > It seems that gnuplot_drawnow.m requires exact match of terminal  
> > names in
> > 3.1.55. However, gnuplot names the pdf terminal "pdf" or "pdfcairo"
> > according to the library it was compiled against. In both cases "set  
> > term
> > pdf" works.
> >
> > I think gnuplot_drawnow.m should test presence of "pdfcairo" if  
> > "pdf" has
> > not been found.
> >
> > If I try
> > 	print zz.png -dpngcairo
> > 	print zz.pdf -dpdfcairo
> > it produces these two files:
> > 	pngcairo:zz.png
> > 	pdfcairo:zz.pdf
> > Why the prefix there?
> >
> > ---
> > PM
> 
> Petr,
> 
> For "set term png" if there is no "png" present does gnuplot  
> substitute "pngcairo" as well?

yes

> I notice the cairo terminals default options are different from the  
> non-cairo terminals. Specifically, there is no default font-name  
> specified, in GPVAL_TERMOPTIONS, for the cairo terminals. This will  
> interfere with the rendering of different font-sizes when the  
> anonymous font-name "*" is associated to an Octave text object.

The cairo terminals default to font "Sans".
Why does this make a difference?
Would you like this to be echoed back by "show term"?
All gnuplot terminals should accept a font-size request with a blank font
name as referring to the current (perhaps default) font.
E.g.
     set term png enhanced font ",11"
     set title "Big Title" font ",20"
should give you the default font in size 11 points, and a title in the
same font with size 20 points.

 
> The prefixes "pngcairo" and "pdfcairo" prefixes are due to how print.m  
> has been implemented.
> 
> When the specified device does not match an explicit list, Octave  
> assumes that "convert" is to be used to convert the image to the  
> specified format. Octave uses eps as the basis for converting to other  
> formats.
> 
> As "pdfcairo" and "pngcairo" are not presently among the devices  
> supported by Ocave, the current implementation relies upon  
> "convert" ... which is obviously not what you intend, and does not  
> produce a sensible result.

I don't follow this.  Octave should not care how gnuplot chooses to
produce a PNG file.  There are at least 3 possible drivers that gnuplot
might use (the now obsolete libpng-based png driver, the libgd-based
png driver, and the cairo-based png driver).  In each case gnuplot
accepts "set term png", exactly so that the calling script or interactive
user does not need to know the details of that particular gnuplot 
installation.  

It is true, of course, that the obsolete driver never supported many of
the recent options like variable fonts and rgb colors,
but the libgd and cairo implementations are pretty similar in terms of
what they support.  In fact if you encounter an issue where they are
incompatible, I would appreciate a bug report.

> In any event, I'm planning to add support the Lua/TikZ terminal soon.  
> It would make sense for me to include the cairo terminals as well.

You should not have to do anything at all to support the cairo terminals.
Just issue the "set term png" or "set term pdf" commands as usual.

The only reason for ever saying "set term pngcairo" is if you are trying
to force a choice between two alternative png drivers in the same gnuplot
executable.  I think that is more of interest to gnuplot developers than
to outside users.  

-- 
Ethan A Merritt

Re: Octave 3.1.55: printing to pdf

[Ben A. <bpa...@ma...>]

On Apr 5, 2009, at 3:47 AM, Petr Mikulik wrote:

> Printing to pdf (via gnuplot backend) is broken in Octave 3.1.55  
> even though
> gnuplot accepts "set term pdf" via "pdfcairo" terminal.
>
>
>> plot(1:100); print a.pdf -dpdf
>
> error: gnuplot_drawnow: the gnuplot terminal, "pdf", is not available.
> error: called from:
> error:
> /opt/octave/octave-3.1.55/share/octave/3.1.55/m/plot/ 
> gnuplot_drawnow.m at
> line 72, column 7
>
>
> It seems that gnuplot_drawnow.m requires exact match of terminal  
> names in
> 3.1.55. However, gnuplot names the pdf terminal "pdf" or "pdfcairo"
> according to the library it was compiled against. In both cases "set  
> term
> pdf" works.
>
> I think gnuplot_drawnow.m should test presence of "pdfcairo" if  
> "pdf" has
> not been found.
>
> If I try
> 	print zz.png -dpngcairo
> 	print zz.pdf -dpdfcairo
> it produces these two files:
> 	pngcairo:zz.png
> 	pdfcairo:zz.pdf
> Why the prefix there?
>
> ---
> PM

Petr,

For "set term png" if there is no "png" present does gnuplot  
substitute "pngcairo" as well?

I notice the cairo terminals default options are different from the  
non-cairo terminals. Specifically, there is no default font-name  
specified, in GPVAL_TERMOPTIONS, for the cairo terminals. This will  
interfere with the rendering of different font-sizes when the  
anonymous font-name "*" is associated to an Octave text object.

The prefixes "pngcairo" and "pdfcairo" prefixes are due to how print.m  
has been implemented.

When the specified device does not match an explicit list, Octave  
assumes that "convert" is to be used to convert the image to the  
specified format. Octave uses eps as the basis for converting to other  
formats.

As "pdfcairo" and "pngcairo" are not presently among the devices  
supported by Ocave, the current implementation relies upon  
"convert" ... which is obviously not what you intend, and does not  
produce a sensible result.

In any event, I'm planning to add support the Lua/TikZ terminal soon.  
It would make sense for me to include the cairo terminals as well.

Ben

Octave 3.1.55: printing to pdf

[Petr M. <mi...@ph...>]

Printing to pdf (via gnuplot backend) is broken in Octave 3.1.55 even though 
gnuplot accepts "set term pdf" via "pdfcairo" terminal.


> plot(1:100); print a.pdf -dpdf

error: gnuplot_drawnow: the gnuplot terminal, "pdf", is not available.
error: called from:
error:   
/opt/octave/octave-3.1.55/share/octave/3.1.55/m/plot/gnuplot_drawnow.m at 
line 72, column 7


It seems that gnuplot_drawnow.m requires exact match of terminal names in 
3.1.55. However, gnuplot names the pdf terminal "pdf" or "pdfcairo" 
according to the library it was compiled against. In both cases "set term 
pdf" works.

I think gnuplot_drawnow.m should test presence of "pdfcairo" if "pdf" has 
not been found.

If I try
	print zz.png -dpngcairo
	print zz.pdf -dpdfcairo
it produces these two files:
	pngcairo:zz.png
	pdfcairo:zz.pdf
Why the prefix there?

---
PM

extra white pixel row in PNG

[Mojca M. <moj...@gm...>]

Hello,

Today I was trying to generate PNG "heatmaps" (similar to this one:
http://gnuplot.sourceforge.net/demo/pm3d.8.png) with one-to-one pixel
ratio, but I cannot get rid of the extra white row below data and one
extra white column on the right:

# remove everything but the plot
set tmargin 0
set bmargin 0
set lmargin 0
set rmargin 0
unset colorbox
unset border
unset xtics
unset ytics
unset key
set size ratio -1

n=4
# I have (x,y,z) tripples with x and y from (0,1,2,3,4)
# so that's a 5x5 matrix
set xrange [-0.5:n+0.5]
set yrange [-0.5:n+0.5]

# this doesn't work as desired, but leaves an extra blank row and column
set term png size n+1,n+1
plot "my-5-times-5.dat" matrix with image

At the end I solved the problem by using
set term png size n+2,n+2 crop
so that the crop command removed the extra line and column, but it
seems more like a tiny bug to me (most probably resulting from
fundamentally slightly different behaviour between pixel and vector
formats/different perception of whether one draws in the center of
pixels or on the border). Any comments or ideas about this?

Thanks,
    Mojca

Re: combining binary+vector terminals

[Mojca M. <moj...@gm...>]

On Sat, Apr 4, 2009 at 19:42, Ethan A Merritt wrote:

>> I would like to create a terminal that would combine some "pixel"
>> terminal with a TeX terminal. The same has been done with epslatex
>> where PS takes care for graphical part of the plot and TeX is used for
>> generating labels. I would like to do the same, but in the way that
>> drawing pixel data is delegated to some third terminal that generates
>> a PNG figure (could be GD or pango or whatever) and TeX labels are
>> handled with the TeX terminal. TeX would then include the generated
>> PNG image and draw true labels on top of image.
>
> Here is another suggestion for how one might do it:
>
> 1) Create a latex terminal variant that simply assumes that the graphics
>   part of the plot already exists.  The current CVS code stores
>   relevant information about plot boundaries and axis scaling from the
>   previous plot, so it should be possible to place all the text elements
>   appropriately.

Wow! That's indeed a great suggestion. There's only one tiny, but
important question: font sizes. How can I convince "the other" (pixel)
terminal to assume the same label sizes than the ones that TeX
terminal uses?

For example, I could alreadyuse (pseudocode):
    set term png withtransparentlabels
    set output "bla.png"
    plot sin(x)
    set term context/latex includethegraphics "bla.png" font "iwona,8"
    set output "bla.tex"
    plot sin(x)

but I'm afraid that if I align the borders of the two plots, the
graphics themselves won't align nicely because different label sizes
are used to generate the plots.

This means that it's not straight-forward to do it; it needs some
tweaking of font sizes, but I really like the idea and it should not
be too difficult to do. I'll take a look and come back.

> 2) Teach one or more of the other terminals (gd, cairo, post) to accept
>   a terminal option to draw all text invisibly.
>
> 3) Perhaps introduce a new top-level command that runs the plot through
>   these two drivers sequentially.  Doing it manually should be easy
>   enough, however.
>
> Something of the sort would also be useful for the svg and canvas
> terminals, whose respective output languages are not well suited for
> direct representation of pixel images.  Instead they expect to be able
> to refer to a PNG image in the appropriate position, similar to the
> way latex can embed an eps or pdf image.
>
>> My main question is: how difficult is the configuration process that
>> needs to be done in the background? I know a bit about programming and
>> managed to write a terminal that works OK, but I don't understand a
>> bit about configuring the bits and pieces, so that the code compiles
>> properly when using different libraries.
>
> Are you thinking of the autoconf tools?
> They are indeed a nightmare. But I would not worry about that until you
> actually have a new terminal ready to go.  What new libraries did you
> have in mind?

No new libraries. I just don't have any experience with external
libraries and their configuration. If GD library is already configured
properly, I guess that it should already work.

Mojca

Below are just my explanations (no need to argue on them, they are all
relative).

On Sat, Apr 4, 2009 at 19:42, Ethan A Merritt wrote:
> On Saturday 04 April 2009, Mojca Miklavec wrote:
>> Hello,
>>
>> I'm using gnuplot a lot for different kinds of graphs. I'm mostly
>> using the TeX terminal (my own one, ConTeXt), but as soon as one wants
>> to draw a complicated graphic (it's enough to request this:
>> http://gnuplot.sourceforge.net/demo_4.3/pm3d.8.png) the following
>> happens:
>> - TeX runs out of memmory very quickly
>> - even if TeX manages to process the graphic, desplaying it becomes
>> extremely slow if you ask any PS/PDF viewer to display one million
>> points or lines; it needs to draw every line separately even if most
>> of them are hidden
>
> Conclusion:
> TeX is very bad at graphics.  That is not what it was designed for.
> It is the wrong tool for the job.

That's both true and false. The old good TeX is very bad for graphics,
but when talking about ConTeXt and TikZ as macro packages, or in
particular about LuaTeX that has metapost built in ... TeX becomes
almost as powerful as PS/PDF.

The graphics generated by ConTeXt or TikZ terminal are of satisfactory
quality (comparable to that of other terminals) as long as we're
talking about 2D. 3D is indeed problematic, but too dense mesh causes
problems to PS/PDF as well.

But I don't want to argue whether TeX is suitable or not. As long as
it does the job well for me, I'm happy with it even if others are not.

>> If I use GD terminal, then I'm very limited with the labels I use (I
>> cannot use TeX tricks on them, the fonts don't scale, switching fonts
>> is very complicated and not too much platform-independent; I'm
>> copiling my documents on multiple platforms) etc. etc.
>
> I do not understand these comments.  The fonts are indeed scalable,

Yes, the fonts are scalable, I can get smaller or bigger fonts, but
once the labels are written to PNG file, one cannot zoom into the plot
and get arbitrary scaled version of the label any more. I prefer all
the labels in my documents to be scalable (in vector format).

(One side of the truth is that I still have some problems with gd
terminal, but that's another issue. Do not bother about it.)

> and are entirely platform-independent,

True, the font is platform-independent, but I need to tell gnuplot
where some font resides. And that information is not
platform-independent unless I put a copy of the font in folder when I
compile graphics. I need to figure out how to play with fonts inside
GD terminal (the main reason why I didn't do that until now is that
TeX more or less satisfies my needs except in some weird cases).

Another problem is that TeX is more powerful and (for me personally)
much easier to use when talking about placing labels with math
expressions. Again - I would not like to argue about it. Everyone has
its own preferences and this one is one of them.

> moreso than LaTeX fonts are
> since only the original machine, not the viewing machine, needs to
> have the fonts installed.

True, but I sometimes need to compile graphics on different machines.
I compile gnuplot graphics on the same machine where I compile TeX
graphics, so "viewing machine" and "original machine" imply "the same
different machines" in my case.

> In either case you have to have the support
> package installed (TeX in one case, libgd in the other).

I'm aware of that. I don't have problems installing TeX, though
configuring all the libraries to compile gnuplot properly may
sometimes be painful. But I can live with that.

Re: combining binary+vector terminals

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 04 April 2009, Mojca Miklavec wrote:
> Hello,
> 
> I'm using gnuplot a lot for different kinds of graphs. I'm mostly
> using the TeX terminal (my own one, ConTeXt), but as soon as one wants
> to draw a complicated graphic (it's enough to request this:
> http://gnuplot.sourceforge.net/demo_4.3/pm3d.8.png) the following
> happens:
> - TeX runs out of memmory very quickly
> - even if TeX manages to process the graphic, desplaying it becomes
> extremely slow if you ask any PS/PDF viewer to display one million
> points or lines; it needs to draw every line separately even if most
> of them are hidden

Conclusion:  
TeX is very bad at graphics.  That is not what it was designed for.
It is the wrong tool for the job.

> If I use GD terminal, then I'm very limited with the labels I use (I
> cannot use TeX tricks on them, the fonts don't scale, switching fonts
> is very complicated and not too much platform-independent; I'm
> copiling my documents on multiple platforms) etc. etc.

I do not understand these comments.  The fonts are indeed scalable,
and are entirely platform-independent, moreso than LaTeX fonts are
since only the original machine, not the viewing machine, needs to
have the fonts installed. In either case you have to have the support
package installed (TeX in one case, libgd in the other).
 
> I would like to create a terminal that would combine some "pixel"
> terminal with a TeX terminal. The same has been done with epslatex
> where PS takes care for graphical part of the plot and TeX is used for
> generating labels. I would like to do the same, but in the way that
> drawing pixel data is delegated to some third terminal that generates
> a PNG figure (could be GD or pango or whatever) and TeX labels are
> handled with the TeX terminal. TeX would then include the generated
> PNG image and draw true labels on top of image.

Here is another suggestion for how one might do it:  

1) Create a latex terminal variant that simply assumes that the graphics
   part of the plot already exists.  The current CVS code stores
   relevant information about plot boundaries and axis scaling from the
   previous plot, so it should be possible to place all the text elements
   appropriately.

2) Teach one or more of the other terminals (gd, cairo, post) to accept
   a terminal option to draw all text invisibly.

3) Perhaps introduce a new top-level command that runs the plot through
   these two drivers sequentially.  Doing it manually should be easy
   enough, however.

Something of the sort would also be useful for the svg and canvas
terminals, whose respective output languages are not well suited for
direct representation of pixel images.  Instead they expect to be able
to refer to a PNG image in the appropriate position, similar to the
way latex can embed an eps or pdf image.

> My main question is: how difficult is the configuration process that
> needs to be done in the background? I know a bit about programming and
> managed to write a terminal that works OK, but I don't understand a
> bit about configuring the bits and pieces, so that the code compiles
> properly when using different libraries.

Are you thinking of the autoconf tools?
They are indeed a nightmare. But I would not worry about that until you
actually have a new terminal ready to go.  What new libraries did you
have in mind?


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742