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

Re: How to generate <ul> & <li> or \begin{itemize} in documentation?

[Ethan A M. <eam...@gm...>]

On Sunday, 11 September 2011, Mojca Miklavec wrote:
> Dear list,
> 
> What is the syntax in help for terminals that would generate
> <ul><li>...</li>...</ul> syntax in HTML output, \begin{itemize} in
> LaTeX (PDF documentation) and a normal "-" in text mode?

.../docs/README  explains the format of gnuplot.doc
But there is no provision for bulleted lists.  I agree with you that
it would be useful, but it would have to be added to all of the 
various doc2XXX.c conversion programs.

> Also, how could one replace TeX with \TeX in gnuplot.tex that is used
> to generate gnuplot.doc?

??
That's backwards.  gnuplot.doc is used to generate gnuplot.tex.
I suppose you could add a search-and-replace filter in doc2tex.c,
but it would probably be simpler to run sed 's/ TeX/ \\TeX/' on
the output. You could add it as an extra line in the Makefile rule
for gnuplot.tex

	Ethan

-- 
Tradition is not the worship of ashes, but the preservation of fire.
  - Gustav Mahler

Re: adding picins.sty to docs/

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

On Sunday, 11 September 2011, Mojca Miklavec wrote:
> 
> Would it be possible to put picins.sty to docs/, so that documentation
> (pdffigures) will at least compile without problems?

The idea was that we provide by default a simple target "make pdf"
that does not require any local customization of the TeX environment
or figure-generation tools.  That should be sufficient for most
development purposes.  The more complex target "make pdffigures"
is used to generate a pdf verion of the manual, with figures, that
is included in the distribution package.  So the end user gets a copy
of gnuplot.pdf that includes figures, and need not have TeX installed
at all.

On the other hand, it's not that hard to regenerate a copy of the
pdf+figures from the CVS source yourself.   It is true that you may
have to tweak the local TeX environment to successfully use the
"make pdffigures" target rather than "make pdf".  But you clearly have
far more TeX experience than I do, so it seems surprising that you
would have difficulty installing one extra *.sty file on your system.

	cheers,

		Ethan

Re: old tex files in repository

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

On Sunday, 11 September 2011, Mojca Miklavec wrote:
> Dear list,
> 
> When I try to build gnuplot, the following two files are modified:
> 
> # modified:   share/LaTeX/gnuplot-lua-tikz.sty
> # modified:   src/version.c

The file share/LaTeX/gnuplot-lua-tikz.sty is not in the CVS
repository.  It is auto-generated at build time.

> The second one only has a trivial change:
> 
>  const char gnuplot_patchlevel[] = "0";
> -const char gnuplot_date[] = "August 2011";
> +const char gnuplot_date[] = "2011-09-09 ";
>  const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998,
> 2004, 2007-2011";
> 
> but the first one seems to be completely outdated:

You must have somehow left an old copy in your source tree.  
It is not in the current CVS, so it will never be updated.

> Should gnuplot-lua-tikz.sty be removed from CVS (if it is
> auto-generated)?

See above.  It was removed from CVS long ago.

> I also noticed that pdffigures.tex is rebuilt automagically:
> 
> --- a/docs/pdffigures.tex
> +++ b/docs/pdffigures.tex
> @@ -1,7 +1 @@
> -%
> -% $Id: pdffigures.tex,v 1.1 2010/03/08 23:41:15 sfeam Exp $
> -%
> -% This file is modified dynamically by "make" depending on whether or not
> -% figures are to be included in the documentation
> -% \usepackage{graphicx}
> -% \usepackage{picins}
> +
> 
> Why is pdffigures.tex included in CVS if it is built during "make pdf" anyway?

The comment you quote attempts to explain this.
The top-level file titlepag.tex contains a line
\include{pdffigures}
In order to toggle whether or not the figure-generation code is
_really_ used, the Makefile either creates appropriate file contents
for pdffigures.tex or creates an empty file with that name.

Perhaps someone more knowledgeable in TeX syntax knows how make the
latex "\include" statement conditional on some external variable,
which would be an alternative way to accomplish the same thing.
 
> I would really really really like to have ./configure script in CVS
> repository, but the main reason against that was that this is a
> generated file. Still, it would help many users without (or with old
> version of) autotools to be able to build gnuplot. 

> On the other hand these files (pdffigures, gnuplot-lua-tikz.sty, ...)
> are rebuild without my intervention and my version control tools constantly
> complain that these files have been changed. I need to be very careful
> not to commit the changes.

You obviously have a different work-flow than I do.
The contents of my local copy of the CVS source are normally changed
only by the "cvs update" operation, so the issues you mention
do not arise.  I am guessing that because you are locally modifying
these files (and not deleting obsolete files?) the various time 
stamps and directory contents are not truly in sync with the 
CVS repository, which is causing the problems you see.

I realize the different people have different work-flows, so 
"it works for me" is not the end of the story.  But I suggest that
at a minimum you need to identify a command that gives you a clean
copy of current CVS, one that doesn't also contain obsolete or
locally-modified file versions.

	Ethan

How to generate <ul> & <li> or \begin{itemize} in documentation?

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

Dear list,

What is the syntax in help for terminals that would generate
<ul><li>...</li>...</ul> syntax in HTML output, \begin{itemize} in
LaTeX (PDF documentation) and a normal "-" in text mode?

Also, how could one replace TeX with \TeX in gnuplot.tex that is used
to generate gnuplot.doc?

Thank you,
   Mojca

old tex files in repository

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

Dear list,

When I try to build gnuplot, the following two files are modified:

# modified:   share/LaTeX/gnuplot-lua-tikz.sty
# modified:   src/version.c

The second one only has a trivial change:

 const char gnuplot_patchlevel[] = "0";
-const char gnuplot_date[] = "August 2011";
+const char gnuplot_date[] = "2011-09-09 ";
 const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998,
2004, 2007-2011";

but the first one seems to be completely outdated:

--- a/share/LaTeX/gnuplot-lua-tikz.sty
+++ b/share/LaTeX/gnuplot-lua-tikz.sty
@@ -1,382 +1,13 @@
 %%
-%%  This is the style file for the gnuplot PGF/TikZ terminal
-%%
-%%  It is associated with the 'gnuplot.lua' script, and usually generated
-%%  automatically. So take care whenever you make any changes!
+%%  LaTeX wrapper for gnuplot-tikz style file
 %%
 \NeedsTeXFormat{LaTeX2e}
 \ProvidesPackage{gnuplot-lua-tikz}%
-          [2009/05/26 (rev. 96a) GNUPLOT Lua terminal style]
+          [2011/07/21 (rev. 100) GNUPLOT Lua terminal style]

-\RequirePackage{tikz,xxcolor,ifpdf,ifxetex}
+\RequirePackage{tikz}

-\usetikzlibrary{arrows,patterns,plotmarks}
+\usetikzlibrary{arrows,patterns,plotmarks,backgrounds}
+\input gnuplot-lua-tikz-common.tex
...


Should gnuplot-lua-tikz.sty be removed from CVS (if it is
auto-generated)? Or at least: can somebody please make sure that the
latest version will be in repository?

I also noticed that pdffigures.tex is rebuilt automagically:

--- a/docs/pdffigures.tex
+++ b/docs/pdffigures.tex
@@ -1,7 +1 @@
-%
-% $Id: pdffigures.tex,v 1.1 2010/03/08 23:41:15 sfeam Exp $
-%
-% This file is modified dynamically by "make" depending on whether or not
-% figures are to be included in the documentation
-% \usepackage{graphicx}
-% \usepackage{picins}
+

Why is pdffigures.tex included in CVS if it is built during "make pdf" anyway?


I would really really really like to have ./configure script in CVS
repository, but the main reason against that was that this is a
generated file. Still, it would help many users without (or with old
version of) autotools to be able to build gnuplot. On the other hand
these files (pdffigures, gnuplot-lua-tikz.sty, ...) are rebuild
without my intervention and my version control tools constantly
complain that these files have been changed. I need to be very careful
not to commit the changes.

Thank you,
    Mojca

adding picins.sty to docs/

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

Dear list,

Would it be possible to put picins.sty to docs/, so that documentation
(pdffigures) will at least compile without problems?
The file is located at
http://mirror.ctan.org/macros/latex209/contrib/picins/picins.sty and
has been removed from most TeX distributions. It would help a lot if
it was present in the folder where docs are built, together with all
the headers etc.

Thank you,
   Mojca

Re: complie error current cvs source on djgpp

[Tatsuro M. <tma...@ya...>]

Hello

With your patch djgpp binaries are successfully built.
Thanks!

Tatsuro

--- On Mon, 2011/9/5, Ethan Merritt  wrote:

> On Sunday, 04 September 2011, Tatsuro MATSUOKA wrote:
> > Hello
> > In compiling current cvs (2011-09-04) , change in 2011-09-03 gives compile errors, canvas.rm:620 and svg.trm: 1035 because in config.dj2,'USE_MOUSE' is disabled.
> 
> Thanks for the report.
> 
> Let me think....
> The canvas and svg terminals can easily support mousing even
> if the interactive gnuplot session itself does not.
> So I would prefer a fix that allows these terminals to produce 
> mousing information even when USE_MOUSE is not defined.
> Could you please try the attached patch instead?
> 
>     Ethan
> 
> > I have attached quick hack and compile term.c and built gnuplot for djgpp.
> > (attached files.)
> > 
> > Regards
> > 
> > Tatsuro
> 
> 

Re: complie error current cvs source on djgpp

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

On Sunday, 04 September 2011, Tatsuro MATSUOKA wrote:
> Hello
> In compiling current cvs (2011-09-04) , change in 2011-09-03 gives compile errors, canvas.rm:620 and svg.trm: 1035 because in config.dj2,'USE_MOUSE' is disabled.

Thanks for the report.

Let me think....
The canvas and svg terminals can easily support mousing even
if the interactive gnuplot session itself does not.
So I would prefer a fix that allows these terminals to produce 
mousing information even when USE_MOUSE is not defined.
Could you please try the attached patch instead?

	Ethan

> I have attached quick hack and compile term.c and built gnuplot for djgpp.
> (attached files.)
> 
> Regards
> 
> Tatsuro

complie error current cvs source on djgpp

[Tatsuro M. <tma...@ya...>]

Hello
In compiling current cvs (2011-09-04) , change in 2011-09-03 gives compile errors, canvas.rm:620 and svg.trm: 1035 because in config.dj2,'USE_MOUSE' is disabled.

I have attached quick hack and compile term.c and built gnuplot for djgpp.
(attached files.)

Regards

Tatsuro

Re: gnuplot and plotting equations

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

On 09/04/11 17:44, Anna Lappala wrote:
> Dear gnuplot users,
>
> I have an enquiry related to equations; for instance, I would like to
> plot the 12-6 lennard-jones equation
>
> with r=1, sigma =1 and global cutoff rc= 1.12
>
> I'd appreciate any help and advice. I am a self-taught student, and
> apologise if this question is trivial.
>
> with best wishes,
> A
>
>


please note this is a development list , not for basic user help enquiries.

there's a google group if you are having trouble reading the doc.

best regards.

Re: gnuplot and plotting equations

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

On Sun, Sep 4, 2011 at 17:44, Anna Lappala wrote:
>
> Dear gnuplot users,
> I have an enquiry related to equations; for instance, I would like to plot the 12-6 lennard-jones equation
>
> with r=1, sigma =1 and global cutoff rc= 1.12

    f(r,sigma)=4*((sigma/r)**12-(sigma/r)**6)
    plot [0:3] [:5] f(x,1)

What exactly do you mean with global cutoff? That you would like to
stop drawing at 1.12?

    g(r,rcut,sigma)=(r<rcut) ? f(r,sigma) : 1/0
    plot [0:3] [:5] g(x,1.12,1)

Mojca

gnuplot and plotting equations

[Anna L. <mol...@ya...>]

Dear gnuplot users, 

I have an enquiry related to equations; for instance, I would like to plot the 12-6 lennard-jones equation
 

with r=1, sigma =1 and global cutoff rc= 1.12

I'd appreciate any help and advice. I am a self-taught student, and apologise if this question is trivial.

with best wishes,
A

Re: pngcairo and resolution

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

On Saturday, 03 September 2011, Ethan Merritt wrote:
> On Saturday, 03 September 2011, Mojca Miklavec wrote:
> > Dear list,
> > 
> > The pngcairo terminal behaves a bit weird when setting the size:
> > 
> > gnuplot> set term pngcairo size 10cm,10
> > Options are ' fontscale 1.0 size 10.00cm, 10.00cm '
> > 
> > gnuplot> set term pngcairo size 10,10cm
> > Options are ' fontscale 1.0 size 0.35cm, 10.00cm '
> 
> What's weird about that? The default unit is pixels.
> Unless you force it otherwise, both the y dimension
> is are assumed to be in the same units as the x dimension.

Bleah. Please forgive typose.  That should read:

 Unless you force it otherwise, the y dimension is
 assumed to be in the same units as the x dimension.

	Ethan

Re: auto-inrementing 'set output'

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

On Saturday, 03 September 2011, Mojca Miklavec wrote:
> Dear list,
> 
> I would like to know if there is any trick to create a lot of PNG
> images without calling "set output ..." for each of them.
> 
> If I use gnuplot with PostScript, PDF, any TeX-based on any
> interactive terminal, I get all the plots without having to call set
> output for each of them.

The PNG standard has no provision for multiple images in a single
output file.  There is a variant format MNG that does, but it has
never caught on.

The only "trick" I can think of is to do
    gnuplot> set term gif animate nooptimize
    gnuplot> set output 'all-in-one.gif'
and then afterwards split out all the individual image frames
into separate png images.
    [1] convert all-in-one.gif image.png
    [2] ls *.png
    image-0.png image-1.png image-2.png
   

	Ethan


> 
> I would like to be able to set something like
>     set output pattern "filename-%03d.png"
> and then just call "plot" without having to worry about filenames.
> 
> (Writing a script to generate plots is not an option and auto-insert
> "set output" is not an option.)
> 
> Have there ever been any plans about such functionality?
> 
> Thank you,
>     Mojca
> 
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better 
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: pngcairo and resolution

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

On Saturday, 03 September 2011, Mojca Miklavec wrote:
> Dear list,
> 
> The pngcairo terminal behaves a bit weird when setting the size:
> 
> gnuplot> set term pngcairo size 10cm,10
> Options are ' fontscale 1.0 size 10.00cm, 10.00cm '
> 
> gnuplot> set term pngcairo size 10,10cm
> Options are ' fontscale 1.0 size 0.35cm, 10.00cm '

What's weird about that? The default unit is pixels.
Unless you force it otherwise, both the y dimension
is are assumed to be in the same units as the x dimension.

> On top of that I do find it a bit annoying that I'm not able to check
> how many pixels will be the final image size.

Specifiying the size in pixels is the default.
Just stick with that and you'll be fine.
Specifying in inches or cm doesn't really make any sense, since it
depends on the resolution of the output device.  The fact that the
terminal recognizes sizes in "in" or "cm" is largely an artifact
of sharing the code between pngcairo and pdfcairo.

> Also, the following note is probably not exact:
> 
>  The width of all lines in the plot can be modified by the factor <lw>
>  specified in `linewidth`. The default linewidth is 0.25 points.
>  (1 "PostScript" point = 1/72 inch = 0.353 mm)
> 
> >From what I understand the line width is one pixel (which makes it 1
> point at 1 dpi).

True. That sentence is left over from the pdf documentation.
It should not appear also in the png documentation.

> I would also like to be able to change resolution, but it seems that
> this is currently not possible.

A bitmap image (png, gif, bmp, ...) does not have a resolution.
Only the output device has a resolution.
It is true that some programs use the comment field of a png image
to store a suggested output resolution, but that does not actually
change anything in the image itself.

auto-inrementing 'set output'

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

Dear list,

I would like to know if there is any trick to create a lot of PNG
images without calling "set output ..." for each of them.

If I use gnuplot with PostScript, PDF, any TeX-based on any
interactive terminal, I get all the plots without having to call set
output for each of them.

I would like to be able to set something like
    set output pattern "filename-%03d.png"
and then just call "plot" without having to worry about filenames.

(Writing a script to generate plots is not an option and auto-insert
"set output" is not an option.)

Have there ever been any plans about such functionality?

Thank you,
    Mojca

pngcairo and resolution

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

Dear list,

The pngcairo terminal behaves a bit weird when setting the size:

gnuplot> set term pngcairo size 10cm,10
Options are ' fontscale 1.0 size 10.00cm, 10.00cm '

gnuplot> set term pngcairo size 10,10cm
Options are ' fontscale 1.0 size 0.35cm, 10.00cm '

On top of that I do find it a bit annoying that I'm not able to check
how many pixels will be the final image size.


Also, the following note is probably not exact:

 The width of all lines in the plot can be modified by the factor <lw>
 specified in `linewidth`. The default linewidth is 0.25 points.
 (1 "PostScript" point = 1/72 inch = 0.353 mm)

>From what I understand the line width is one pixel (which makes it 1
point at 1 dpi).


I would also like to be able to change resolution, but it seems that
this is currently not possible.

Mojca

[offtopic] lapdf: new latex package for drawing graphs

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

The output of this package is really nice:
    http://www.ctan.org/pkg/lapdf

I didn't try it out, but it is in many cases comparable with gnuplot
(except that it doesn't do 3D, uses a different syntax and serves a
slightly different purpose).

Mojca

Re: gnuplot on mingw64 status

[Tatsuro M. <tma...@ya...>]

Hello Bastian Märkisch

Thank you for your reply.

--- On Thu, 2011/9/1, Bastian Märkisch wrote:

> Dear Tatsuro,
> 
> thanks for the update. Out of curiosity: what benefits for Windows users 
> do you expect from a 64bit build?

At present, I expect little benefits for 64 bit build for the gnuplot.  
Octave for windows on 64 bit build has a benefit to treat large size data.
Before I challenge the octave build I have tried 64 bit build on the gnuplot.

Another point: Window 7 64 bit is now implemented even on $400 PC.
Applications will move to 64 bit in the future as win16 was replaced by win32.  


> Am 01.09.2011 01:34, schrieb Tatsuro MATSUOKA:
> > I have been tried to build gnuplot on mingw64 platform.
> > Unfortunately the trail was not successful.
> > However, I will the the current status as a memo.
> >
> > 1. build tools
> > Cygwin + mingw64 cross compile tool chain is used.
> > The reason of the selection is the above is the most systematic at this moment.
> >
> > 2. Problem of cvs source
> > The gdiplus is not implemented on mingw64.  So that I cannot compile wgdiplus.cpp.
> >
> > 3. Build on gnuplot-4.4.3 source
> > Because current cvs requires gdiplus. So I have tried using gnuplot-4.4.3 source.
> 
> Just to clarify: current cvs should not require gdiplus (Watcom does not 
> support gdiplus at the moment). There are conditionals in the code 
> (HAVE_GDIPLUS). For MinGW (32) this is enabled unconditionally in 
> config/config.mgw - just disable that line. You would also have to 
> remove the library from LDLIBS in config/mingw/Makefile.
> 

> > gnuplot.exe is genarated. But it does not work due error 0xc000007b (The application was unable to start correctly.).
> >
> 
> Does your setup work for other programs, e.g. some simple "Hello world!" 
> program? Could it be that your program accidentally links to some 32bit 
> library? The HTML help library (htmlhelp) would be a possible candidate.
> 
> Btw. the Win SDK header ntstatus.h defines STATUS_INVALID_IMAGE_FORMAT 
> as 0xc000007b.

Thank you for your variable suggestions. I will try them later.

Regards

Tatsuro

Re: gnuplot on mingw64 status

[Bastian M. <bma...@we...>]

Dear Tatsuro,

thanks for the update. Out of curiosity: what benefits for Windows users 
do you expect from a 64bit build?

Am 01.09.2011 01:34, schrieb Tatsuro MATSUOKA:
> I have been tried to build gnuplot on mingw64 platform.
> Unfortunately the trail was not successful.
> However, I will the the current status as a memo.
>
> 1. build tools
> Cygwin + mingw64 cross compile tool chain is used.
> The reason of the selection is the above is the most systematic at this moment.
>
> 2. Problem of cvs source
> The gdiplus is not implemented on mingw64.  So that I cannot compile wgdiplus.cpp.
>
> 3. Build on gnuplot-4.4.3 source
> Because current cvs requires gdiplus. So I have tried using gnuplot-4.4.3 source.

Just to clarify: current cvs should not require gdiplus (Watcom does not 
support gdiplus at the moment). There are conditionals in the code 
(HAVE_GDIPLUS). For MinGW (32) this is enabled unconditionally in 
config/config.mgw - just disable that line. You would also have to 
remove the library from LDLIBS in config/mingw/Makefile.


> gnuplot.exe is genarated. But it does not work due error 0xc000007b (The application was unable to start correctly.).
>

Does your setup work for other programs, e.g. some simple "Hello world!" 
program? Could it be that your program accidentally links to some 32bit 
library? The HTML help library (htmlhelp) would be a possible candidate.

Btw. the Win SDK header ntstatus.h defines STATUS_INVALID_IMAGE_FORMAT 
as 0xc000007b.

Bastian

> It seem not to be easy work to build gnuplot on mingw64.
>
> Any suggestions are welcome.
>
> Regards
>
> Tatsuro
>

gnuplot on mingw64 status

[Tatsuro M. <tma...@ya...>]

Hello

I have been tried to build gnuplot on mingw64 platform.
Unfortunately the trail was not successful.
However, I will the the current status as a memo.

1. build tools
Cygwin + mingw64 cross compile tool chain is used.
The reason of the selection is the above is the most systematic at this moment.

2. Problem of cvs source
The gdiplus is not implemented on mingw64.  So that I cannot compile wgdiplus.cpp.

3. Build on gnuplot-4.4.3 source
Because current cvs requires gdiplus. So I have tried using gnuplot-4.4.3 source.
gnuplot.exe is genarated. But it does not work due error 0xc000007b (The application was unable to start correctly.). 

It seem not to be easy work to build gnuplot on mingw64.

Any suggestions are welcome.

Regards

Tatsuro

I have to stu

Re: destination of tex files

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

Dear list,

I filed a bug report on
    http://sourceforge.net/tracker/?func=detail&aid=3401370&group_id=2055&atid=102055
and also explained what would have to be done instead.

Please fix this weird functionality. It works fine for Ethan, but only
because of some "cheating":
    sed "s%^.*share/%$TEXDIR/share/%"
In general this replacement is not applied (not everyone uses "share"
for texlive). The worst point is that it doesn't even work on default
TeX Live installation.

Thank you,
    Mojca


On Thu, Jan 13, 2011 at 09:01, Mojca Miklavec wrote:
> Dear list,
>
> When I run ./configure I get
>
> TeX files will be installed in
> /usr/local/usr//usr/local/texlive/2010/../texmf-local/tex/latex/gnuplot
>
> However that should have been
>    /usr/local/texlive/texmf-local/tex/latex/gnuplot
> and not the complicated string above.
>
> The configure script says:
>
>    if test "$TEXDIR" = "no"; then
>    #in the case prefix = NONE us ac_default_prefix
>    TEXDIR="${prefix}"
>    test "x$TEXDIR" = xNONE && TEXDIR=$ac_default_prefix
> # at this point TEXDIR is set to "/usr/local"
>    TEXDIR=`$KPSEXPAND $TEXDIR/usr/'$TEXMFLOCAL'/tex/latex/gnuplot \
>            |sed "s%^.*share/%$TEXDIR/share/%"`
> # and now /usr is appended
> # TEXMFLOCAL is /usr/local/texlive/2010/../texmf-local
> # so I get
>    "/usr/local"+"/usr"+"/usr/local/texlive/2010/../texmf-local"+"/tex/latex/gnuplot"
> # which is certainly wrong
>
>
> I have no idea what the sed is supposed to do (here it doesn't do
> anything anyway), but the overall functionality is simply wrong here.
> I don't plan to use that functionality anyway, but it would be nice to
> fix it.
>
> Thanks a lot,
>   Mojca
>

Re: bug in tikz

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

Dear Peter and others,

by checking some old code (mostly thanks to github) I think that I
have found the solution for the problem I described last time [sorry
for top-posting]. It was actually Peter's code that probably got lost
somehow/for unknown reason.

When I tested tikz with context in February 2011 it worked fine, but I
admit that back then I was still using my own copy of tikz terminal
before it got included into CVS. It worked at that time (my own copy),
however at the moment the color handling is broken completely
(documents don't even compile).

I'm not sure if this solves all problems (or if it doesn't introduce
any new problems), but at least the basic functionality is restored if

\tikzset{rgb color/.code={\pgfutil@definecolor{.}{rgb}{#1}\color{.}}}
\tikzset{global rgb color/.code={\pgfutil@definecolor{.}{rgb}{#1}\color{.}}}
\tikzset{global color/.code={\color{#1}}}

gets replaced by

\tikzset{rgb color/.code={\pgfutil@definecolor{.}{rgb}{#1}\tikzset{color=.}}}
\tikzset{global rgb
color/.code={\pgfutil@definecolor{.}{rgb}{#1}\pgfsetcolor{.}}}
\tikzset{global color/.code={\pgfsetcolor{#1}}}

in gnuplot-lua-tikz-common.tex.

May I ask for changing this?

https://sourceforge.net/tracker/?func=detail&aid=3401068&group_id=2055&atid=102055

Thank you,
   Mojca


On Fri, Aug 19, 2011 at 01:33, Mojca Miklavec wrote:
> Dear Peter,
>
> there seems to be a problem with colours in ConTeXt with TikZ terminal
> in gnuplot. I'm not sure since when the problem exists (when I was
> last testing it worked fine, but that was probably several months
> ago).
>
> Please keep in mind that \color is an existing command in ConTeXt that
> uses a different syntax than LaTeX, so your code using \color is not
> really portable.
>
> % wrapper for color settings
> \def\gpcolor#1{\tikzset{global #1}}
> \tikzset{rgb color/.code={\pgfutil@definecolor{.}{rgb}{#1}\color{.}}}
> \tikzset{global rgb color/.code={\pgfutil@definecolor{.}{rgb}{#1}\color{.}}}
> \tikzset{global color/.code={\color{#1}}}
>
>
> Here is a minimal context document to reproduce the problem (you may
> try to use TeX Live 2011 to compile it; TikZ has been patched, so it
> works with ConTeXt again):
>
> \usemodule[gnuplot-lua-tikz]
>
> \starttext
> \starttikzpicture[gnuplot]
> \gpcolor{color=gp lt color border}
> \gpsetlinetype{gp lt border}
> \draw[gp path] (1.410,7.185)--(1.410,0.730)--(12.048,0.730)--(12.048,7.185)--cycle;
> \stoptikzpicture
> \stoptext
>
> Here is the error:
>
> ! Use of \color doesn't match its definition.
> \pgfkeys@code #1\pgfeov ->\color {
>                                  #1}
> \pgfkeysifdefined ...ifcsname pgfk@#1\endcsname #2
>                                                  \else #3\fi
> \pgfkeys@unpack ...pgfeov \else \pgfkeys@case@one
>                                                  \fi \fi
> \pgfkeys@normal ...\pgfkeysnovalue =\pgfkeys@stop
>                                                  \pgfkeys@parse
> \pgfkeys@@qset ...aultpath {#2/}\pgfkeys@parse #3,
>                                                  \pgfkeys@mainstop \def \pg...
> l.5 \gpcolor{color=gp lt color border}
>
> ?
>
> You either need to write a different code for ConTeXt or use some
> other strategy to apply colours.
>
> Thank you very much,
>    Mojca
>

Re: plotting two sets of random points

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

2011/8/30 Bastian Märkisch wrote:
> Or, if you use the current CVS version, you could use loops to generate a
> data file:
>
>  set print "points.dat"
>  print "# dataset 1"
>  do for [i=1:100] { print rand(0), rand(0) }
>  print ""; print ""
>  print "# dataset 2"
>  do for [i=1:200] { print rand(0)+3, rand(0)+3 }
>  unset print

Thank you. This works perfect, and "set table" is also perfectly suitable.

Mojca

Re: plotting two sets of random points

[Bastian M. <bma...@we...>]

Or, if you use the current CVS version, you could use loops to generate 
a data file:

   set print "points.dat"
   print "# dataset 1"
   do for [i=1:100] { print rand(0), rand(0) }
   print ""; print ""
   print "# dataset 2"
   do for [i=1:200] { print rand(0)+3, rand(0)+3 }
   unset print

Bastian

Am 30.08.2011 19:24, schrieb Daniel J Sebald:
> On 08/30/2011 10:58 AM, Mojca Miklavec wrote:
>> Hello,
>>
>> I would like to fill one square area of the plot with 100 random
>> points and another one with n random points (n is a parameter).
>>
>> If I use
>>      set samples 100
>>      set parametric
>>      plot rand(0),rand(0) w lines, rand(0)+3,rand(0)+3
>> then I cannot vary number of points - I need an equal number of each points.
>>
>> Is there a quick remedy for that (apart from writing a C program to
>> create a list of points for me)?
>
> Mojca, I think it should be straightforward to generate the random data
> in a couple files using the "table" feature, then pull that data into
> gnuplot.  As examples, look at the "random.dem" demo where the number of
> samples is set quite often.  Just do a couple quick so-called plots to
> create the data files changing the number of samples in between.
>
> Dan
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

-- 
Dr. Bastian Märkisch
Physikalisches Institut, Universität Heidelberg
Philosophenweg 12
69120 Heidelberg
Tel.: +49-6221-549214
Fax: +49-6221-549343