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

Re: word(s) patch

[Juergen W. <wie...@fr...>]

Am Montag, 4. Juli 2005 20:38 schrieb Ethan A Merritt:
> On Monday 04 July 2005 01:10 am, you wrote:
> > Secondly, and probably too late: word("s t r i n g", 1) fishes the
> > first word ("s"), while substr("string",1,1) returns the second
> > letter.  I think both indices should start at the same value.
> > Don't know how to solve this.
>
> I don't know either.  Perhaps I should just remove the substr()
> function altogether.  That would make a clear distinction between
> the operation  STRING[beg:end]  (uses C-language indexing from 0)
> and the function calls like word(STRING,N)  (uses rexx or fortran
> indexing starting from 1).

Well, STRING[beg:end] is not exactly C syntax.  The bracket may be C
style, but the is like Fortran style.  I vote for 1 as start index
even here.

> I don't think it's too late to change these; they've only been
> in CVS for a short time.  The question did come up in discussion,
> but few opinions or answers were offered.  I chose to go with logic
> that if the function name came from a particular environment, rexx
> in the case of word() and words(), it should maintain the indexing
> convention that it was derived from.
>
> But I agree that the substr(beg,end) indexing is confusing, and
> contradicts the awk equivalent  substr(beg,length) regardless
> of whether beg starts at 0 or 1.

It's not that easy to notice that STRING[beg:end] also works on
general string expressions.  And to use it in these cases is not
very elegant.  BTW: What precedence does this operator have.  I
couldn't find it at "help operators".


Juergen

Re: strings and macros

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

On Tuesday 05 July 2005 12:07 pm, Juergen Wieferink wrote:
> Johannes Zellner wrote:
> > 1. A limitation to 80 characters for sprintf really hurts!
>
> Full ACK.

OK, OK.  I've coded it up.  It's ugly but it works.
I'll try to clean it up a bit before adding to cvs. 


> > 2. dynamical macros would be really nice ;-)

Petr and I had this discussion a while back.
I don't see a good way to do it, for exactly the reason you
pointed out - the macro expansion happens before the line has
been tokenized, so we can't use any of our nice tools to check
for function names or evaluate expressions.

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

Re: UTF8 encoding

[Juergen W. <wie...@fr...>]

Am Dienstag, 5. Juli 2005 21:37 schrieb Ethan Merritt:
> As I understand it, a single character glyph may have more than one legal
> representation in UTF-8.  So =C3=A4 =C3=B6 =C3=BC each have a one-byte re=
presentation
> (\344 \366 \374 if the encoding is iso8559-1 or iso8559-15) and also have
> a multibyte unicode representation (C3A4 C3B6 C3BC).

You are probably right.  But that doesn't help me as SuSE9.3 seems
to choose the latter ones.

> gnuplot> show locale
>
>         LC_CTYPE is en_US.UTF-8
>         LC_NUMERIC is C
>         LC_TIME is C
>
> gnuplot> set xlabel "=C3=A4=C3=B6=C3=BC"
> gnuplot> set term png
> Terminal type set to 'png'
> Options are 'nocrop font verdana 12 size 640,480 '
> gnuplot> set output 'test.png'
> gnuplot> plot sin(x)
>
>   (output image attached)

gnuplot> show locale

        LC_CTYPE is de_DE.UTF-8
        LC_NUMERIC is C
        LC_TIME is C

gnuplot> set xlabel "=C3=A4=C3=B6=C3=BC"
gnuplot> set term png
Terminal type set to 'png'
Options are 'nocrop medium size 640,480 '
gnuplot> set output 'test.png'
gnuplot> plot sin(x)

But it may also be a missing font in gdlib.


Juergen

Re: strings and macros

[Dave D. <dde...@es...>]

Juergen Wieferink <wie...@fr...> writes:

> Johannes Zellner wrote:
>> 1. A limitation to 80 characters for sprintf really hurts!
>
> Full ACK.  
>
>> 2. dynamical macros would be really nice ;-)
>>
>>     set macros
>>     pl(x) = sprintf("plot '<extract -n %s' u 2, '<extract -n -f %s' u 3",\
>>                     x, x)
>>     @pl("myfile.dat")
>

This particular case can probably be handled using 'call'.

> The hardest part in your suggestion would be to construct the
> function call.  OTOH, parsing a constant expression is already
> implemented.  Thus the hardest part would be to terminate the
> expression correctly.
>
> How about:
> gnuplot> set macros {expressions}
> gnuplot> pl(x) = ...
> gnuplot> @@pl("myfile.dat")@@
>
> The "@@" syntax would have the additional advantages of backwards
> compatibility and that you could use a general expression, not only
> single functions.
>

I've suggested 'eval string-expr'  in the past, to be like sh, perl, etc.


>
> A few minutes later:
> Arrgh!  At the time string_expand() is called, the input line has not
> yet been tokenized.
>
> Is there any possibility to tokenize and parse a string not on the
> input line?
>

I think replot is implemented by building up a new input line and
retokenising.


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: Key layout

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Tuesday 05 July 2005 11:56 am, Daniel J Sebald wrote:
> 
>>I just noticed the key is programmed so that settings are adjusted immediately upon interpretation.  Thus if there is a syntax error in a line, settings up to that error will be changed.
>>
>>Isn't it preferable that nothing be changed until the whole line is verified as valid?
> 
> 
> Not really. Why would it be?
> I think I'd rather get as much of my command as possible, even if the last option has a typo.

I don't know, there's just something random about a portion of a line being processed.

If there is an error, I'm not likely going to think "Alright, now which properties changed?  And which do I have left to change?"  Rather, I think most people have a habit of hitting the up arrow to recall the last line and fix it (or just fix the line in a script file) then rerun the command.

I'll leave it as is.

The other side of the coin is someone types in a command with "exploratory syntax" to see if something works, an error results, the user decides it is fine as is, yet some parameter has changed.

Dan

Re: UTF8 encoding

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

On Tuesday 05 July 2005 12:03 pm, Juergen Wieferink wrote:
> Harald Harders wrote:
> > If I remember correctly, the low byte of UTF-8 is identical with either
> > latin1 or latin9. Thus, using =BBset encoding iso_8859_1=AB should also=
 work
> > with UTF-8 (and in fact it worked for me today at work) as long as you
> > don't use characters above \377.
>=20
> But aren't the umlauts "=E4=F6=FC" multibyte characters in UTF-8? =20

As I understand it, a single character glyph may have more than one legal
representation in UTF-8.  So =E4 =F6 =FC each have a one-byte representation
(\344 \366 \374 if the encoding is iso8559-1 or iso8559-15) and also have
a multibyte unicode representation (C3A4 C3B6 C3BC).


> This is=20
> at least what hexdump says to sample files.  And I can say
> empirically that it doesn't work to just use UTF-8 scripts
> containing umlauts with gnuplot -- at least with SuSE9.3.

gnuplot> show locale

        LC_CTYPE is en_US.UTF-8
        LC_NUMERIC is C
        LC_TIME is C

gnuplot> set xlabel "=E4=F6=FC"
gnuplot> set term png
Terminal type set to 'png'
Options are 'nocrop font verdana 12 size 640,480 '
gnuplot> set output 'test.png'
gnuplot> plot sin(x)

  (output image attached)


=2D-=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: strings and macros

[Juergen W. <wie...@fr...>]

Johannes Zellner wrote:
> 1. A limitation to 80 characters for sprintf really hurts!

Full ACK.  

> 2. dynamical macros would be really nice ;-)
>
>     set macros
>     pl(x) = sprintf("plot '<extract -n %s' u 2, '<extract -n -f %s' u 3",\
>                     x, x)
>     @pl("myfile.dat")

The hardest part in your suggestion would be to construct the
function call.  OTOH, parsing a constant expression is already
implemented.  Thus the hardest part would be to terminate the
expression correctly.

How about:
gnuplot> set macros {expressions}
gnuplot> pl(x) = ...
gnuplot> @@pl("myfile.dat")@@

The "@@" syntax would have the additional advantages of backwards
compatibility and that you could use a general expression, not only
single functions.

...

A few minutes later:
Arrgh!  At the time string_expand() is called, the input line has not
yet been tokenized.

Is there any possibility to tokenize and parse a string not on the
input line?


Juergen

Re: UTF8 encoding

[Juergen W. <wie...@fr...>]

Harald Harders wrote:
> If I remember correctly, the low byte of UTF-8 is identical with either
> latin1 or latin9. Thus, using =BBset encoding iso_8859_1=AB should also w=
ork
> with UTF-8 (and in fact it worked for me today at work) as long as you
> don't use characters above \377.

But aren't the umlauts "=E4=F6=FC" multibyte characters in UTF-8?  This is
at least what hexdump says to sample files.  And I can say
empirically that it doesn't work to just use UTF-8 scripts
containing umlauts with gnuplot -- at least with SuSE9.3.

> > So my question:  Is it possible to add UTF to "set encoding"?  At
> > least for the postscript terminal?  What does the postscript
> > standard say about UTF?
>
> Postscript can only handle 255 characters per font encoding. Thus, it does
> not work with UTF-8. It may be possible to add a second and third encoding
> that contains the encoding vectors for UTF-8 fonts. Thus, 255 characters
> will be put into one font. E.g., /Times-Roman, /Times-Roman-1,
> /Times-Roman-2. But this is just theoretical, not yet implemented in
> gnuplot.

Oh dear.  I have spent so much time on all this font/encoding stuff.
And I still feel like a complete beginner.  But thank all of you for
your explanations.


Juergen

Re: Key layout

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

On Tuesday 05 July 2005 11:56 am, Daniel J Sebald wrote:
> I just noticed the key is programmed so that settings are adjusted immediately upon interpretation.  Thus if there is a syntax error in a line, settings up to that error will be changed.
> 
> Isn't it preferable that nothing be changed until the whole line is verified as valid?

Not really. Why would it be?
I think I'd rather get as much of my command as possible, even if the last option has a typo.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Key layout

[Daniel J S. <dan...@ie...>]

I just noticed the key is programmed so that settings are adjusted immediately upon interpretation.  Thus if there is a syntax error in a line, settings up to that error will be changed.

Isn't it preferable that nothing be changed until the whole line is verified as valid?  Should I make alterations into a temp key structure then copy that temp key structure to the actual key structure at the end of "set key" line?

Dan

Re: UTF8 encoding

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

On Tuesday 05 July 2005 09:26 am, Robert Hart wrote:
> On Tue, 2005-07-05 at 08:48 -0700, Ethan A Merritt wrote:
>=20
> > My machines all use UTF-8.  It works fine.
>=20
> Are you sure about this?=20

Well, it works for me.

> I see two problems.=20
> 1) Inputting multibyte characters gives problems using backspace and/or
> cursor keys to edit the command.

I use SCIM for multibyte input.  This interface is independent of the
program being used. Yes, there are some operations that may not
work the way you expect, but this has nothing in particular to do with
gnuplot. You just have to learn the conventions of the input layer.


> 2) Actual output shows incorrect characters.
>=20
> e.g.:
>=20
> set xlabel "=E1=E2=E3=E4" font "Verdana"
> show xlabel

Are you sure that you have a UTF-8 version of Verdana?

Is your LC_CTYPE set to a UTF-8 language type appropriate for these
letters?

Which x11 terminal type are you using for input?  The terminal you are
running from needs to support multibyte x11 fonts in order for it to
display properly. For me it works in nxterm, but not in many of the
other xterm clones.  But just because the terminal is too stupid to
display it properly doesn't mean it is incorrectly stored in the program.

> (note I'm trying to set the xlabel to contain greek characters in this
> example)

I cannot comment on this specifically. I have not tried using Greek in
UTF-8, nor do I have any Greek fonts installed.  (Note that the Adobe
and MS Symbol fonts are *not* UTF-8 fonts).  But I have successfully used
Japanese UTF-8 fonts, following the guidelines of Shigeharu Takeno
 http://takeno.iee.niit.ac.jp/~shige/unix/gnuplot/gnuplot.html

When I next get some time, I'll post some examples.


However...

I was wrong to imply that UTF-8 works equally well for all output
terminals. Harald is correct in pointing out that UTF-8 output
in PostScript is far more problematic than in x11 or via libgd.

Harald Harders <h.h...@tu...> wrote >
>> So my question:  Is it possible to add UTF to "set encoding"?  At
>> least for the postscript terminal?  What does the postscript
>> standard say about UTF?
>
> Postscript can only handle 255 characters per font encoding. Thus, it does
> not work with UTF-8. It may be possible to add a second and third encoding
> that contains the encoding vectors for UTF-8 fonts. Thus, 255 characters
> will be put into one font. E.g., /Times-Roman, /Times-Roman-1,
> /Times-Roman-2. But this is just theoretical, not yet implemented in
> gnuplot.

It's a mess.  PostScript 2015  (don't ask me why it seems to have appeared
10 years early :-)  implements a two-layer font decoding mechanism.  One
layer is Adobe's own "CID-keyed font" 16-bit encoding, one is the native
unicode or other multibyte font.  The viewing device must arrange for=20
translation from one encoding to the other, or else the translation table
and conversion routine must be included in the file itself.

A general discussion, particularly with regard to ghostscript is here  =20
   http://www.cs.wisc.edu/~ghost/doc/gnu/7.05/CJK.htm

=2D-=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: UTF8 encoding

[Robert H. <en...@no...>]

On Tue, 2005-07-05 at 08:48 -0700, Ethan A Merritt wrote:

> My machines all use UTF-8.  It works fine.

Are you sure about this? I see two problems.
1) Inputting multibyte characters gives problems using backspace and/or
cursor keys to edit the command.

2) Actual output shows incorrect characters.

e.g.:

set xlabel "=E1=E2=E3=E4" font "Verdana"
show xlabel

        xlabel is "\316\261\316\262\316\263\316\264", offset at
((character units) 0, 0, 0), using font "verdana"

plot sin(x)

This has an xlabel that contains eight glyphs (and not 4), and does not
contain the correct symbols.

(note I'm trying to set the xlabel to contain greek characters in this
example)


--=20
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: UTF8 encoding

[Harald H. <h.h...@tu...>]

J=FCrgen,

> A colleague just asked me how to use Umlauts with gnuplot on his
> box.  As he uses SuSE 9.3, the default encoding is UTF-8.  That
> isn't supported by "set encoding" yet.  So I had to refer to latin1,
> ps_guide.ps and all the funny "\340" octal codes.  That's of course
> far from being convenient.  A more convenient workaround would be to
> switch the encoding within emacs for gnuplot files, but...

If I remember correctly, the low byte of UTF-8 is identical with either
latin1 or latin9. Thus, using =BBset encoding iso_8859_1=AB should also wor=
k
with UTF-8 (and in fact it worked for me today at work) as long as you
don't use characters above \377.

> So my question:  Is it possible to add UTF to "set encoding"?  At
> least for the postscript terminal?  What does the postscript
> standard say about UTF?

Postscript can only handle 255 characters per font encoding. Thus, it does
not work with UTF-8. It may be possible to add a second and third encoding
that contains the encoding vectors for UTF-8 fonts. Thus, 255 characters
will be put into one font. E.g., /Times-Roman, /Times-Roman-1,
/Times-Roman-2. But this is just theoretical, not yet implemented in
gnuplot.

Best regards
Harald

--=20
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: UTF8 encoding

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

On Tuesday 05 July 2005 02:27 am, Juergen Wieferink wrote:
> A colleague just asked me how to use Umlauts with gnuplot on his
> box.  As he uses SuSE 9.3, the default encoding is UTF-8.  That
> isn't supported by "set encoding" yet.  

My machines all use UTF-8.  It works fine.
As I understand it (but I welcome correction if I'm misinterpreting),
the "encoding" in "set encoding" is relevant only to the 
characters represented in the low byte.  The whole point of
UTF-8 is that it extends this one-byte set by adding additional
bytes.  So UTF-8 coexists in parallel with "set encoding". 

> So my question:  Is it possible to add UTF to "set encoding"?  At
> least for the postscript terminal?

There is no need to.  It "just works". 
I can post some examples if you like, but really there is nothing
special about it other than making sure that the requested font
is in fact a UTF-8 font. UTF-8 (and other multibyte fonts) is
also supported by the png/gif/jpeg terminal and more recently by
x11. Hmmm. Maybe I really should add some examples to the demo
pages on the web site.

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

Question about gnuplot v 4.0

[Luca M. <mon...@at...>]

Hi,
I would like to know how is possible to write a text  in colour in a
legend, by using the combination of <set key> and the command
<title> in <plot>

e.g.:
set key screen 0.5,0.5 Left reverse spacing 1.1
plot "filename" u 1:5 t "text" w d

The previous version of Gnuplot was doing it automatically, the version
4.0 does not..

Many thanks for your kind reply!!
  L. Montabone

-------------------------------------------------------------------------|
Dr Luca Montabone  -  Post-doctoral Research Assistant                   |
University of Oxford                                                     |
Atmospheric, Oceanic and Planetary Physics (AOPP) - Clarendon Laboratory |
Parks Road, Oxford, OX1 3PU - United Kingdom                             |
Telephone: +44 (0)1865 272902     Fax: +44 (0)1865 272923                |
E-mail: mon...@at...                                           |
-------------------------------------------------------------------------|

strings and macros

[Johannes Z. <joh...@ze...>]

Hello,

just some thoughts about those nifty strings and macros:

1. A limitation to 80 characters for sprintf really hurts!

2. dynamical macros would be really nice ;-)

    set macros
    pl(x) = sprintf("plot '<extract -n %s' u 2, '<extract -n -f %s' u 3", x, x)
    @pl("myfile.dat")


1. can be implemented easily.
I wouldn't know how to implement 2.

Any comments?

-- 
Johannes

UTF8 encoding

[Juergen W. <wie...@fr...>]

Hi,

A colleague just asked me how to use Umlauts with gnuplot on his
box.  As he uses SuSE 9.3, the default encoding is UTF-8.  That
isn't supported by "set encoding" yet.  So I had to refer to latin1,
ps_guide.ps and all the funny "\340" octal codes.  That's of course
far from being convenient.  A more convenient workaround would be to
switch the encoding within emacs for gnuplot files, but...

So my question:  Is it possible to add UTF to "set encoding"?  At
least for the postscript terminal?  What does the postscript
standard say about UTF?


Juergen

Re: user-defined function & string file name

[<wie...@we...>]

Ethan A Merritt wrote:
> The internal evaluation code uses switch(value.type) statements everywhere.
> At the very least, if you add a new type without adding new case
> statements you will cause compiler warnings.  Easy enough to do, but my
> feeling is that if you want to go to this trouble then we might just as
> well remove the conditional compilation flags around the string variable
> code and leave it at that.

I think I got the point.  Thanks for your patience.  I've already
said that I regret ever having suggested this. :-) Removing
GP_STRING_VARS would be nice, but isn't really neccessary.  Tomorrow
I'll upload a clean up for the last patch.

BTW: During my tests, I've stumbled over a small memory leak, which
took me quite long to locate.  Eventually, it has been in there
before my changes.  The function f_call() pops a "struct value" from
the stack.  If this contains a string, it ought to be freed.  Patch
attached.


Juergen

Re: user-defined function & string file name

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

On Monday 04 July 2005 02:23 am, Juergen Wieferink wrote:
> Hans-Bernhard Broeker wrote:
> > Juergen Wieferink wrote:
> > > Enabling strings in this special case would be to define "STRING"
> > > and to extend the union within "struct value" by "string_val".  This
> > > itself should not lead to additional code in the executable.
> >
> > That would only be true if we were certain that all usages of the
> > union are already fully decoded, i.e. the switch(value.type) all have
> > cases for each of the allowed values, and there are no if(value.type
> > == INTGR) or similar.  That's not quite true right now, even though
> > we're surprisingly close to that goal.
>
> I don't understand this, and I feel really should.  Is there really
> a problem with "if (value.type == INTGR)", or would it be the "else"
> part that makes problems?

The internal evaluation code uses switch(value.type) statements everywhere.
At the very least, if you add a new type without adding new case
statements you will cause compiler warnings.  Easy enough to do, but my
feeling is that if you want to go to this trouble then we might just as
well remove the conditional compilation flags around the string variable
code and leave it at that.
-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: word(s) patch

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

On Monday 04 July 2005 01:10 am, you wrote:
> Secondly, and probably too late: word("s t r i n g", 1) fishes the
> first word ("s"), while substr("string",1,1) returns the second
> letter.  I think both indices should start at the same value.
> Don't know how to solve this.

I don't know either.  Perhaps I should just remove the substr()
function altogether.  That would make a clear distinction between
the operation  STRING[beg:end]  (uses C-language indexing from 0)
and the function calls like word(STRING,N)  (uses rexx or fortran
indexing starting from 1).

I don't think it's too late to change these; they've only been
in CVS for a short time.  The question did come up in discussion,
but few opinions or answers were offered.  I chose to go with logic
that if the function name came from a particular environment, rexx
in the case of word() and words(), it should maintain the indexing 
convention that it was derived from.

But I agree that the substr(beg,end) indexing is confusing, and
contradicts the awk equivalent  substr(beg,length) regardless
of whether beg starts at 0 or 1.

Petr: What are your thoughts?  It was your suggestion to include
a subroutine form of the substring operator (and it was utterly
trivial to implement).  But it may add more confusion than it is
worth.

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

Re: user-defined function & string file name

[Juergen W. <wie...@fr...>]

Hans-Bernhard Broeker wrote:
> Juergen Wieferink wrote:
> > I don't understand this, and I feel really should.  Is there really
> > a problem with "if (value.type == INTGR)", or would it be the "else"
> > part that makes problems?
>
> If there's an else part, that'll almost certainly create problems.  An
> "if (value.type != INTGR)" quite likely will.  As will any "switch()"
> that doesn't have a case(STRING) or a default case that does a sensible
> thing.
>
> All such cases are likely to break if we enable the STRING entry in
> DATA_TYPES, but don't also turn on the rest of the string-variables stuff.

But the problem only occurs where the val.type is actually set to
STRING.  This wouldn't be allowed anywhere but within this special
context of eval_plot() & Co.  And uninitialized "struct value"s
mustn't be used anyway because of the current string variable
implementation.

But I agree that my proposal is a Bad Thing.


Juergen

Re: set grid lt rgb "#aaaaaa" plots dotted grid

[Juergen W. <wie...@fr...>]

Johannes Zellner wrote:
> I just observed that
>
>     set grid lt rgb "#aaaaaa"
>
> plots a dotted grid, while
>
>     set grid lt 3
>
> plots a solid grid. Is this a bug?
>
> In other words: how can I get a solid grid with a user defined (rgb)
> color?

Linecolors are now somewhat separated from linetypes:

gnuplot> set grid lt 1 lc rgb '#aaaaaa'

works correctly.  I don't know if the behavior you mentioned is
intended, though.  I'd expect at least a subsequent

gnuplot> set grid lc rgb '#333333'

not to change the linetype back to 0.  But I'm not aware of any
general policy in these things, so I can't say how it should be
done.


Juergen

set grid lt rgb "#aaaaaa" plots dotted grid

[Johannes Z. <joh...@ze...>]

Hello,

I just observed that

    set grid lt rgb "#aaaaaa"

plots a dotted grid, while

    set grid lt 3

plots a solid grid. Is this a bug?

In other words: how can I get a solid grid with a user defined (rgb)
color?

-- 
Johannes

Re: Key layout and exterior X window patches

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:
> Daniel J Sebald wrote:
> 
>> But, isn't there some memory in gnuplot options?  That is,
>>
>>   set key left
>>   set key center
>>
>> has an end state of
>>   set key left center
> 
> 
> It may have that effect.  Or one option may override the default 
> specified by another, if it comes after that.   The memory is in the 
> internal status variables, not necessarily in the syntax seen by the user.

I'm working on it.  I have something close to this I think.  Patch soon.

Dan

Re: user-defined function & string file name

[Hans-Bernhard B. <br...@ph...>]

Juergen Wieferink wrote:
> I don't understand this, and I feel really should.  Is there really
> a problem with "if (value.type == INTGR)", or would it be the "else"
> part that makes problems?

If there's an else part, that'll almost certainly create problems.  An 
"if (value.type != INTGR)" quite likely will.  As will any "switch()" 
that doesn't have a case(STRING) or a default case that does a sensible 
thing.

All such cases are likely to break if we enable the STRING entry in 
DATA_TYPES, but don't also turn on the rest of the string-variables stuff.