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

Re: pm3d question

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

On Sun, Nov 20, 2005 at 02:30:56AM -0600, Daniel J Sebald wrote:
> Juergen Wieferink wrote:
> >Ethan A Merritt wrote:
> >
> >>Can anyone explain to me why the two surfaces produced
> >>by the command below are colored so differently?
> >>
> >> splot x with pm3d, y with pm3d
> >>
> >>The "y" surface is colored smoothly, but the "x"
> >>surface is colored in 9 increments only.
> >>What command would I use to get two smoothly
> >>colored surfaces?
> >
> >
> >This is a sampling issue.  For the x-lines (scan lines) the setting
> >of "set samples" is used while for the y-lines the "set isosamples"
> >setting applies.  This can be useful for surface plots, where the
> >x-lines will be smooth and adjacent x-lines are linearly connected
> >a few times.  For pm3d this does not seem to be optimal.
> 
> Oh yeah.  Interchanging x and y in the example still results in the same 
> sampling relationship, only one surface order is interchanged.
> 
> Hmm, I guess I'm not following how this is useful for surface plots.  Why 
> should one dimension have any different meaning than the other dimension 
> unless the user programs it to be that way?  Is there an example in the 
> demos somewhere that we can look at?
> 
> So, I think I see what controls that, Ethan:
> 
> set isosamples 128
> 
> And by default it is 10.
> 
> Now, am I understanding correctly that the isolines controls both the mesh 
> spacing of the surface plot and the color gradient spacing of the pm3d?  
> (Nothing in "help set isosamples" seems to suggest that.)  If so, we should 
> maybe discuss if that is good or bad.
> 
> First it seems a bit confusing, or should I say non-obvious.  Could 
> independent parameters be less confusing?  (Or the same parameter with 
> qualifiers "surface" and "pm3d" somehow?  E.g., "set surface isosamples", 
> "set pm3d isosamples".)

If you think of "samples" and "isosamples" converting functions into data
points it's totally obvious. It's pretty straightforward that pm3d uses
the same sampling as any other plotting styles do. gnuplot offers just
one sampling which is common for all plots.

> Second, I could imagine a case where you wouldn't want those tied together. 
> A lot of times people (like me) are concerned with adequately sampling a 
> function or signal.  Say one wanted to plot a function as a pm3d color 
> "surface" and lay a mesh surface over the top to represent where the 
> sampling locations might be.  If "pm3d isosamples" is higher than the 
> "surface isosamples" one may get insight to whether the sampling chosen is 
> high enough resolution, i.e. greater than the Nyquist rate.  On the other 
> hand, if the two are always tied together, it's not so useful that way.

There might be cases where you want a different sampling for different
plotting styles. To be more rigorous: there might be cases where
different PLOTS should be sampled differently, something like

    splot f(x, y) sampling 50:70 w pm3d, g(x, y) sampling 20:20 w lines


-- 
Johannes

last modified date in CVS

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

Perhaps it isn't a big deal, but I've noticed that the "last modified" date in the CVS version is not updated according to the last modification of the CVS source tree.  Rather it refers to the date of the release, e.g.,

        G N U P L O T
        Version 4.1 patchlevel 0
        last modified Sat Jul  3 00:04:32 CEST 2004
        System: Linux 2.6.9-1.667

It would be nice if that could be updated via a CVS checkin script or something.  (Not sure if CVS has that capability.)  For example

        G N U P L O T
        CVS Post Version 4.1 patchlevel 0
        last modified Tue Nov  13 11:06:27 CEST 2005
        System: Linux 2.6.9-1.667

Dan

pm3d.dem "color lines: 'splot sin(y)/(y) with linespoints palette'"

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

In the pm3d.dem example "color lines: 'splot sin(y)/(y) with linespoints palette'" are the points as well as the lines supposed to be hidden?  In general, the points appear to be hidden, but when zooming about sometimes I see the points come through.

Dan

Re: pm3d question

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

Juergen Wieferink wrote:
> Ethan A Merritt wrote:
> 
>>Can anyone explain to me why the two surfaces produced
>>by the command below are colored so differently?
>>
>>  splot x with pm3d, y with pm3d
>>
>>The "y" surface is colored smoothly, but the "x"
>>surface is colored in 9 increments only.
>>What command would I use to get two smoothly
>>colored surfaces?
> 
> 
> This is a sampling issue.  For the x-lines (scan lines) the setting
> of "set samples" is used while for the y-lines the "set isosamples"
> setting applies.  This can be useful for surface plots, where the
> x-lines will be smooth and adjacent x-lines are linearly connected
> a few times.  For pm3d this does not seem to be optimal.

Oh yeah.  Interchanging x and y in the example still results in the same sampling relationship, only one surface order is interchanged.

Hmm, I guess I'm not following how this is useful for surface plots.  Why should one dimension have any different meaning than the other dimension unless the user programs it to be that way?  Is there an example in the demos somewhere that we can look at?

So, I think I see what controls that, Ethan:

set isosamples 128

And by default it is 10.

Now, am I understanding correctly that the isolines controls both the mesh spacing of the surface plot and the color gradient spacing of the pm3d?  (Nothing in "help set isosamples" seems to suggest that.)  If so, we should maybe discuss if that is good or bad.

First it seems a bit confusing, or should I say non-obvious.  Could independent parameters be less confusing?  (Or the same parameter with qualifiers "surface" and "pm3d" somehow?  E.g., "set surface isosamples", "set pm3d isosamples".)

Second, I could imagine a case where you wouldn't want those tied together.  A lot of times people (like me) are concerned with adequately sampling a function or signal.  Say one wanted to plot a function as a pm3d color "surface" and lay a mesh surface over the top to represent where the sampling locations might be.  If "pm3d isosamples" is higher than the "surface isosamples" one may get insight to whether the sampling chosen is high enough resolution, i.e. greater than the Nyquist rate.  On the other hand, if the two are always tied together, it's not so useful that way.

Dan

Re: pm3d question

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

Ethan A Merritt wrote:
> Can anyone explain to me why the two surfaces produced
> by the command below are colored so differently?
>
>   splot x with pm3d, y with pm3d
>
> The "y" surface is colored smoothly, but the "x"
> surface is colored in 9 increments only.
> What command would I use to get two smoothly
> colored surfaces?

This is a sampling issue.  For the x-lines (scan lines) the setting
of "set samples" is used while for the y-lines the "set isosamples"
setting applies.  This can be useful for surface plots, where the
x-lines will be smooth and adjacent x-lines are linearly connected
a few times.  For pm3d this does not seem to be optimal.


Juergen

Re: pm3d question

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

Ethan A Merritt wrote:
> Can anyone explain to me why the two surfaces produced
> by the command below are colored so differently?
> 
>   splot x with pm3d, y with pm3d
> 
> The "y" surface is colored smoothly, but the "x"
> surface is colored in 9 increments only.
> What command would I use to get two smoothly
> colored surfaces?

I assume that is a bug.  I created a PDF example, and zooming in using a viewer shows the first draw (x) has a larger color map than the second draw (y).  So this is not terminal dependent.  Furthermore, if a third function is added to the plot, it too has a low resolution color map.  So the first map is drawn probably correct and the map for functions afterward is incorrect.  Furthermore, replot results in the first function being correct again, so it is reset between replots.

Using a fprintf(), I believe that "make_palette" is called just once.  Also, I don't think the function is being cast to an integer anywhere because then we'd see 20 levels (-10 to 10) rather than just ten.

Petr, could there be a conversion problem in z2cb(), cb2gray() or set_color()?

Dan

pm3d question

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

Can anyone explain to me why the two surfaces produced
by the command below are colored so differently?

  splot x with pm3d, y with pm3d

The "y" surface is colored smoothly, but the "x"
surface is colored in 9 increments only.
What command would I use to get two smoothly
colored surfaces?

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

Re: Cannot change to 'C:\' (root) on Windows

[Martin H. <mar...@gm...>]

Dear all,

just right after sending my last post another idea came into my mind:
Wouldn't it be valid in general to replace a  single "\" with a double
"\\" in a path (the "Select Folder" dialog returns)?
So e.g. 'D:\' would become 'D:\\' and e.g. 'C:\MyDir\MyOtherDir' would
become 'C:\\MyDir\\MyOtherDir'. This would make the replacement a lot
easier (just replace all single backslashes with double ones), is valid
and works (I've just tried it).

It would be even compatible to *nix since there no backslash appears in
a path (or does it?). Thus the replacement would replace "nothing"... ;-)

Maybe it's worth considering this...?! What do you think?

With regards,

Martin Halle

Re: Cannot change to 'C:\' (root) on Windows

[Martin H. <mar...@gm...>]

Dear all,

I've watched this discussion and actually I didn't expect that it
becomes that difficult and goes into such deep discussion. I would like
to make a suggestion on that topic:

I don't know whether it's right or wrong to interprete \' as ' or really
\'. I would entirely leave this decision up to you. But: To change to a
root folder on Windows if one uses the "Select Folder" dialog is not
working. In my opinion this clearly IS a bug.

So my suggestion is as follows: Why not intercepting at least the return
value of the "Select Folder" dialog to provide the "cd" command with a
valid path. This bug seems to apply only to root folders that have a
trailing backslash. Other folders the "Select Folder" dialog returns
without the backslash at the end. So it's a simple:
if ("2 letters on the right of the path" == ":\") then
  (replace "\" with "\\") modification.
Thus the "cd" command becomes cd 'D:\\', which works.

I assume that this would always be right and it doesn't matter than how
the qutotation are handled. A \\ should always be interpreted as a \ so
this replacement is correct.

With regards,

Martin Halle.

Re: [ gnuplot-Patches-1356114 ] set term post size <foo>in,<baz>in (also cm)

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

> >remember that just because gnuplot thinks the output
> >resolution is 300 pixels per something, that doesn't
> >mean the actual display device will have that resolution.
> 
> This only applies to screen terminals. Screen terminals as
> x11 should read the system-wide value as default.

There is no such thing as a system-wide default for x11.
It is different for every display session.

> But for all pixel-based terminals (png, gif, ...), the
> resolution can be written into the output file.

Actually, it can't.  Or at least, not using libgd.
That is a failing of libgd but we are stuck with it at present.
And I don't see a way to do it for pbm output either.
 
> - A patch exists that fixes clipping for many (or all?)
> terminals.

You are referring to patch #1104264?
That patch does not fix the root problem at all. It just
multiplies the reported screen limits by a factor large
enough to let the arrows escape clipping.  This works for
PostScript because it doesn't really care that you are drawing
outside of the limits it previously reported.
On terminals that do care, your patch could make things worse
rather than better.

I would much rather the problem, if it is one, be fixed
by having the terminals correctly report a legal range of
x and y values.  That would make the current clipping code
work for all terminals, rather than having to special-case
terminals that report silly values.

But if we *do* have to special-case post.trm, it's better to
just turn off clipping altogether rather than "fix" it
by describing an over-large drawing area.
Please try the patch I sent you earlier today.

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

Re: Cannot change to 'C:\' (root) on Windows

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

On Wednesday 16 November 2005 09:54 Petr Mikulik wrote:
> Your patch is fine with me.
>
> Could you please update it with adding docs (description + examples) into
> "help quotes", and maybe also to "help cd" (we should replace "DOS users
> _must_" by "DOS and Windows users _must_").

Patch attached.  I have much more trouble writing English than
writing C, so I recommend to have close look on what I've written.


Juergen

Re: New PostScript sizing options [was: Argh: Why are arrows clipped to the graph?]

[Jonathan T. <jt...@ae...>]

Hi,

On Mon, 14 Nov 2005, Ethan Merritt wrote:
> Sorry, I should have posted a specific announcement here as well as
> to the SourceForge tracking list.
>
> Please give a thorough workout to SourceForge patch #1356114
>
> 	set term post size <foo>in,<baz>in
>
> Also handles units of cm or pixels.
[[...]]

Thanks, this looks like just what I was looking for.
I'm tied up for the next 2-3 weeks, but shortly after that I'll
try it out.

Of course, for _portable_ gnuplot scripts (ones which I can put into
our local cvs repository, and expect my coauthors to be able to run
with whatever random gnuplot version they have) I'll have to stick to
the old 'set size > 1' for another year or two, but in the long run,
I think Ethan's patch is a clean solution to the problem.

ciao,

-- 
-- Jonathan Thornburg <jt...@ae...>
    Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
    Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html
    "Washing one's hands of the conflict between the powerful and the
     powerless means to side with the powerful, not to be neutral."
                                       -- quote by Freire / poster by Oxfam
>
>
> Here is a repeat announcement
>
>
> Initial Comment:
> Enough talking about it, here is actual code.
>
> Synopsis
> ========
> Specify explicit bounding box for postscript-based
> terminals in inches, centimeters, or points.
> e.g. default is equivalent to
>       set term post size 10in, 7in
>
> Details
> =======
> Adds a parsing routine parse_term_size(*x, *y,
> default_units) that can be called by any terminal
> driver.  I've only implemented it for post.trm and
> gd.trm, but any terminal that already allows a size can
> be trivially converted to use the new routine.
>
> Default_units is either INCHES, CM, or PIXELS.
> This tells the routine how to interpreat a bare number
> in the size spec.  Pixel-based terminals will normally
> select PIXELS as the default units, but post.trm
> defaults to INCHES.
>
> This will get you US paper size "legal":
>   set term post landscape size 14, 8.5
>
> This will get you paper size A4:
>   set term post size 29.7cm, 21.0cm
>
> And this will get you a 3 inch by 5 inch PNG image if
> display on a monitor with approximately 72 dpi resolution:
>  set term png size 3in, 5in
>
> Notes
> ======
>
> We need some mechanism to specify a resolution other
> than 72dpi for pixel-based terminals.
>
> With this in place, there should never be a need for
> specifying size > 1 to postscript terminals.  This
> mechanism gets the bounding box right for large plots,
> which the old mechanism never did.
>
> Please give this a workout.  I've tested it, but I
> don't have any old scripts that produced oversize
> postscript images, so I can't easily compare backwards
> compatibility in real cases.
>
>
> --
> Ethan A Merritt       merritt@u.washington.edu
> Biomolecular Structure Center
> Mailstop 357742
> University of Washington, Seattle, WA 98195
>
>

Re: maximing/resizing multiple x11: change of palette

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

Yes, your patch fixes the bug, so I wish to move it to cvs.

---
PM

Re: maximing/resizing multiple x11: change of palette

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

Petr Mikulik wrote:
> This is an old bug (August 2004, see below). What do you think nowadays 
> about fixing it?

Petr,

Attached is a freshened version of the patch for the bug fix.  Give it a try and if you think it solves the problem please consider moving into CVS.

As a reminder to others, we had a big discussion about this bug.  (Go back to about Sep  9, 2004.)  In addition to the initial problem Petr found, I think this patch also has a bug fix for what I thought was a memory leak.  It also rid that difficult to decipher code with "recursive" in it.

In summary, it is a linked list of color maps separate from the linked list for X11 plots.  (Hey, I like linked lists; what can I say?)  Basically, whenever a new palette (i.e., different than any other already in the list) comes over the link it is placed in the list.  Whenever a figure is destroyed and the associated palette is not used by a different plot, that palette is discarded from the list.

Dan

 
> ***
> 
> There is a bug in the color palette treatment in the X11 terminal: when
> using multiple X11 terminals, window redraw (requested e.g. by a window
> manager) will change its palette.
> 
> Try this script:
> 
> 
> set pm3d map
> 
> set term x11 10
> set title '10 gray levels'
> set palette gray
> set palette maxcolors 10
> splot x*x
> 
> set term x11 2
> set title '2 colors'
> set palette color
> set palette maxcolors 2
> splot x
> 
> 
> Now, maximize or resize window #10 by mouse => it will change from gray map
> with 10 gray levels to color map with 2 colors.
> 
> 
> 
> 
>>> Yes, every x11 windows should have its own copy of the palette. When 
>>> there
>>> is a new (re)plot, x11 should copy the current gnuplot palette into 
>>> palette
>>> of the active window, and use that.
>>
>>
>> I don't like hacking stuff, and this may take some consideration.  I'm 
>> wondering how this should be structured, and whether we should be 
>> conservative with palette usage in order to not consume too much 
>> memory. Are palettes memory consumers?  If so, it might be wise to not 
>> save a color map with every plot.  That is, say there is a fairly 
>> large palette, and then someone creates twenty plots.  If all those 
>> plots have a similar palette, it may be an inefficient use of memory.
>>
>> Rather, it might be wise to have a linked-list of palettes.  Whenever 
>> a new palette is created, it is put in the linked list.  Then, when a 
>> palette is changed at the gnuplot command line, gplt_x11.c will search 
>> through the plot list and see if any of the plots is using the old 
>> palette.  If not, that color map can be discarded from the list.
>>
>> It sounds unnecessarily tedious, but it really does seem like the 
>> thing to do, and it actually might simplify the various uses of 
>> XAllocColor and XFreeColors.
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. 
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


-- 

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/

Re: Cannot change to 'C:\' (root) on Windows

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

> I'd vote for the Fortran syntax.  There are no compatibility issues
> (AFAICS).  Single quotes have a special meaning anyway and the
> sequence of two consequent single quotes within a 'string' would
> otherwise be illegal.  I've attached a patch implenting this to test
> this out and get a feeling for it.

Your patch is fine with me.

Could you please update it with adding docs (description + examples) into 
"help quotes", and maybe also to "help cd" (we should replace "DOS users 
_must_" by "DOS and Windows users _must_").

---
PM

Re: Cannot change to 'C:\' (root) on Windows

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

On Tuesday 15 November 2005 11:27 am, Juergen Wieferink wrote:
> > There really needs to be a way to escape quote characters.

> I tend to disagree.  The main advantage of 'these strings' (like
> they are understood by the majority) compared to "these" is that
> backslashes don't have a special meaning and can be easily used.
> The drawback is the unavailability of certain characters ('\n', '\t'
> '\r', octal codes, and '\'').  With your approach, you have to
> resort to double quoted strings just to be able to have a trailing
> backslash.

Not really. IMHO it should behave as in the perl documentation
you quote below.  If you want a trailing backslash, then you have
to escape the backslash:

	foo = 'c:\\'

Yes, I know this is not what the current code does and it will
break all the existing backslash uses in single quotes. So we
won't even consider it.  But that's what it should have been :-)


I'm dropping out of this discussion.
I truly don't care which way this goes.



> *Perl* seems to work very much like you suggested. "man perldata":
> 
>        String literals are usually delimited by either single or double
>        quotes.  They work much like quotes in the standard Unix shells: dou-
>        ble-quoted string literals are subject to backslash and variable sub-
>        stitution; single-quoted strings are not (except for "\'" and "\\").


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

Re: Cannot change to 'C:\' (root) on Windows

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

On Monday 14 November 2005 20:05 Ethan Merritt wrote:
> On Monday 14 November 2005 10:00 am, Juergen Wieferink wrote:
> > As a small excuse for the mostly pointless discussion I've caused,
> > I've prepared a small patch which should switch to a more intuitive
> > behaviour.  Maybe the docs could be clarified accordingly.
>
> But this breaks the ability to embed quotes:
>
> gnuplot> a = "foo\"bar"
> gnuplot> print a
> foo"bar
> gnuplot> b = 'foo\'bar'
>                    ^
>          ';' expected
>
>
> This is particularly a problem is you are constructing, say,
> unix shell command lines to pass to a system() call.
> There really needs to be a way to escape quote characters.

I tend to disagree.  The main advantage of 'these strings' (like
they are understood by the majority) compared to "these" is that
backslashes don't have a special meaning and can be easily used.
The drawback is the unavailability of certain characters ('\n', '\t'
'\r', octal codes, and '\'').  With your approach, you have to
resort to double quoted strings just to be able to have a trailing
backslash.  And this is what is meant to be especially easy using
single quotes.


> The other common convention is to repeat the quote character:
>
> c = 'foo''bar'
>
> but that convention is not so far used anywhere in gnuplot.


FYI: The *bash* implements the single quotes much the same way as my
yesterday patch does: no special meaning of backslashes at all.
"man bash":

       Enclosing characters in single quotes preserves the  literal  value  of
       each character within the quotes.  A single quote may not occur between
       single quotes, even when preceded by a backslash.


*Perl* seems to work very much like you suggested. "man perldata":

       String literals are usually delimited by either single or double
       quotes.  They work much like quotes in the standard Unix shells: dou-
       ble-quoted string literals are subject to backslash and variable sub-
       stitution; single-quoted strings are not (except for "\'" and "\\").

In *Python* it does not make any difference which type of quotes are
used (apart from the correct closing).  But if the string is
prefixed with the letter 'r', it is a so called "raw string",
working exactly (except auto closing) like it used to in gnuplot.
"Python Reference Manual, Sec 2.4.1":


       When an "r" or "R" prefix is present, a character following a
       backslash is included in the string without change, and all
       backslashes are left in the string. For example, the string
       literal r"\n" consists of two characters: a backslash and a
       lowercase "n". String quotes can be escaped with a backslash,
       but the backslash remains in the string; for example, r"\""
       is a valid string literal consisting of two characters: a
       backslash and a double quote; r"\" is not a valid string
       literal (even a raw string cannot end in an odd number of
       backslashes). Specifically, a raw string cannot end in a
       single backslash (since the backslash would escape the
       following quote character). Note also that a single backslash
       followed by a newline is interpreted as those two characters
       as part of the string, not as a line continuation.

*Fortran* also makes no difference between single and double quoted
strings.  There is no special meaning to backslashes at all.  I'm
not even sure if a backslash in Fortran source code is strictly
speaking legal.  The quote character can be inserted by doubling
it---just as your last suggestion.

I'd vote for the Fortran syntax.  There are no compatibility issues
(AFAICS).  Single quotes have a special meaning anyway and the
sequence of two consequent single quotes within a 'string' would
otherwise be illegal.  I've attached a patch implenting this to test
this out and get a feeling for it.


Juergen

Re: Argh: Why are arrows clipped to the graph?

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

On Monday 14 November 2005 03:38 am, Jonathan Thornburg wrote:
> On Fri, 11 Nov 2005, Ethan A Merritt wrote:
> >>> set size 2,2
> >    ^^^^^^^^^^^^^
> > Don't do that.

Please note that the original example that I responded to
was *not* using the PostScript driver. This was the 
original complaint:

> set size 2,2
> set terminal png
> set output 'asdf.png'
> plot sin(x)
> set output
> 
> Half of the tic marks are missing.

The png driver has always supported "set term png size xx, yy".

Nevertheless, since you ask....

>    set term postscript enhanced eps solid color "Helvetica" 18
>    set output 'geodesics.eps'
>    set size 1.0, 1.5

> Is there
> an alternative mechanism that I've missed in _current_ gnuplot?

Step 1
    set term post enh solid color "Helvetica" 18
    set output 'geodesics.eps'
    set size 0.5, 0.75
    plot ...
    set output

Step 2
    add the string "EPSF-2.0" at the end of the first line of
    geodesics.eps


No, I'm not saying this is convenient. That's why I'm 
trying to push acceptance of the new patch to add explicit
size info to the "set term post" command.





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

Re: New PostScript sizing options

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

> We need some mechanism to specify a resolution other
> than 72dpi for pixel-based terminals.

Bitmap terminals would need yet another option "resolution" for specifying 
the dpi value.

> With this in place, there should never be a need for
> specifying size > 1 to postscript terminals.

OK with me.

---
PM

Re: Cannot change to 'C:\' (root) on Windows

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

>> The actual bug in 4.0 only happens if \' is at the end of the command. It's 
>> a side effect of the auto-closing of strings. The convenience feature 
>> helper that allows people to type
>>
>>     set label 1 'foo
>
> Good point.  I've gotten into the conscious (bad) habit of leaving that 
> second apostrophe off the string.

I like this feature for command line work, I don't want this to be removed.

---
PM

Re: Cannot change to 'C:\' (root) on Windows

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

Hans-Bernhard Broeker wrote:

> I.e. as of version 4.0, the status actually was that \' is *not* an 
> escape --- both the \ and the ' made it into the string unmodified.
> 
> The actual bug in 4.0 only happens if \' is at the end of the command. 
> It's a side effect of the auto-closing of strings. The convenience 
> feature helper that allows people to type
> 
>     set label 1 'foo

Good point.  I've gotten into the conscious (bad) habit of leaving that second apostrophe off the string.  Maybe gnuplot shouldn't do that.

Dan

Re: Cannot change to 'C:\' (root) on Windows

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

Petr Mikulik wrote:
> 1. \ is always \ in 'strings'; however, there is no possibility to type 
> in a quote '
> This helps writing e.g. 'cd C:\tmp\'
> 
> 2. there is only one escape possibility inside 'string': \' means '
> 
> Currently, gnuplot uses option 2. 

No, it didn't.  If it does now, that's an incompatible change.  Viz 
version 4.0 behaviour:

gnuplot> set label 1 'c:\'\win98'
gnuplot> show lab

    label 1 "c:\\'\\win98" at (0, 0, 0) left not rotated back  nopoint

I.e. as of version 4.0, the status actually was that \' is *not* an 
escape --- both the \ and the ' made it into the string unmodified.

The actual bug in 4.0 only happens if \' is at the end of the command. 
It's a side effect of the auto-closing of strings. The convenience 
feature helper that allows people to type

	set label 1 'foo

and makes that mean the same thing as

	set label 1 'foo'

mistakenly transforms

	set label 1 'foo\'

into

	set label 1 'foo\''

Re: Cannot change to 'C:\' (root) on Windows

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

>> If you do not allow some mechanism for escaping quotes, then you
>> cannot represent a quote inside a quoted string.
>
> The mechanism for escaping quotes in gnuplot is to use a double-quoted string 
> and use backslash escapes.  There is neither a need for supporting backslash 
> escapes in single-quoted strings, nor does the documentation even suggest 
> such a thing, anywhere.
>
> No, the bug is that the command
>
> 	b = 'foo\'bar'
>
> was accepted in the first place.  It should have flagged a syntax error.

Consequently, we have two possibilities:

1. \ is always \ in 'strings'; however, there is no possibility 
to type in a quote '
This helps writing e.g. 'cd C:\tmp\'

2. there is only one escape possibility inside 'string': \' means '

Currently, gnuplot uses option 2. but docs tends to 1, so it is an open 
question what to fix.

If people say escape \' is usual in other languages, I would vote for 2. 
Then, docs should include an explicit help for 'cd c:/tmp/' for Windows 
users.

---
PM

Re: Cannot change to 'C:\' (root) on Windows

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

Ethan Merritt wrote:

> \'  or \"   are not "special characters", they are escaped quotes.
> If you do not allow some mechanism for escaping quotes, then you
> cannot represent a quote inside a quoted string.

The mechanism for escaping quotes in gnuplot is to use a double-quoted 
string and use backslash escapes.  There is neither a need for 
supporting backslash escapes in single-quoted strings, nor does the 
documentation even suggest such a thing, anywhere.

> gnuplot> a = "foo\"bar"
> gnuplot> print a
> foo"bar
> 
> gnuplot> b = 'foo\'bar'
> gnuplot> print b
> foo\'bar
> 
> If there is a bug here, it is not the fact that the backslash
> escapes the single-quote.  It is that the print routine should
> know enough not to _print_ the backslash in such a case.

No, the bug is that the command

	b = 'foo\'bar'

was accepted in the first place.  It should have flagged a syntax error.

pm3d depth ordering

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

Hello,

nice to see that the pm3d depth patch is still alive ;)
Thanks Ethan for updating it to the current CVS.

As pointed out earlier, I'd like to see this in the CVS version.
Unfortunately I'm not really active in the gnuplot development any more,
so I feel it's not my decision to put the patch in. But I'd really
encourage anyone to put it into CVS ...

Best wishes,

-- 
Johannes