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

Compile warnings in new post/pslatex terminal code

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

Current CVS gives the following errors when compiled:
../term/pslatex.trm:260: warning: unused variable `tmp'
../term/pslatex.trm:150: warning: enumeration value `PSTERM_POSTSCRIPT' not handled in switch
../term/pslatex.trm:257: warning: enumeration value `PSTERM_EPSLATEX' not handled in switch
../term/pslatex.trm:257: warning: enumeration value `PSTERM_POSTSCRIPT' not handled in switch
../term/post.trm:2202: warning: enumeration value `PSTERM_POSTSCRIPT' not handled in switch
../term/post.trm:2309: warning: 'xmin_t' might be used uninitialized in this function
../term/post.trm:2309: warning: 'ymin_t' might be used uninitialized in this function
../term/post.trm:2309: warning: 'xmax_t' might be used uninitialized in this function
../term/post.trm:2309: warning: 'ymax_t' might be used uninitialized in this function

so far relatively trivial, though they ought to be fixed.
but then I get:

../term/post.trm:1463: warning: implicit declaration of function `conv_text'
../term/post.trm:1463: warning: format argument is not a pointer (arg 3)

This is bad.  Individual drivers should not be calling
back into the gnuplot core routines (conv_text is in show.c).
Is this conversion really necessary?  
Why do we care if a user manages to type in non-printing characters
in an epslatex header string?  "If it hurts, don't do it".



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

Re: compiling CVS under cygwin

[Hardy G. <nt...@ma...>]

Hans-Bernhard Broeker wrote:
:
> In other words: programs can fail to work in a text-mode mounted system 
> --- but if they do, that's clearly the programs' fault.  Binary mode 
> mounts are essentially a way to deliberately break the OS to make it 
> compatible with broken programs.
:

Hi Hans-Bernhard,

many thanks for the explanation!

So I will remount my cygwin-drives with the text option.

Hardy

Re: compiling CVS under cygwin

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

Hardy Griech wrote:
> Unfortunately there is no "auto" option for cygwins mount.

There's on in their libc, but apparently it's *still* not been exported 
to the mount options....

> What I've understood so far is, that it is safer to mount with text.  

For correctly ported programs: yes.

Standard C and POSIX only know two kinds of opening files: "binary" and 
"default".  If a program expects files to keep all their bits, it's 
supposed to say so by activating binary mode.  Failure to do so is, at 
least technically, a bug.

> What will happen if actually binary files are opened for 
> reading?  

If the program explicitly used binary mode, they'll be opened as binary,
regardless of the mount option.

 > Will a \r\n sequence cut down to \n or how is the mode then
> detected?

It's not supposed to be necessary to "detect" the mode --- the program 
opening the file is supposed to know what it's doing, and tell the OS.

In other words: programs can fail to work in a text-mode mounted system 
--- but if they do, that's clearly the programs' fault.  Binary mode 
mounts are essentially a way to deliberately break the OS to make it 
compatible with broken programs.

Re: compiling CVS under cygwin

[Hardy G. <nt...@ma...>]

Hans-Bernhard Broeker wrote:
:
> That most certainly is exactly the problem.  Yes, the actual files must 
> be compatible with cygwin's "mount" option for the volume the files are 
> on (unless that mount option is "auto", in which case it shouldn't 
> matter).  A text-mode mount will work with whatever files, but a 
> bin-mode mount won't work with CRLF-style text files.

Unfortunately there is no "auto" option for cygwins mount.

What I've understood so far is, that it is safer to mount with text.  Is 
this right?  What will happen if actually binary files are opened for 
reading?  Will a \r\n sequence cut down to \n or how is the mode then 
detected?

Seems to me that this is more a cygwin issue...

Hardy

Re: compiling CVS under cygwin

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

Hardy Griech wrote:

> Funny.  This is perhaps the problem:  I checked out gnuplot with 
> tortoisecvs without explicitly saying 'use UNIX line endings' i.e. \n only.

That most certainly is exactly the problem.  Yes, the actual files must 
be compatible with cygwin's "mount" option for the volume the files are 
on (unless that mount option is "auto", in which case it shouldn't 
matter).  A text-mode mount will work with whatever files, but a 
bin-mode mount won't work with CRLF-style text files.

Re: line color given by rgb value

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

On Friday 11 February 2005 03:40 am, Petr Mikulik wrote:
>
> However, can you please fix that the "with l ls 1" works also for
> splots, not only for plots?

In cvs.

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

Re: compiling CVS under cygwin

[Hardy G. <nt...@ma...>]

Petr Mikulik wrote:
>>if the source tree is mounted with the text option, compilation will
>>work as one expects:
>>
>>./prepare
>>./configure
>>make
>>make install
> 
> 
> I have all cygwin mounts with binmode, and it works as expected as well.
> (For portability, I prefer files with LF, not CRLF.)

Funny.  This is perhaps the problem:  I checked out gnuplot with 
tortoisecvs without explicitly saying 'use UNIX line endings' i.e. \n only.

I also must state, that I identified this as the problem, because 
config.* had filenames containing ^M in it (i.e. \r).

Perhaps a note in the INSTALL could help other people to not fall into 
this pit...

Hardy

Re: Again, epslatex terminal

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

> The patch turns out to be fairly big because I put the ASCII85 encoding
> and in its own function, thereby shuffling around a lot of code.  So there
> is an ASCII85 routine, a regular level 1 image routine--both with the same
> input/output structure.  If someone wants a new encoding, say runlength
> (which some have asked for) this works out nicely because all it means now
> is a new subroutine similar to the existing two.

There is one failure in the patch, can you please update it?

I can see there are two extraneous lines with "LT0" added to the output
postscript files added, could this be avoided?

Otherwise, the patch seems OK, so it could to cvs I think.

--
PM

Re: line color given by rgb value

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

> Your simple patch for the colorbox looks fine.
> Do you see a way to construct a similar fix for the 3D bug?

It's in cvs.

However, can you please fix that the "with l ls 1" works also for splots,
not only for plots?

set style line 1 lt rgb "#0000FF"
plot x*x with l ls 1
pause -1
splot x with l ls 1


---
PM

Re: compiling CVS under cygwin

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

> if the source tree is mounted with the text option, compilation will
> work as one expects:
>
> ./prepare
> ./configure
> make
> make install

I have all cygwin mounts with binmode, and it works as expected as well.
(For portability, I prefer files with LF, not CRLF.)

---
PM

Re: Again, epslatex terminal

[<ds...@ac...>]

> The patch turns out to be fairly big because I put the ASCII85 encoding
> and in its own function, thereby shuffling around a lot of code.  So th=
ere
> is an ASCII85 routine, a regular level 1 image routine--both with the s=
ame
> input/output structure.  If someone wants a new encoding, say runlength
> (which some have asked for) this works out nicely because all it means =
now
> is a new subroutine similar to the existing two.

I should clarify, the patch _file_ is big because of all the reorganizing=
.
 However, the actual addition to the source code is fairly small.

Dan

Re: compiling CVS under cygwin

[Hardy G. <nt...@ma...>]

I love to respond to myself, but I think I have to clarify a little bit:

if the source tree is mounted with the text option, compilation will
work as one expects:

./prepare
./configure
make
make install

Of course 'some' cygwin packets have to be installed before.

Hardy

compiling CVS under cygwin

[Hardy G. <nt...@ma...>]

Perhaps someone is interested in my experiences compiling gnuplot 4.1 
under cygwin:

one has to mount the source tree to 'text' to get gnuplot compiled 
successfully.

E.g.
mount -f -s -t "d:/src" "/src"

Hardy

Re: line color given by rgb value

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

Your simple patch for the colorbox looks fine.
Do you see a way to construct a similar fix for the 3D bug?
 
> 2. I think that the rgb command should be the same for both label and
> linetype, i.e. "rgb$color":
>         plot sin(x) lt rgbcolor "#FF00FF"

Sure. Added to cvs.

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

Re: Again, epslatex terminal

[<ds...@ac...>]

>> On that note, I've placed a patch on SourceForge (1117060) that is a f=
ix
>> or enhancement for PostScript level 1 devices.  It's been hanging arou=
nd
>> for a while.  I've just updated the thing to accomodate the change in
>> layout and variable names in post.term.  The original code was a bit o=
f
>> work.  The postscript code is tricky because it conditionally displays
>> an image in the non "level1" setting depending upon whether the device
>> is level 1 or not.  The trick is that you can't just ignore the data
>> there, it has to be "read in" from within the file itself so that
>> PostScript doesn't think the data are commands and subsequently crashe=
s.
>>
>> Anyway, it hasn't been tested by someone who has a true Level 1 printe=
r
>> (i.e., dinosaur).  But I think it is an improvement.  Doubt I will
>> update the patch again unless I ever need Level 1 support for some
>> strange reason.
>
> How much does it extend the file size?

Not by much.  Here is the structure as I have changed it when level2 is
allowed (i.e., user does not indicate "level1"):

<conditional test for Level1>
<if true>
<draw a box with "this is level 2 image" inside>
<if false>
<a groupd of commands saying to "read from file" and ignore the next N by=
tes
 of data in the file>
<end conditional>
\filter and other commands
<big block of ASCII86 image data>

With the added instructions, the "\filter" command is read and ignored.=20
Without them, "\filter" is an unrecognized command to level 1 and causes
problems.

The type bunch of code in ascii I'm guessing is 200 bytes or so (?).

>
> Is this Level1 code only for images? I think that a combination of some=
one
> printing images and using an obsolete (color?) postscript level 1 print=
er
> is
> very rare. Is the code put in only when "set term post level1" is
> specified?

No, when level1 is specified, a level one readable image is included, not
an ASCII86 filtered image.  It is bulkier, but viewable to level 1
devices.

The patch turns out to be fairly big because I put the ASCII85 encoding
and in its own function, thereby shuffling around a lot of code.  So ther=
e
is an ASCII85 routine, a regular level 1 image routine--both with the sam=
e
input/output structure.  If someone wants a new encoding, say runlength
(which some have asked for) this works out nicely because all it means no=
w
is a new subroutine similar to the existing two.

Dan

Re: line color given by rgb value

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

> Another thing:
> Why does gnuplot switch on the color palette when using an rgb-defined
> color? I think it should not do that, automatically. In this code,

I have removed this untentional behaviour by the enclosed patch. Do you like
it? Try to play with (un)commenting lines below:

#set label 1 "ahoj" at 0,1 tc palette frac 1
set label 1 "ahoj" at 0,-1 tc rgbcolor "#0000FF"
#set style line 2 lt palette frac 1
set style line 2 lt rgb "#0000FF"

plot x w l ls 2

Note:
  splot x w l # ls 2
does not work due to a bug described below.


***

There seem to be one bug and one "inconsistency" in the current explicit
"rgb" functionality:

1. The splot acts as "with line palette" instead of a plot with blue lines:

set style line 1 lt rgb "#0000FF"
plot x*x with l ls 1
pause -1
splot x with l ls 1


2. I think that the rgb command should be the same for both label and
linetype, i.e. "rgb$color":
        plot sin(x) lt rgbcolor "#FF00FF"
currently reports an error.

---
PM

Re: Again, epslatex terminal

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

> On that note, I've placed a patch on SourceForge (1117060) that is a fix
> or enhancement for PostScript level 1 devices.  It's been hanging around
> for a while.  I've just updated the thing to accomodate the change in
> layout and variable names in post.term.  The original code was a bit of
> work.  The postscript code is tricky because it conditionally displays
> an image in the non "level1" setting depending upon whether the device
> is level 1 or not.  The trick is that you can't just ignore the data
> there, it has to be "read in" from within the file itself so that
> PostScript doesn't think the data are commands and subsequently crashes.
>
> Anyway, it hasn't been tested by someone who has a true Level 1 printer
> (i.e., dinosaur).  But I think it is an improvement.  Doubt I will
> update the patch again unless I ever need Level 1 support for some
> strange reason.

How much does it extend the file size?

Is this Level1 code only for images? I think that a combination of someone
printing images and using an obsolete (color?) postscript level 1 printer is
very rare. Is the code put in only when "set term post level1" is
specified?

---
PM

Re: Again, epslatex terminal

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

> If you still have reservations to apply this patch please let me know why.

I've just added two minor corrections for docs, but otherwise I think it is
ready for cvs. I will do it when you apply them.

I hope people are comfortable with the new directory "share/" in cvs. The
"pm3d/contrib" should be merged in it somewhen in future.

---
PM

Re: Separating line color and dot/dash pattern

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

> - The obvious extension is to add a keyword "{dt|dashtype} <n>".

OK

> - A surprising number of terminal types already support dashed lines:
>     apollo be cgm dxf eepic emf epslatex fig gnugraph gpic gpr
>     hpgl iris4d metafont metapost next openstep post pslatex
>     pstricks tgif tpic unixplot win x11
>   But I suspect that other than the ones piggybacking on post.trm
>   they all disagree about specific dot/dash patterns.
>   Is this worth addressing?

Same linetype should produce the same pattern. And all terminals should
support "solid|dashed" option.

> - Another alternative is to create a small number of new linetypes.
>   I suppose these would internally be LT_DOTTED, LT_DASHED,
>   LT_DOTDASH, ..., and have negative index values (similar to -1
>   for the current LT_BORDER line type). Support for this would

Good idea.

---
PM

Re: Outputing image fields

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

>   I understand that I am probablly trying to do something that gnuplot is
> not meant for, as it deals with much more then a height field. I think I
> will use zimg to do that, though I must admit I really like gnuplot's way
> of dealing with colormap.

zimg uses exactly the same "traditional" colormap formulae.

---
PM

Re: Gnuplot for pocket pc?

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

Max Velasques wrote:
> Hi,
>    exist some version of gnuplot for pocket pc?

None that we know of.  Nor is there a plan to make such a version --- we 
already have trouble enough with the native Windows version as it is; we 
don't need more trouble with a Windows CE (or one of its myriad of 
offspring versions).

Re: Win32 printing

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

[Russell: you may want to subscribe to gnuplot-beta, to avoid the lag
created by me having to approve each of your messages to the list
through SF.net's Mailman web interface.]

Russell Lang wrote:

>> That would be putting it mildly.  As of the current release
>> version, 4.0, the 16-bit version no longer even compiles.

> So do you want all 16-bit code removed?

Not per se.  If it falls off the table as part of some major renovation,
I can accept that, but there's not (yet) a good reason to kill that code
just because we can.

>> And the 32-bit version is known to have various problems.
>> Apparently, it never worked on Win9x at all.  Neither the "print
>> this" menu entry in the graph context menu, nor the 'set output
>> 'PRN:' method.

> Neither of these should have been broken in the move to 32-bit.

AFAIK, they were broken by differences between Win9x and Windows NT.
I.e. they only failed on 9x --- a rather unusual thing, really.
Usually, it's the tougher restrictions of the NT family that break code,
not the loose ones on 9x.

[...]
>> particular, I would really like to get rid of the home-grown
>> terminal emulator and all the problems and limitations it causes.

> Doing it on one thread may be a little tricky.

May be.  I'm quite sure it won't be any trickier than the home-grown
terminal emulation already is.

Other than that, I'd say we use whatever does the job.  The main issue
to keep an eye on would be the mouse feedback stuff.  I.e. the main
input loop of gnuplot now needs to listen to *two* input streams:
the command input (console, redirection or some script file), and the
mouse feedback.  That's about the only thing that was easier in the
existing Windows version than in X11.  The X11 synchronization details
(select(), <stdio.h> buffering, blocking pipes, ...) took us most of
three years to (somewhat) finally sort out.

> Do you want gnuplot to provide the command line editing, or do you 
> want the default Windows command line editor?

I got an experimental version going around August 2003, which has
gnuplot's -DREADLINE set, i.e. gnuplot does the command-line editing,
Windows just giving us keystrokes.  It's not completely done (i.e. the
wtext.c window still shows up, but is non-functional), but it's at least
marginally usable.

Re: Again, epslatex terminal

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

Harald Harders wrote:

>Today, I have noticed that the currently available epslatex terminal has
>two bugs. Have a look at the output of this script:
>
>set terminal epslatex color 'default' 12
>set output 'epslatex-orig1.eps'
>test
>set output
>set output 'epslatex-orig2.eps'
>set style line 1 lt rgb "#DA00A0"
>plot sin(x) w l ls 1
>set output
>
>"gs epslatex-orig1.eps" results in "Error: /undefined in PolyFill" while
>"gs epslatex-orig2.eps" results "Error: /undefined in C". It is easy to
>fix these problems but I once again propose to apply my patch to cvs.
>The 'oldstyle' mode of today's version provides line styles, colors and
>symbols that are very similar to the ones of the old epslatex terminal
>(for those who did like the old behaviour).
>
>There has been positive feedback by Juergen Wieferink, Theo Hopman, and
>Andreas Keil.
>
>If you still have reservations to apply this patch please let me know why.
>  
>

I recall this.  If there are some others who've tried this patch and 
think it is an improvement, I'd say move it into CVS.

On that note, I've placed a patch on SourceForge (1117060) that is a fix 
or enhancement for PostScript level 1 devices.  It's been hanging around 
for a while.  I've just updated the thing to accomodate the change in 
layout and variable names in post.term.  The original code was a bit of 
work.  The postscript code is tricky because it conditionally displays 
an image in the non "level1" setting depending upon whether the device 
is level 1 or not.  The trick is that you can't just ignore the data 
there, it has to be "read in" from within the file itself so that 
PostScript doesn't think the data are commands and subsequently crashes.

Anyway, it hasn't been tested by someone who has a true Level 1 printer 
(i.e., dinosaur).  But I think it is an improvement.  Doubt I will 
update the patch again unless I ever need Level 1 support for some 
strange reason.

I've replaced some of the "fprintf"s with "fputs" for consistency with 
some recent changes to post.trm in CVS.

Dan

PS:  Out of town for next 2 or 3 weeks.

Re: Separating line color and dot/dash pattern

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

On Sat, 5 Feb 2005, Ethan Merritt wrote:

> On Saturday 05 February 2005 12:25 pm, Harald Harders wrote:
> > On Sat, 5 Feb 2005, Ethan Merritt wrote:
> >
> > > - The obvious extension is to add a keyword "{dt|dashtype} <n>".
> > >   In the context of setting a line style, the command would be
> > >     set style line <tag> dt <N> lt rgb "#aabbcc"
>
> > I think the keyword 'colour' is more clear because it tells what it
> > changes. And at the moment, linetype changes both color and dashtype in
> > many cases which should be preserved for compatibility.
> > Set dashtype to <N> and color to RGB value of aa, bb, cc:
> >   set style line <tag> dashtype <N> color rgb "#aabbcc"
>
> But is it really more clear?  Remember that currently the
> "line style" also includes the point type and point size.
> Is "colour" to apply to both the line and the points, or is
> it specifically the line colour?
>
> And I think there are compatibility issues. Consider the command
> 	plot "foo" with linespoints dashtype <n> color rgb "red"
>
> What exactly do you expect to happen to the points?

You are right that we also have to consider the points. I think the
keywords 'linecolour' and 'pointcolour' as well 'pointlinewidth' could
serve as start. Then, the user can set the colours of the line and the
points independently.

In general, I think the user should be able to determine the linewidth,
dashtype, color of the line as well as linewidth, size, and type of the
symbol independently. I do not like a misleading name as 'linetype' for
one of these switches. In addition, linetype is used for a different
purpose in the current version. This should be preserved.

> And what should happen on a terminal that cannot set rgb colors?

What happens with a terminal that cannot set rgb colors in the current
version? Where is the difference in adding a new keyword that only changes
the colour instead of doing multiple things including changing the colour?

The fact that some terminals may not be able to use a new feature should
not prevent us from adding this new feature. For example text rotation at
arbitrary angles has been invented even though there are terminals that
are not capable of this.

> > Escpecially for postscript there is a difference between cmyk and rgb
> > (and hsb) colours depending on the output device.
>
> So?  That's a totally orthogonal issue. Anything that depends on the
> eventual PostScript output device is clearly out of gnuplot's control.
> If you are concerned to have an hsv option, this could either be created
> as a parallel option to rgb, or else we could define a user-accessible
> string-valued function  hsv2rgb(H,S,V)  that returns "#RRGGBB". E.g.
> 	set style line 1 lt rgb hsv2rgb(H,S,V)
> Hmmm. Actually, I think you could do that anyhow right now just by
> loading a script that defined such a funciton.

That is not correct. The colorspaces RGB and CMYK are different in praxis.
The user always should use the color model that is used by the final
output device (just speak to people doing desktop publishing). For
example, to produce a presentation for a projector you should use RGB. If
you want to print on a Laser or Ink Jet printer you should use CMYK from
the start on.

Have a look at this example:

%!PS-Adobe-2.0 EPSF-2.0
%%BoundingBox: 0 0 201 100
%%EndComments
/Box { 100 0 rlineto 0 100 rlineto -100 0 rlineto closepath fill } def
newpath 0 0 1 setrgbcolor 0 0 moveto Box
newpath 1 1 0 0 setcmykcolor 101 0 moveto Box
showpage
%%Trailer

If I convert it to pdf using ghostscript 8.50 and view it with Acrobat
Reader 5.0, the nominally equal colours RGB 0,0,1 and CMYK 1,1,0,0 look
rather different.
If a users wants to reach a colour that fits to the rest of his document
he may be forced to use a different colour model then RGB.

If the output file format does not support a mixture of RGB and CMYK data
(for example pixel formats), a conversion of these colour models is
necessary, of course.

> > > - A surprising number of terminal types already support dashed lines:
> > >   But I suspect that other than the ones piggybacking on post.trm
> > >   they all disagree about specific dot/dash patterns.
> >
> > Yes, I think, all terminals should be harmonized.
>
> Good luck. There is no guarantee that any particular terminal device
> is capable of a particular dash style.  We haven't even reached a
> point where all terminals agree on colors!

I think we will never reach a more or less satisfactury state if we start
like that. If we start to harmonize some of the terminals it is better
than doing nothing.

> (Nor do I necessarily
> think they should - what looks good on the screen may not look good
> on paper).

This is an important issue. For many terminals you don't know which output
device will be used. Of course, x11 is merely for screen. But I am using
Postscript for both screen (projector presentations) and paper. Same
applies to png and jpg. And much is individual taste of the user. Thus,
the user should be able to select the colours and dash types as he wants
to use them, independently.

Regards
Harald

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

Re: Separating line color and dot/dash pattern

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

Ethan Merritt wrote:

>On Saturday 05 February 2005 01:45 pm, you wrote:
>  
>
>>Some of the colors in X11 are too bright to contrast against a gray or
>>white background.  In particular, green and cyan are difficult to see.
>>    
>>
>
>You do realize that you can redefine the X11 colors in your
>.Xdefaults file?  
>  
>

Oh yeah, I keep forgetting about that .Xdefaults file.

>After all, the appearance also depends on your local
>monitor gamma setting, and the default background color, and so on.
>  
>

You're right.  I'd say though that trying to retain color schemes across 
terminals is a good thing.  If someone wants to modify the scheme, he or 
she can.  It's quite disorienting when the color scheme changes across 
terminals.  (Yellow becoming brown seems the most egregious example I 
can think of.  Magenta to purple isn't too bad...  I know, megenta and 
purple are close enough that adjusting the screen might change one to 
another.)

Dan