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

Re: cairo and character encoding issues

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

On Friday 23 November 2007 19:37, Allin Cottrell wrote:
> On Fri, 23 Nov 2007, Ethan A Merritt wrote:
> > 
> > > lascaux [1235] ./gnuplot...
> > 
> > > gnuplot> show locale
> > > 
> > >         LC_CTYPE is en_US.UTF-8
> > >         LC_TIME is C
> 
> This is puzzling.
> 
> 1) If LC_CTYPE is en_US.UTF-8 then g_get_charset should certainly 
> return UTF-8, which it is not doing in the cairo driver.
> 
> 2) How did LC_CTYPE _get_ to be equal to en_US.UTF-8 at this point 
> in execution, when the only command that has been issued is "show 
> locale"? 

Puzzling indeed.  With the help of many trace statements, I find that
the locale is loaded during the first call to readline_ipc() in rlgets(),
which is itself called from gp_get_string(). The body of this routine is listed below:

  /* get a line from stdin, and display a prompt if interactive */
  static char*
  gp_get_string(char * buffer, size_t len, const char * prompt)
  {
  # if defined(READLINE) || defined(HAVE_LIBREADLINE)
    if (interactive)
        return rlgets(buffer, len, prompt);
#              ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    else
        return fgets_ipc(buffer, len);
  # else /* !(READLINE || HAVE_LIBREADLINE) */
    if (interactive)
        PUT_STRING(prompt);

    return GET_STRING(buffer, len);
  # endif /* !(READLINE || HAVE_LIBREADLINE) */
  }

So we see that the use of this input path depends on the setting of "interactive"
and the presence/absence of READLINE support.

> 3) Anyway, by the time you plot a graph using cairo the LC_CTYPE 
> setting has reverted to "C".  I've verified that by sticking a 
> print before the g_get_charset() invocation:

I can't reproduce that. Once the locale gets set, it sticks.  As you would expect.


I am thinking that regardless of any possible bugs in the cairo processing,
we should be consistent and always call setlocale(LC_CTYPE,"").

Can anyone see a problem if we load the locale from the environment immediately
on program entry?


-- 
Ethan A Merritt

Re: pngcairo: suggestion for additional option

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

On Fri, 23 Nov 2007, Ethan A Merritt wrote:

> On Friday 23 November 2007 16:56, pl...@pi... wrote:
> > On Sat, 24 Nov 2007 01:24:09 +0100, Allin Cottrell <cot...@wf...>  
> > wrote:
> > >
> > > gp_cairo.h: #define GP_CAIRO_SCALE 20
> > >
> > 
> > So you should probalby be using the named const not a number.
> 
> No core routine should be peering into the code of individual 
> terminal drivers, nor making terminal-specific decisions.

Granted.  I'm attaching a set of 3 small patches that, I hope, 
jointly do the job in a reasonably elegant way.

1) term_api.h is modified to add another term->foo function, 
namely term_scale, which (if applicable) retrieves a 
terminal-specific scale factor such as the oversampling_scale
in pngcairo.

2) cairo.trm (pngcairo variant) is modified to provide that 
function, which simply returns the oversampling scale.

3) eval.c is modified as per my previous suggestion, as amended by 
you.  That is, update_gpval_variables(), for context = 1, is 
augmented to call the new function update_plot_bounds(), which 
defines the 4 variables TERM_XMIN, TERM_XMAX, TERM_YMIN and 
TERM_YMAX.  The initial values to fill out these variables come 
via the map_position() function.  We then test to see if the 
current term offers a term_scale function, and if so we use this 
to modify the values before recording them.

This way every terminal writes entries for TERM_XMIN et al, with 
the option for the maintainer of the terminal to add a scale 
factor function if that makes sense (e.g. to convert to pixels).

You suggested this sort of thing might be done on a per-terminal 
basis via the term->text function.  I thought about that, but it 
would seem to create a potential problem.  Suppose I plot using 
(say) pngcairo and the TERM_* values are set.  Then I plot again 
using some other terminal, and these values are not touched.  Now 
I'm going to get stale state information from the TERM_* 
variables.

Also, the basic bounds calculation can easily be done in the core, 
hence avoiding needless duplication of code at the terminal level.

Allin Cottrell

patch for gp_cairo.c -- use g_utf8_validate

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

Here's a tiny patch that avoids erroneous conversions from 
valid UTF-8 strings (and saves a bunch of function calls if the 
input strings are already valid)

--
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: cairo and character encoding issues (once more)

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

On Fri, 23 Nov 2007, Allin Cottrell wrote:

> On Fri, 23 Nov 2007, Ethan A Merritt wrote:
> > 
> > > lascaux [1235] ./gnuplot...
> > 
> > > gnuplot> show locale
> > > 
> > >         LC_CTYPE is en_US.UTF-8
> > >         LC_TIME is C
> 
> This is puzzling...

Still puzzling, but here's a hint: LC_CTYPE is registered 
correctly, as above, only in interactive mode.  If you put "show 
locale" into a command file and run gnuplot on it, you'll see

 LC_CTYPE is C

in an en_US.UTF-8 environment.

Allin Cottrell

Re: cairo and character encoding issues

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

On Friday 23 November 2007 18:21, Allin Cottrell wrote:
> > >      setlocale (LC_ALL, "");
> > 
> > Isn't there one already?
> > Or at any rate a call to setlocale(LC_CTYPE, "")?  
> > When I enter gnuplot it correctly knows about the locale:
> > 
> > lascaux [1235] ./gnuplot...
> 
> > gnuplot> show locale
> > 
> >         LC_CTYPE is en_US.UTF-8
> >         LC_TIME is C
> 
> That's what I see here too, but g_get_charset(), called in 
> gp_cairo.c, is getting ANSI_X3.4-1968 (ascii).  

Something is broken, it seems. But I really don't know what.

> The GLib reference says,
> "A number of interfaces in GLib depend on the current locale in 
> which an application is running. Therefore, most GLib-using 
> applications should call setlocale (LC_ALL, "")

We most definitely do not want LC_ALL, as that will mess with
the time/date and numerical formats also.  We have separate
commands to load LC_TIME and LC_NUMERIC. 

> I tried sticking that exact invocation into gp_cairo.c, prior to 
> the call to g_get_charset, and the latter then found UTF-8 OK.

Possibly that pins down the brokeness.
Setting LC_CTYPE should do exactly what we want - set the character encoding.
But LC_ALL may be [incorrectly] required by some library instead of the more
specific LC_CTYPE?


-- 
Ethan A Merritt

Re: cairo and character encoding issues

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

On Fri, 23 Nov 2007, Ethan A Merritt wrote:
> 
> > lascaux [1235] ./gnuplot...
> 
> > gnuplot> show locale
> > 
> >         LC_CTYPE is en_US.UTF-8
> >         LC_TIME is C

This is puzzling.

1) If LC_CTYPE is en_US.UTF-8 then g_get_charset should certainly 
return UTF-8, which it is not doing in the cairo driver.

2) How did LC_CTYPE _get_ to be equal to en_US.UTF-8 at this point 
in execution, when the only command that has been issued is "show 
locale"? 

I can't see any invocation of setlocale(LC_CTYPE, "") in src/*.c 
other than in the default response to the command "set locale".

3) Anyway, by the time you plot a graph using cairo the LC_CTYPE 
setting has reverted to "C".  I've verified that by sticking a 
print before the g_get_charset() invocation:

fprintf(stderr, "gp_cairo_get_encoding: LC_CTYPE is %s\n", 
        setlocale(LC_CTYPE, NULL));

-> gp_cairo_get_encoding: LC_CTYPE is C

Allin Cottrell

Re: cairo and character encoding issues

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

On Fri, 23 Nov 2007, Ethan A Merritt wrote:

> > * The function gp_cairo_get_encoding() doesn't work properly 
> > unless the right encoding has been set explicitly by the user. The 
> > fallback in that function is g_get_charset(), but this won't do 
> > anything useful, in the sense of identifying the character set 
> > actually in use on the given system, unless there has been a prior 
> > call 
> >      setlocale (LC_ALL, "");
> 
> Isn't there one already?
> Or at any rate a call to setlocale(LC_CTYPE, "")?  
> When I enter gnuplot it correctly knows about the locale:
> 
> lascaux [1235] ./gnuplot...

> gnuplot> show locale
> 
>         LC_CTYPE is en_US.UTF-8
>         LC_TIME is C

That's what I see here too, but g_get_charset(), called in 
gp_cairo.c, is getting ANSI_X3.4-1968 (ascii).  The GLib reference 
says,

"A number of interfaces in GLib depend on the current locale in 
which an application is running. Therefore, most GLib-using 
applications should call setlocale (LC_ALL, "") to set up the 
current locale."

I tried sticking that exact invocation into gp_cairo.c, prior to 
the call to g_get_charset, and the latter then found UTF-8 OK.

Allin Cottrell

Re: cairo and character encoding issues

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

On Nov 24, 2007 3:12 AM, Ethan A Merritt wrote:
> > * The function gp_cairo_get_encoding() doesn't work properly
> > unless the right encoding has been set explicitly by the user. The
> > fallback in that function is g_get_charset(), but this won't do
> > anything useful, in the sense of identifying the character set
> > actually in use on the given system, unless there has been a prior
> > call
> >      setlocale (LC_ALL, "");
>
> Isn't there one already?
> Or at any rate a call to setlocale(LC_CTYPE, "")?
> When I enter gnuplot it correctly knows about the locale:
>
> lascaux [1235] ./gnuplot
>
>         G N U P L O T
>         Version 4.3 patchlevel CVS-21Nov2007
>         last modified Wed Nov 21 19:43:57 PST 2007
>         System: Linux 2.6.12-24mdksmp
>
>         Copyright (C) 1986 - 1993, 1998, 2004, 2007
>         Thomas Williams, Colin Kelley and many others
>
>         Type `help` to access the on-line reference manual.
>         The gnuplot FAQ is available from
>                 http://www.gnuplot.info/faq/
>
>         Send comments and help requests to  <gnu...@li...>
>         Send bug reports and suggestions to <gnu...@li...>
>
>
> Terminal type set to 'wxt'
> gnuplot> show locale
>
>         LC_CTYPE is en_US.UTF-8
>         LC_TIME is C
>
> But we have at least one bug report from somewhere who is having
> trouble getting gnuplot to pull LC_CTYPE from the environment, so I'm
> not really sure what is going on.

Here I have:

> locale
LANG=
LC_COLLATE="sl_SI.UTF-8"
LC_CTYPE="sl_SI.UTF-8"
LC_MESSAGES="sl_SI.UTF-8"
LC_MONETARY="sl_SI.UTF-8"
LC_NUMERIC="sl_SI.UTF-8"
LC_TIME="sl_SI.UTF-8"
LC_ALL="sl_SI.UTF-8"

(I set those in .bash_profile)

> gnuplot

        G N U P L O T
        Version 4.3 patchlevel 0
        last modified February 2007
        System: Darwin 8.11.1

        Copyright (C) 1986 - 1993, 1998, 2004, 2007
        Thomas Williams, Colin Kelley and many others

        Type `help` to access the on-line reference manual.
        The gnuplot FAQ is available from
                http://www.gnuplot.info/faq/

        Send comments and help requests to  <gnu...@li...>
        Send bug reports and suggestions to <gnu...@li...>


Terminal type set to 'aqua'
gnuplot> show locale

        LC_CTYPE is C
        LC_TIME is C
        LC_NUMERIC is C

gnuplot>

Mojca

Re: cairo and character encoding issues

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

On Friday 23 November 2007 17:27, Allin Cottrell wrote:
> I believe there are a couple of things not quite right with the 
> encoding to UTF-8 in the context of the cairo-based terminals.
> I'd suggest that conversion  should be conditional on failure of
> g_utf8_validate() on the string in question.

Could be.


> * The function gp_cairo_get_encoding() doesn't work properly 
> unless the right encoding has been set explicitly by the user. The 
> fallback in that function is g_get_charset(), but this won't do 
> anything useful, in the sense of identifying the character set 
> actually in use on the given system, unless there has been a prior 
> call 
>      setlocale (LC_ALL, "");

Isn't there one already?
Or at any rate a call to setlocale(LC_CTYPE, "")?  
When I enter gnuplot it correctly knows about the locale:

lascaux [1235] ./gnuplot

        G N U P L O T
        Version 4.3 patchlevel CVS-21Nov2007
        last modified Wed Nov 21 19:43:57 PST 2007
        System: Linux 2.6.12-24mdksmp

        Copyright (C) 1986 - 1993, 1998, 2004, 2007
        Thomas Williams, Colin Kelley and many others

        Type `help` to access the on-line reference manual.
        The gnuplot FAQ is available from
                http://www.gnuplot.info/faq/

        Send comments and help requests to  <gnu...@li...>
        Send bug reports and suggestions to <gnu...@li...>


Terminal type set to 'wxt'
gnuplot> show locale

        LC_CTYPE is en_US.UTF-8
        LC_TIME is C

But we have at least one bug report from somewhere who is having 
trouble getting gnuplot to pull LC_CTYPE from the environment, so I'm
not really sure what is going on.


-- 
Ethan A Merritt

cairo and character encoding issues

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

I believe there are a couple of things not quite right with the 
encoding to UTF-8 in the context of the cairo-based terminals.

* In gp_cairo_convert() (gp_cairo.c) there's an *unconditional* 
conversion of an input string, from the charset returned by 
gp_cairo_get_encoding() to UTF-8.  I'd suggest that conversion 
should be conditional on failure of g_utf8_validate() on the 
string in question.

Rationale: the supposed source charset may not be correct (see 
below).  If the string validates as UTF-8 it should be passed as 
is.  You get bamboozling error messages if g_convert() is called 
on a string that's already in UTF-8, but is misrepresented as 
being in some other encoding.

* The function gp_cairo_get_encoding() doesn't work properly 
unless the right encoding has been set explicitly by the user. The 
fallback in that function is g_get_charset(), but this won't do 
anything useful, in the sense of identifying the character set 
actually in use on the given system, unless there has been a prior 
call

setlocale (LC_ALL, "");

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: pngcairo: suggestion for additional option

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

On Friday 23 November 2007 16:56, pl...@pi... wrote:
> On Sat, 24 Nov 2007 01:24:09 +0100, Allin Cottrell <cot...@wf...>  
> wrote:
> >
> > gp_cairo.h: #define GP_CAIRO_SCALE 20
> >
> 
> So you should probalby be using the named const not a number.

No core routine should be peering into the code of individual terminal
drivers, nor making terminal-specific decisions.  If it is necessary to 
get additional information from the terminal, it should either be
returned by one of the terminal entry routines term->foo()  or be
exported directly in the terminal table analogous to term->xmax and
term-ymax.

But please also think of alternative ways to accomplish this.
For instance, instead of setting these GPVAL_GRAPH_XMIN values from a
core routine, how about the driver setting them as part of the
term->text() processing?  In that case we might want to start up a 
new series of exported variable names.  We already have GPVAL_*, MOUSE_*,
and FIT_*.  These could be TERM_* or AXISCALE_* or something like that.


-- 
Ethan A Merritt

Re: pngcairo: suggestion for additional option

[<pl...@pi...>]

On Sat, 24 Nov 2007 01:24:09 +0100, Allin Cottrell <cot...@wf...>  
wrote:

> On Fri, 23 Nov 2007, Allin Cottrell wrote:
>
>> On Thu, 22 Nov 2007, Ethan A Merritt wrote:
>
>> > Where did the magic number 20 come from?
>>
>> The cairo code seems to deal in units of 1/20 of a pixel...
>
> Found the source:
>
> gp_cairo.h: #define GP_CAIRO_SCALE 20
>
> See also plot->oversampling_scale in gp_cairo.c.
>
> Allin Cottrell
>

So you should probalby be using the named const not a number.

Nice work.

Peter.

Re: pngcairo: suggestion for additional option

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

On Fri, 23 Nov 2007, Allin Cottrell wrote:

> On Thu, 22 Nov 2007, Ethan A Merritt wrote:

> > Where did the magic number 20 come from?
> 
> The cairo code seems to deal in units of 1/20 of a pixel...

Found the source:

gp_cairo.h: #define GP_CAIRO_SCALE 20

See also plot->oversampling_scale in gp_cairo.c.

Allin Cottrell

Re: pngcairo: suggestion for additional option

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

On Thu, 22 Nov 2007, Ethan A Merritt wrote:

> On Thursday 22 November 2007 08:19, Allin Cottrell wrote:
> > 
> > I'm attaching a small patch to eval.c that implements 
> > GPVAL_GRAPH_XMIN, GPVAL_GRAPH_XMAX, GPVAL_GRAPH_YMIN and 
> > GPVAL_GRAPH_YMAX. In the context of bitmapped output, these values 
> > should represent the pixel coordinates of the actual graph area.
> > 
> > Those more familiar than I with the gnuplot architecture will no 
> > doubt be able to see if there's a better way of doing this.
> 
> >--- eval.c.orig	2007-11-22 10:16:05.000000000 -0500
> >+++ eval.c	2007-11-22 11:05:46.000000000 -0500
> >@@ -733,6 +733,39 @@
> >     Gstring(&v->udv_value, gp_strdup(stringvalue));
> > }
> > 
> >+static void update_plot_bounds (void)
> >+{
> >+    int xl = plot_bounds.xleft;
> >+    int xr = plot_bounds.xright;
> >+    int yb = plot_bounds.ybot;
> >+    int yt = plot_bounds.ytop;
> 
> I think that has to be 
> 
>     unsigned int xl, xr, yb, yt;
>     struct position bottom_left = {graph, graph, graph, 0., 0., 0.};
>     struct position upper_right = {graph, graph, graph, 1., 1., 1.};
> 
>     map_position(&bottom_left, &xl, &yb, "");
>     map_position(&upper_right, &xr, &yt, "");

OK, I'll take your word for that!

> >+    if (term != NULL && !strcmp(term->name, "pngcairo")) {
> >+        /* convert to pixels */
> >+	xl /= 20;
> >+	xr /= 20;
> >+	yb /= 20;
> >+	yt /= 20;
> 
> Where did the magic number 20 come from?

The cairo code seems to deal in units of 1/20 of a pixel.  Note 
that in mouse.c we have, e.g.:

  mv_mouse_x = term->xmax / 20;

However, if something like the above assignment to 
GPVAL_GRAPH_XMIN et al is acceptable, I'd be happy even if no 
conversion to pixels is done -- that is, if the numbers are just 
whatever comes out of map_position().

Allin Cottrell

Re: pngcairo: suggestion for additional option

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

On Thursday 22 November 2007 08:19, Allin Cottrell wrote:
> 
> I'm attaching a small patch to eval.c that implements 
> GPVAL_GRAPH_XMIN, GPVAL_GRAPH_XMAX, GPVAL_GRAPH_YMIN and 
> GPVAL_GRAPH_YMAX. In the context of bitmapped output, these values 
> should represent the pixel coordinates of the actual graph area.
> 
> Those more familiar than I with the gnuplot architecture will no 
> doubt be able to see if there's a better way of doing this.

>--- eval.c.orig	2007-11-22 10:16:05.000000000 -0500
>+++ eval.c	2007-11-22 11:05:46.000000000 -0500
>@@ -733,6 +733,39 @@
>     Gstring(&v->udv_value, gp_strdup(stringvalue));
> }
> 
>+static void update_plot_bounds (void)
>+{
>+    int xl = plot_bounds.xleft;
>+    int xr = plot_bounds.xright;
>+    int yb = plot_bounds.ybot;
>+    int yt = plot_bounds.ytop;

I think that has to be 

    unsigned int xl, xr, yb, yt;
    struct position bottom_left = {graph, graph, graph, 0., 0., 0.};
    struct position upper_right = {graph, graph, graph, 1., 1., 1.};

    map_position(&bottom_left, &xl, &yb, "");
    map_position(&upper_right, &xr, &yt, "");

>+    if (term != NULL && !strcmp(term->name, "pngcairo")) {
>+        /* convert to pixels */
>+	xl /= 20;
>+	xr /= 20;
>+	yb /= 20;
>+	yt /= 20;

Where did the magic number 20 come from?
If we need terminal-specific code in core routines, this approach isn't
going to work.  We would have to export addition information from the
terminals, probably from term->text().  But I'm not sure we need this at all.

-- 
Ethan A Merritt

Re: pngcairo: suggestion for additional option

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

On Wed, 21 Nov 2007, Ethan Merritt wrote:

(about extracting bounds information from gnuplot, e.g. for a PNG 
file)

> I believe the suggestion was that one could achieve this by the
> following lines:
> 
>   set print "plot_coords.dat"
>   print "x limits: ", GPVAL_X_MIN, GPVAL_X_MAX
>   print "x2 limits: ", GPVAL_X2_MIN, GPVAL_X2_MAX
>   print "y limits: ", GPVAL_Y_MIN, GPVAL_Y_MAX
>   print "y2 limits: ", GPVAL_Y2_MIN, GPVAL_Y2_MAX
>   print "graph limits: ", GPVAL_GRAPH_XMIN, GPVAL_GRAPH_XMAX
>   ... and so on

I'm attaching a small patch to eval.c that implements 
GPVAL_GRAPH_XMIN, GPVAL_GRAPH_XMAX, GPVAL_GRAPH_YMIN and 
GPVAL_GRAPH_YMAX. In the context of bitmapped output, these values 
should represent the pixel coordinates of the actual graph area.

Those more familiar than I with the gnuplot architecture will no 
doubt be able to see if there's a better way of doing this.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: pngcairo: suggestion for additional option

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

On Wednesday 21 November 2007 23:33, Timoth=C3=A9e Lecomte wrote:
> pl...@pi... a =C3=A9crit :
> > On Wed, 21 Nov 2007 23:40:35 +0100, Hans-Bernhard Br=C3=B6ker =20
> > <HBB...@t-...> wrote:
> >  =20
> >> gnuplot cannot  possibly write the closing tags if you didn't tell it =
=20
> >> you're done with writing to the file.=20
> >
> > Well it could _possibly_ write the closing tags temporarily as I sugges=
ted =20
> > and remove them later if/when further output occured. Maybe you did not=
 =20
> > read that part of my post.
> >  =20
> I like this idea very much. This kind of "lazy file closing" would be a=20
> good time saver.

That would prevent using a pipe for output.  I do not use the TeX
terminals normally, so I don't know if piped output is relevant to these.
Certainly it is a very common case for png, svg, and postscript (eps).


=2D-=20
Ethan A Merritt

Re: pngcairo: suggestion for additional option

[<tim...@lp...>]

pl...@pi... a écrit :
> On Wed, 21 Nov 2007 23:40:35 +0100, Hans-Bernhard Bröker  
> <HBB...@t-...> wrote:
>
>   
>> gnuplot cannot  possibly write the closing tags if you didn't tell it  
>> you're done with writing to the file.
>>     
>
> Well it could _possibly_ write the closing tags temporarily as I suggested  
> and remove them later if/when further output occured. Maybe you did not  
> read that part of my post.
>
>   
I like this idea very much. This kind of "lazy file closing" would be a 
good time saver.

Best regards,

Timothée

Re: pngcairo: suggestion for additional option

[<pl...@pi...>]

On Wed, 21 Nov 2007 23:40:35 +0100, Hans-Bernhard Bröker  
<HBB...@t-...> wrote:

> pl...@pi... wrote:
>
>>    One thing I've often wanted on working with SVG is a means to get a   
>> readable file at the end of a plot command without having to unset   
>> terminal to write out the xml terminators and close the file.
>
> Unsetting the terminal is completely unnecessary.  You will have to  
> close the plot though, i.e. "unset output".

I beg you pardon, I was meaning unset output not unset terminal. This does  
not affect crux of what I was suggesting. It is the need to close the file  
for it to become parsable, that remains the same.

> gnuplot cannot  possibly write the closing tags if you didn't tell it  
> you're done with writing to the file.

Well it could _possibly_ write the closing tags temporarily as I suggested  
and remove them later if/when further output occured. Maybe you did not  
read that part of my post.

>
>> For example , if I output to jpeg or png, I get a readable file after  
>> the  plot command. With svg I dont.
>
> The reason for the difference is that JPEG only allows one page per  
> file, SVG allows as many as you wish.

Yes precisely, that's why it may be useful to produce intermidiate svg  
output in a readable state.

>
>> Would it make sense to have gnuplot terminate the unmatched tags until  
>> a  further command is given in either of the following cases:
>>  1/ end of .gnu file input from load "filename" . If svg terminal is  
>> still  open , close unmatched tags.
>
> Absolutely no.  Not all loaded scripts end the output file.

Again, you've misread the main point of my post that this should be  
reversible.
If three lines of closing tags were needed these simply get chopped off  
again and output continues.

>
>> 2/ interactive use after plot command close tags while awaiting  
>> further  input.
>
> Absolutely no, for basically the same reason.
>

Absolutely possible , for basically the same reason.

It may be helpful if you reread the parts of my previous post that you  
chose not to quote, before replying.

regards, Peter.

small help bug

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

"help variables" produces some information, at the foot of which 
it says:

See `show functions`, `functions`, `gnuplot-defined variables`, 
`macros`.

However:

gnuplot> help gnuplot-defined variables
Sorry, no help for 'gnuplot-defined variables variables'

Plain "help gnuplot-defined" works OK.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: Strange interaction between epslatex and wxt???

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

Yes, you are right. That does work and
flushes the remainders to file.

Still, this is only necessary when I had 
used wxt before - which seems to be
undesirable behaviour. 

(Certainly not the highest priority bug in
the world, although it took me quite a 
while to figure out exactly WHAT went 
wrong for me with epslatex. Now at least
it is documented...)

Best,

		Ph.


On Wednesday 21 November 2007 01:12, Richard Henwood wrote:
> Philipp K. Janert wrote:
> > I made a mistake when pasting the gnuplot
> > session in the previous email. The problem is
> > NOT a missing "replot" command. Let me try
> > again - as you can see the problem is specific
> > to a plot to wxt preceding the plot to epslatex.
> > It does not happen when plotting to X11 first.
> >
> > ===================================
> > Bad Session:
> >
> > Terminal type set to 'wxt'
> > gnuplot> plot sin(x)
> > gnuplot> set t epslatex standalone
> > Terminal type set to 'epslatex'
> > Options are '   leveldefault monochrome blacktext \
> >    dashed dashlength 1.0 linewidth 1.0 butt \
> >    palfuncparam 2000,0.003 \
> >    noheader "" 11 '
> > gnuplot> set o "broken.tex"
> > gnuplot> replot
>
> at this point, maybe you could try:
> gnuplot> set output
> which will tell gnuplot to finalise all the open file(s).
>
> r,
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: pngcairo: suggestion for additional option

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

On Wed, 21 Nov 2007, Ethan Merritt wrote:

> On Wednesday 21 November 2007 16:01, Allin Cottrell wrote:
> > 
> > > Version 4.2.2 has quite a lot of this already your finger tips, 
> > > by way of gnuplot-defined variables GPVAL_X_MIN etc.  Adding 
> > > GRAPH_XLEFT etc. shouldn't pose a major problem.
> > 
> > Sorry, I don't really understand.  There's no difficulty at all 
> > calculating/retrieving this information inside gnuplot.  The issue 
> > is how to make it available to the outside world -- that is, to 
> > another program that has called gnuplot to make a plot file, and 
> > wants to know some internal properties of the file.
> 
> I believe the suggestion was that one could achieve this by the
> following lines:
> 
>   set print "plot_coords.dat"
>   print "x limits: ", GPVAL_X_MIN, GPVAL_X_MAX
>   print "x2 limits: ", GPVAL_X2_MIN, GPVAL_X2_MAX
>   print "y limits: ", GPVAL_Y_MIN, GPVAL_Y_MAX
>   print "y2 limits: ", GPVAL_Y2_MIN, GPVAL_Y2_MAX
>   print "graph limits: ", GPVAL_GRAPH_XMIN, GPVAL_GRAPH_XMAX
>   ... and so on

where GPVAL_GRAPH_XMIN and friends are still to be added?

OK, this looks promising.  

Allin Cottrell

Re: pngcairo: suggestion for additional option

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

On Wednesday 21 November 2007 16:01, Allin Cottrell wrote:
> 
> > Version 4.2.2 has quite a lot of this already your finger tips, 
> > by way of gnuplot-defined variables GPVAL_X_MIN etc.  Adding 
> > GRAPH_XLEFT etc. shouldn't pose a major problem.
> 
> Sorry, I don't really understand.  There's no difficulty at all 
> calculating/retrieving this information inside gnuplot.  The issue 
> is how to make it available to the outside world -- that is, to 
> another program that has called gnuplot to make a plot file, and 
> wants to know some internal properties of the file.

I believe the suggestion was that one could achieve this by the
following lines:

  set print "plot_coords.dat"
  print "x limits: ", GPVAL_X_MIN, GPVAL_X_MAX
  print "x2 limits: ", GPVAL_X2_MIN, GPVAL_X2_MAX
  print "y limits: ", GPVAL_Y_MIN, GPVAL_Y_MAX
  print "y2 limits: ", GPVAL_Y2_MIN, GPVAL_Y2_MAX
  print "graph limits: ", GPVAL_GRAPH_XMIN, GPVAL_GRAPH_XMAX
  ... and so on

In other words, no need for a special terminal option.
The existing print mechanism would allow flexibility as to
file format and exactly what information is saved.

-- 
Ethan A Merritt

Re: pngcairo: suggestion for additional option

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

On Wed, 21 Nov 2007, Hans-Bernhard Bröker wrote:

> Allin Cottrell wrote:
> > I'll float this by the list first and submit a tracker item if there's any
> > support.
> 
> No need to.  There's been an item open for ages about this...

OK, but then nothing has happened about this.  I'm now proposing 
what seems to me a minimalistic solution that shouldn't disturb 
the existing codebase.

> More abstractly speaking, what these requests are about is a 
> very rough approximation of on aspect of mouse interaction: 
> coordinate mapping back to data values for static bitmap 
> terminal drivers.

Why would it be a "very rough approximation", if you know the 
pixel bounds of the actual plot area in the bitmap graphic, and 
the data bounds of the plot?  Pixels are discrete, of course, but 
the approximation should be pretty good if we have hundreds of 
pixels in both dimensions.

> Version 4.2.2 has quite a lot of this already your finger tips, 
> by way of gnuplot-defined variables GPVAL_X_MIN etc.  Adding 
> GRAPH_XLEFT etc. shouldn't pose a major problem.

Sorry, I don't really understand.  There's no difficulty at all 
calculating/retrieving this information inside gnuplot.  The issue 
is how to make it available to the outside world -- that is, to 
another program that has called gnuplot to make a plot file, and 
wants to know some internal properties of the file.

Allin Cottrell

Re: box fill bug in emf.trm

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

On Wed, 21 Nov 2007, Ethan Merritt wrote:

> On Wednesday 21 November 2007 11:17, Ethan Merritt wrote:
> > On Wednesday 21 November 2007 08:38, Allin Cottrell wrote:
> > > There's a bug in emf.trm, on line 836 in current CVS
> > 
> > Huh. I remember that bug.  I thought it was fixed already.
> 
> Indeed. Here is the previous exchange:
> 
> > On Tuesday 09 October 2007 04:50, Dr. Johannes Zellner wrote:
> >> Hello,
> >> 
> >> The line term/emf.trm. around line 836
> >> 
> >>     emf_color = color;
> >> 
> >> is wrong and should be removed in my opinion. 

> I thought Johannes went ahead and fixed it, but maybe not.
> Fixed now.

OK, thanks.  I too thought that had been handled earlier.

Allin Cottrell