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

Re: Expecting all terminals to be the same [was: Re: x11 point symbols]

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

>> plot sin(x) with points 4
>> plot sin(x) with points 8
>
> This proposal may seem charming, but neglects the well-considered
> reasons why gnuplot uses numbered point and line types instead of named
> ones.  The question that this fails to answer is: what is a terminal
> driver supposed to do if I request a named point type that it simply
> doesn't have?  Throw a tantrum, commit seppuku, read my mind, or what?
>
> The single most important design principle of gnuplot has always been
> absolute script compatibility --- scripts were never allowed to just
> fail just because you run them on a different platform's gnuplot, or on
> a different terminal driver.  And where possible, they should generate
> usable output.

In recent years, the tendency goes to compatibility in terminal output. We 
really want this.

Thus yet another missing compatibility are dashed styls -- set terminal 
{no}dashed or set termoption {no}dashed .. and then dashed styles ...

---
PM

Re: Expecting all terminals to be the same [was: Re: x11 point symbols]

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

[Forgot to CC: the list on this...]

Daniel J Sebald wrote:
> Hans-Bernhard Br=F6ker wrote:
>=20
>> Daniel J Sebald wrote:
>>
>>> It would be nice to give names to the symbols so that either the name=
=20
>>> or the number can be used.  For example:
>>>
>>> plot sin(x) with points square
>>> plot sin(x) with points triangle
>>>
>>> instead of
>>>
>>> plot sin(x) with points 4
>>> plot sin(x) with points 8
>>
>>
>>
>> This proposal may seem charming,
>=20
>=20
> You aren't riffing off my Lucky Charms humor, are you?  :-)
>=20
>> but neglects the well-considered reasons why gnuplot uses numbered=20
>> point and line types instead of named ones.  The question that this=20
>> fails to answer is: what is a terminal driver supposed to do if I=20
>> request a named point type that it simply doesn't have?  Throw a=20
>> tantrum, commit seppuku, read my mind, or what?
>=20
>=20
> Read the user's mind... I'll get working on that patch right now.
>=20
> Well, of course there is that matter to deal with.  There may be more=20
> than one way of addressing this, but ultimately it would mean gracefull=
y=20
> substituting symbols; and in a unique way.  (Don't want to substitute=20
> with a symbol that is used on the plot already.)
>=20
> One method would be for gnuplot to have a fixed name to number mapping=20
> as I showed in my previous email.  Then inside the terminal driver is=20
> another array of translations.  For example to gnuplot the square might=
=20
> be #4, but the internal table for the terminal driver looks up array=20
> offset 4 and finds that it is supposed to use #6 for its library call. =
=20
> Something like that.  Then there might be an array for substitutes if=20
> the terminal driver doesn't have the square symbol.  It might issue a=20
> warning (just the first time) "Do not have 'square' symbol, substitutin=
g=20
> with 'Maltese cross'".  I suppose a table of strings would need to be=20
> saved for that... which brings me to the second method.
>=20
> Dan
>=20


--=20

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

Re: Expecting all terminals to be the same [was: Re: x11 point symbols]

[<br...@ph...>]

[Forgot to CC: the list on this...]

Daniel J Sebald wrote:
> It would be nice to give names to the symbols so that either the name or 
> the number can be used.  For example:
> 
> plot sin(x) with points square
> plot sin(x) with points triangle
> 
> instead of
> 
> plot sin(x) with points 4
> plot sin(x) with points 8

This proposal may seem charming, but neglects the well-considered
reasons why gnuplot uses numbered point and line types instead of named
ones.  The question that this fails to answer is: what is a terminal
driver supposed to do if I request a named point type that it simply
doesn't have?  Throw a tantrum, commit seppuku, read my mind, or what?

The single most important design principle of gnuplot has always been
absolute script compatibility --- scripts were never allowed to just
fail just because you run them on a different platform's gnuplot, or on
a different terminal driver.  And where possible, they should generate
usable output.  It's this universality that the number point and line
types achieve.  Replace them by names, and compatibility goes down the
drain.

Re: Expecting all terminals to be the same [was: Re: x11 point symbols]

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

> It would be nice to give names to the symbols so that either the name or the 
> number can be used.  For example:

I like this idea!

The terminology could be the same as in LaTeX (e.g. amssymb).

> plot sin(x) with blue diamonds
> plot cos(x) with yellow moons
> plot tan(x) with green clovers

Yes, it's more cryptic nowadays, but works ...
     plot sin(x) with points lc rgb "green" pt 7

Hmm but it takes some time to find this sequence somewhere in docs ... 
shouldn't it go to 'help colors'?

---
PM

Re: Expecting all terminals to be the same [was: Re: x11 point symbols]

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

On Monday 27 February 2006 11:58 pm, Daniel J Sebald wrote:
> 
> It would be nice to give names to the symbols so that either the name or the number can be used.  For example:
> 
> plot sin(x) with points square
> plot sin(x) with points triangle
> 
> instead of
> 
> plot sin(x) with points 4
> plot sin(x) with points 8

You can do that yourself, simply by creating an 
initialization file that contains

  # Pre-define some point styles
  square = 4
  triangle = 8


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

Re: Please suggest syntax for new command

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

On Tuesday 28 February 2006 05:59 am, Hans-Bernhard Br=C3=B6ker wrote:
> > I'm using as a test:
> > 	set style preferences {ls|linestyle|lt|linetype}
>=20
> I think "set style increment" or "set style autoincrement" would be
> clearer.  And because auto-increment affects point types as well as line=
=20
> types, I think the option values would have be "type" and "style", or=20
> maybe "system" and "user", not ls and lt.

Good point.


> > 	text comment to be stored in the output	file if possible
>=20
> Strictly terminal-specific ---> set term or set termoption

The notion was to be able to associate arbitrary text, say a figure
caption, with the plot as it was generated.  This does not depend on
the terminal type, and if you do a "set term ... replot"  you would
want that same text item to go into the new output format as well.
It's not really on my list of things to do; I just mentioned it as
another example of a plot property.


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Please suggest syntax for new command

[<br...@ph...>]

Ethan A Merritt wrote:

> Amazingly enough, this requires only about 6 lines of code.
> However, it also requires some command to turn it on or off.
> What should such a command look like?
> I'm using as a test:
> 
> 	set style preferences {ls|linestyle|lt|linetype}
> 
> where "preferences" can be abbreviated down to "pref".

I think "set style increment" or "set style autoincrement" would be
clearer.  And because auto-increment affects point types as well as line 
types, I think the option values would have be "type" and "style", or 
maybe "system" and "user", not ls and lt.

> E.g.	line spacing of multi-line text
> 	key titles in black/color

belongs in 'set key'.

> 	max number of linetypes used before recycling

Sub-option of the new command above.

> 	text comment to be stored in the output	file if possible

Strictly terminal-specific ---> set term or set termoption

Re: Expecting all terminals to be the same [was: Re: x11 point symbols]

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

Petr Mikulik wrote:
>> into better agreement for the first 8 or 12 line and point types
>> (I forget exactly what the upper limit was).  If we missed some
>> terminals, then certainly let's fix that.  But many terminal types
>> only *have* 8 linetypes, so I think asking for consistency out to
>> the 14th or 15th is not realistic.
> 
> 
> A typical usage for these symbols is to plot curve with just few 
> symbols, but big! You have even made a patch taking symbol size from 
> datafile.
> 
> I propose we have the first 16 (i.e. until nb 15) the same. If it is 
> (easily) possible, then let's support it. (An ideal case is to have all 
> of them the same, of course...)

It would be nice to give names to the symbols so that either the name or the number can be used.  For example:

plot sin(x) with points square
plot sin(x) with points triangle

instead of

plot sin(x) with points 4
plot sin(x) with points 8

Or maybe even replace "points" with the name, so

plot sin(x) with squares
plot sin(x) with triangles

Now the array of names should be printed via "help set style points"

<usual doc>

Translations are:

1  - pluses
2  - crosses
3  - stars (or whatever that thing is)
4  - squares
5  - filledsquares
   - solidsquares
6  - circles
7  - (you're right Ethan, these things are hard to tell apart) dots
8  - triangles
   - uptriangles
9  - filledtriangles
   - solidtriangles
   - filleduptriangles
   - soliduptriangles
10 - downtrianges
11 - filleddowntriangles
   - soliddowntriangles
12 - diamonds
13 - filleddiamonds

or something like that.

[This next part is a joke, for all the non-americans out there on the list...]

We could then have a special edition Lucky Charms version of gnuplot for which there are symbols like

plot sin(x) with blue diamonds
plot cos(x) with yellow moons
plot tan(x) with green clovers

[... Sorry, I couldn't resist.]

Dan

Re: it seems my Gnuplot 4.0 didn't read my ~/.Xdefaults

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

On Monday 27 February 2006 06:46 pm, James R. Van Zandt wrote:
> >"~/.Xdefaults-<hostname>" file for each server.
> 
> Actually, a file for each client.  I use this mechanism to
> set a different background color for each machine, so I can tell
> at a glance which windows came from which machine.  

I used to do that, but somewhere along the way I switched over
to ssh-ing from inside whatever terminal I was currently in. 
At that point it's too late to change colorschemes.
But I do have all my login scripts reset the title bar of
the current window to the machine just logged into.

> >Huh.  I see that the code does try to open such files, but apparently
> >it only does so if the window manager has not already initialized the
> >database: ...
> 
> Hmm.  That doesn't match the X manual:
> Is that a recent change to the code?

[trimmed to show relevant lines]

1.1   (lhecking 26-Mar-99):   if (server_defaults)
1.1   (lhecking 26-Mar-99):      dbDef = XrmGetStringDatabase(server_defaults);
1.1   (lhecking 26-Mar-99):   else {
1.15  (lhecking 19-Oct-00):      strcat(buffer, "/.Xdefaults");
1.1   (lhecking 26-Mar-99):      dbDef = XrmGetFileDatabase(buffer);

Which I think means it dates back at least to version 3.7 days.


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

Please suggest syntax for new command

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

I've coded up a fairly trivial option that selects 
successive line *styles* for plots rather than successive
line *types*.  That would answer many requests over the years
for user control over the order of colors, etc,
without having to re-write all the corresponding plot commands.

Amazingly enough, this requires only about 6 lines of code.
However, it also requires some command to turn it on or off.
What should such a command look like?
I'm using as a test:

	set style preferences {ls|linestyle|lt|linetype}

where "preferences" can be abbreviated down to "pref".
I'm totally open to other suggestions, though.
Maybe   set style plot ...

There are a couple of other trivial user preferences that could
be stuffed into such a new style type, whatever it would be called.
None are very important, but have been requested from time to time.
E.g.	line spacing of multi-line text
	key titles in black/color
	max number of linetypes used before recycling
	text comment to be stored in the output	file if possible

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

Re: it seems my Gnuplot 4.0 didn't read my ~/.Xdefaults

[James R. V. Z. <jr...@co...>]

>Ethan Merritt <merritt@u.washington.edu> wrote:
>the app-defaults mechanism does not seem
>to be commonly used anymore.  It used to be (back in R4/R5 days)
>that most x11 applications came with a corresponding app-defaults
>file....
>
>Nevertheless, an app-defaults file can be a useful template for
>modifying or adding entries to your personal configuration.
>I have it on my TODO list to stuff the gnuplot_x11 X-resources
>into an app-defaults file for that reason.

I like the app-defaults file mechanism.  It gives the packager or
system administrator a way to tune the application, which the
individual user can still override.  (On a Debian system, they go in
/etc/X11/app-defaults.  I have 63 of them on this system.)

>Based on your traces, it seems one would need a separate
>"~/.Xdefaults-<hostname>" file for each server.

Actually, a file for each client.  I use this mechanism to
set a different background color for each machine, so I can tell
at a glance which windows came from which machine.  

>
>[After a bit of poking through the gplt_x11.c code]
>
>Huh.  I see that the code does try to open such files, but apparently
>it only does so if the window manager has not already initialized the
>database: ...

Hmm.  That doesn't match the X manual:

       XENVIRONMENT
              This must point to a file containing X resources. The
              default is $HOME/.Xdefaults-<hostname>. Unlike
              __projectroot__/lib/X11/Xresources, it is consulted each
              time an X application starts.
              
Is that a recent change to the code?  (I don't have current versions
of gnuplot running everywhere.)

                - Jim Van Zandt

Re: Expecting all terminals to be the same [was: Re: x11 point symbols]

[<tim...@en...>]

> On Monday 27 February 2006 12:41 pm, Timoth=C3=A9e Lecomte wrote:
>> > On Monday 27 February 2006 11:40 am, Ga=C3=ABl Varoquaux wrote:
>> >> On Mon, Feb 27, 2006 at 10:05:11AM -0800, Ethan Merritt wrote:
>> >> > Better to have fewer symbols that are mutually distinguishable
>> >> > than to cycle through  symbols that are confusingly similar.
>> >>
>> >>     Well, I see your point but I actually think it is annoying to
>> >> have different renders with different terminals.
>>
>> In fact, such a distinction may tend to disappear, because most of
>> the work on pixel-based applications can be done through libraries
>> which support subpixel-accuracy, which is related to antialiasing.
>
> It is true that I am very impressed by the crisp font rendering in the
> wxWidgets terminal as compared to straight x11.  But that only
> extends so far, and not everyone sits in front of a huge monitor.
>
> Have a look at the postscript test image as displayed through
> ghostview or gv on a 1024x768 X display.  Do you really think that poin=
t
> types 14 and 15 are distinguishable from 6 and 7 without enlarging
> the local region by a factor of 8 or so?   A pentagon is just too
> similar to a circle.

Hum... I am running on a laptop with a 1024x768 dispay, and if I find tha=
t
in the postscript test image those points are pretty well distinguishable
! Have you turned on gv antialiasing ? (State->Antialias)

> If there is a compelling case for having a consistent set of 16
> point symbols,  I'd suggest we  start by considering what other
> symbols might be used for the last two, rather than pentagons.
> =E2=9C=AB  A star (Unicode U+272B)?
> =E2=9C=BF  A flower (Unicode U+273F)?
> =E2=9C   A Maltese cross (Unicode U+2720)?
>
> In fact, it might be a good idea in general to pick symbols that
> are present in a scalable unicode font.  That would allow more
> terminals to get the improved antialiasing/sub-pixel hinting
> benefits that I expect will continue to be added to font rendering
> libraries.

Interesting idea, but the positionning of a font character is not very
easy in general (as for me, I had to fight with pango)...

Timoth=E9e

Re: Expecting all terminals to be the same [was: Re: x11 point symbols]

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

On Monday 27 February 2006 12:41 pm, Timoth=C3=A9e Lecomte wrote:
> > On Monday 27 February 2006 11:40 am, Ga=C3=ABl Varoquaux wrote:
> >> On Mon, Feb 27, 2006 at 10:05:11AM -0800, Ethan Merritt wrote:
> >> > Better to have fewer symbols that are mutually distinguishable
> >> > than to cycle through  symbols that are confusingly similar.
> >>
> >>     Well, I see your point but I actually think it is annoying to
> >> have different renders with different terminals.
>
> In fact, such a distinction may tend to disappear, because most of
> the work on pixel-based applications can be done through libraries
> which support subpixel-accuracy, which is related to antialiasing.

It is true that I am very impressed by the crisp font rendering in the
wxWidgets terminal as compared to straight x11.  But that only
extends so far, and not everyone sits in front of a huge monitor.

Have a look at the postscript test image as displayed through
ghostview or gv on a 1024x768 X display.  Do you really think that point
types 14 and 15 are distinguishable from 6 and 7 without enlarging
the local region by a factor of 8 or so?   A pentagon is just too=20
similar to a circle.

If there is a compelling case for having a consistent set of 16
point symbols,  I'd suggest we  start by considering what other
symbols might be used for the last two, rather than pentagons.
=E2=9C=AB  A star (Unicode U+272B)?  =20
=E2=9C=BF  A flower (Unicode U+273F)? =20
=E2=9C=A0  A Maltese cross (Unicode U+2720)?

In fact, it might be a good idea in general to pick symbols that
are present in a scalable unicode font.  That would allow more
terminals to get the improved antialiasing/sub-pixel hinting
benefits that I expect will continue to be added to font rendering
libraries.


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Expecting all terminals to be the same [was: Re: x11 point symbols]

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

>>     Well, I see your point but I actually think it is annoying to
>> have different renders with different terminals. And it does take by
>> surprise the newbye.
>
> I understand that new users have unreasonable expectations :-)

Nowadays, they are reasonable. The resolution of output devices gets better 
and better.

> into better agreement for the first 8 or 12 line and point types
> (I forget exactly what the upper limit was).  If we missed some
> terminals, then certainly let's fix that.  But many terminal types
> only *have* 8 linetypes, so I think asking for consistency out to
> the 14th or 15th is not realistic.

A typical usage for these symbols is to plot curve with just few symbols, 
but big! You have even made a patch taking symbol size from datafile.

I propose we have the first 16 (i.e. until nb 15) the same. If it is 
(easily) possible, then let's support it. (An ideal case is to have all of 
them the same, of course...)

---
PM

Re: Expecting all terminals to be the same [was: Re: x11 point symbols]

[<tim...@en...>]

> On Monday 27 February 2006 11:40 am, Ga=EBl Varoquaux wrote:
>> On Mon, Feb 27, 2006 at 10:05:11AM -0800, Ethan Merritt wrote:
>> > Better to have fewer
>> > symbols that are mutually distinguishable than to cycle through
>> > symbols that are confusingly similar.
>>
>>     Well, I see your point but I actually think it is annoying to
>> have different renders with different terminals. And it does take by
>> surprise the newbye.
>
> I understand that new users have unreasonable expectations :-)
>
> The fact remains that there is a huge divide between the essentially
> infinite resolution vector-based terminals like postscript, emf, svg,
> pdf, and the pixel-based terminals like x11 and png.

In fact, such a distinction may tend to disappear, because most of the
work on pixel-based applications can be done through libraries which
support subpixel-accuracy, which is related to antialiasing. This provide=
s
the ability to have satisfying outputs on pixel-based surfaces even for
non-interger coordinates (with some restrictions of course).

For example, I can draw a pentagon as 14th and 15th symbols with the
wxWidgets terminal. I've not done it because my basis was the X11
terminal.

> The same sort of divide exists with regard to optimal color choice,
> where output destined for a physical printer wants different colors
> than output destined for display on a screen.

That's another problem, but we could for example choose the intersection
of the acceptable colors of both output systems.


Timoth=E9e

Expecting all terminals to be the same [was: Re: x11 point symbols]

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

On Monday 27 February 2006 11:40 am, Ga=EBl Varoquaux wrote:
> On Mon, Feb 27, 2006 at 10:05:11AM -0800, Ethan Merritt wrote:
> > Better to have fewer
> > symbols that are mutually distinguishable than to cycle through
> > symbols that are confusingly similar.
>
>     Well, I see your point but I actually think it is annoying to
> have different renders with different terminals. And it does take by
> surprise the newbye.

I understand that new users have unreasonable expectations :-)

The fact remains that there is a huge divide between the essentially
infinite resolution vector-based terminals like postscript, emf, svg,
pdf, and the pixel-based terminals like x11 and png.

The same sort of divide exists with regard to optimal color choice,
where output destined for a physical printer wants different colors
than output destined for display on a screen.

If you truly need to compose a postscript figure accurately, there
is no substitute for using the postscript terminal itself. Trying to
emulate it exactly in x11 is an unreasonable goal, particularly if it
comes at the cost of the legibility of the screen display.=20
We should optimize the x11 settings so that they give the best
appearance on an actual X display.

If I want to end up with an *.eps figure, I preview drafts with
	set term post eps color solid
	set output '| gv:-'
If I want to end up with a *.png figure, I preview drafts with
	set term png
	set output '| display png:-'
and so on.

This is always going to give better control than fiddling with
plot elements in x11 and then hoping they come out the
same on another terminal type. =20

In the run-up to version 4.0 we made an effort to bring terminals
into better agreement for the first 8 or 12 line and point types
(I forget exactly what the upper limit was).  If we missed some
terminals, then certainly let's fix that.  But many terminal types
only *have* 8 linetypes, so I think asking for consistency out to
the 14th or 15th is not realistic.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: x11 point symbols

[V. <gae...@no...>]

On Mon, Feb 27, 2006 at 10:05:11AM -0800, Ethan Merritt wrote:
> On Monday 27 February 2006 09:11 am, Petr Mikulik wrote:
> > It seems that x11 point symbols number 14 and 15 differ from those of
> > postscript. Someone knows how to change them?

> That would not be a good idea.  The resolution of a typical X11 display
> is not good enough to distinguish a pentagon (which is what the=20
> postscript 14 and 15 are) from a circle.  Better to have fewer symbols
> that are mutually distinguishable than to cycle through symbols that
> are confusingly similar.

    Well, I see your point but I actually think it is annoying to have
different renders with different terminals. And it does take by surprise
the newbye.

--=20
    Ga=EBl

Re: it seems my Gnuplot 4.0 didn't read my ~/.Xdefaults

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

On Monday 27 February 2006 03:07 am, Dave Denholm wrote:
>>  Instead, the x11 server reads the file when you
> > begin a new X-session, and applies the values in finds there to
> > answer queries from any applications (like gnuplot) that run later.
>
> I don't think that's the entire story.

I do not know whether it is some official policy change or just
natural selection, but the app-defaults mechanism does not seem
to be commonly used anymore.  It used to be (back in R4/R5 days)
that most x11 applications came with a corresponding app-defaults
file.  Now hardly any do.  It did not help general users much
because it required root access to change, which I suspect is why
it fell out of favor.

Nevertheless, an app-defaults file can be a useful template for
modifying or adding entries to your personal configuration.
I have it on my TODO list to stuff the gnuplot_x11 X-resources
into an app-defaults file for that reason.

The traces you show below are very interesting.  I did not know about
this at all.  So you are quite right that my generic explanation was not
the end of the story.   Thanks for the education!

Based on your traces, it seems one would need a separate
"~/.Xdefaults-<hostname>" file for each server.
Notice that it doesn't try to open the generic ~/.Xdefaults file.

[After a bit of poking through the gplt_x11.c code]

Huh.  I see that the code does try to open such files, but apparently
it only does so if the window manager has not already initialized the
database:

    server_defaults = XResourceManagerString(dpy);
    [...]
    if (server_defaults)
        dbDef = XrmGetStringDatabase(server_defaults);
    else {
        strcpy(buffer, home);
        strcat(buffer, "/.Xdefaults");
        dbDef = XrmGetFileDatabase(buffer);
    }
    XrmMergeDatabases(dbDef, &db);

What a curious thing to do.  So if your machine is properly 
configured to initialize your X environment on startup, then
gnuplot_x11 will not look in the files.  But if your machine is
not configured to use the standard mechanism, then
gnuplot_x11 will look for itself.  I guess since my machines
initialize the database at the start of each X session, I've
never seen this.

I have always have to update the resource database myself,
using xrdb, in order to see the effect of any change in the
.Xdefaults file.

> On linux (hostname "twoflower"):
>
> $ echo test | strace -f gnuplot
>
> ...
> open("/usr/lib/X11/app-defaults/Gnuplot", O_RDONLY) = -1 ENOENT (No
> such file or directory) ...
> uname({sys="Linux", node="twoflower", ...}) = 0
> open("/home/eclipse/ddenholm/.Xdefaults-twoflower", O_RDONLY) = -1
> ENOENT (No such file or directory)
>
>
>
> On solaris (hostname "eclipse")
>
> $ echo test | truss -f gnuplot
>
> 16820:  open("/usr/lib/X11/app-defaults/Gnuplot", O_RDONLY) Err#2
> ENOENT ...
> 16820:  sysinfo(SI_HOSTNAME, "eclipse", 64)             = 8
> 16820:  open("/home/eclipse/ddenholm/.Xdefaults-eclipse", O_RDONLY) =
> 6 16820:  xstat(2, "/home/eclipse/ddenholm/.Xdefaults-eclipse",
> 0x08046C94) = 0
>
>
>
> so on my local setup at least, the application itself is looking for
> files with application defaults. It actually seems to append the
> local hostname to the filename - in both cases, DISPLAY was eclipse.
>
>
>
> dd

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

Re: x11 point symbols

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

On Monday 27 February 2006 09:11 am, Petr Mikulik wrote:
> It seems that x11 point symbols number 14 and 15 differ from those of
> postscript. Someone knows how to change them?

That would not be a good idea.  The resolution of a typical X11 display
is not good enough to distinguish a pentagon (which is what the 
postscript 14 and 15 are) from a circle.  Better to have fewer symbols
that are mutually distinguishable than to cycle through symbols that
are confusingly similar.

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

x11 point symbols

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

It seems that x11 point symbols number 14 and 15 differ from those of 
postscript. Someone knows how to change them?

---
PM

Re: it seems my Gnuplot 4.0 didn't read my ~/.Xdefaults

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

Ethan A Merritt <merritt@u.washington.edu> writes:

> I think you may misunderstand how x11 works.
>
> (1)
> gnuplot (or any other x11 application) does not read the .Xdefaults
> file by itself.

   Instead, the x11 server reads the file when you
> begin a new X-session, and applies the values in finds there to
> answer queries from any applications (like gnuplot) that run later.



I don't think that's the entire story.

On linux (hostname "twoflower"):

$ echo test | strace -f gnuplot

...
open("/usr/lib/X11/app-defaults/Gnuplot", O_RDONLY) = -1 ENOENT (No such file or directory)
...
uname({sys="Linux", node="twoflower", ...}) = 0
open("/home/eclipse/ddenholm/.Xdefaults-twoflower", O_RDONLY) = -1 ENOENT (No such file or directory)



On solaris (hostname "eclipse")

$ echo test | truss -f gnuplot

16820:  open("/usr/lib/X11/app-defaults/Gnuplot", O_RDONLY) Err#2 ENOENT
...
16820:  sysinfo(SI_HOSTNAME, "eclipse", 64)             = 8
16820:  open("/home/eclipse/ddenholm/.Xdefaults-eclipse", O_RDONLY) = 6
16820:  xstat(2, "/home/eclipse/ddenholm/.Xdefaults-eclipse", 0x08046C94) = 0



so on my local setup at least, the application itself is looking for
files with application defaults. It actually seems to append the local
hostname to the filename - in both cases, DISPLAY was eclipse.



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

Re: Gnuplot Question

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

> I have a Gnuplot question that I would like to submit for you. I want to plot a data file
> using pm3d and view map. In this data file the two first column are x and y and I will call
> the third and fourth column R1 and R2 (with the relation R1+R2=1). My problem is that I
> want to attribute one different color for each column R1 and R2 and then  splot on view map
> (x,y,R1+R2).Well maybe I am not so clear...I give an example: if the first line of my data
> file is x=0,y=0,R1=0.5,R2=0.5 and I attribute yellow to R1 and blue to R2, R1+R2 will be green.
> Is it possible to draw such map ?? I hope I was clear enough...

What you mean by "summing colors"? Summing of R,G,B components?
Or do you want to overlap two surfaces -- draw surface R2 on top of R1?

I think you really want first to sum R1+R2, then give it a colour, then 
draw it. If you want to play with the color scale, use "set palette" and 
"set cbrange".

Hope this helps.

---
PM

Re: it seems my Gnuplot 4.0 didn't read my ~/.Xdefaults

[Reiner S. <rei...@im...>]

On Sat, Feb 25 2006, Ethan A Merritt wrote:

> On Saturday 25 February 2006 10:47 am, Ethan A Merritt wrote:
>> gnuplot (or any other x11 application) does not read the .Xdefaults
>> file by itself.   Instead, the x11 server reads the file when you
>> begin a new X-session, and applies the values in finds there to
>> answer queries from any applications (like gnuplot) that run later.

Maybe better use ~/.Xresources instead of ~/.Xdefaults; see X(1).

>> You can force an update of the x-session values
>> by typing:
>> 	xrdb -merge < ~/.Xdefaults
>
> Bleah. Sorry.  That should have been
> 	cat ~/.Xdefaults | xrdb -merge

What's the difference (apart from UUOC[1])?

(BTW, "xrdb -merge ~/.Xdefaults" should also work[2])

Bye, Reiner.

[1] Useless use of cat

[2] SYNOPSIS
       xrdb [-option ...] [filename]
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: suggestion on axis ratios

[<br...@ph...>]

James R. Van Zandt wrote:
>> 	set size ratio -1

> It would be nice if this worked for splot too.

It does, to some extent.  It's not perfect, but then, almost none of the 
3D plot layout really is.

Re: it seems my Gnuplot 4.0 didn't read my ~/.Xdefaults

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

On Saturday 25 February 2006 10:47 am, Ethan A Merritt wrote:
> You can force an update of the x-session values
> by typing:
> 	xrdb -merge < ~/.Xdefaults

Bleah. Sorry.  That should have been
	cat ~/.Xdefaults | xrdb -merge


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