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

Re: pm3d for emf terminal and point types

[Dr. J. Z. <joh...@ze...>]

On Thu, Dec 07, 2006 at 09:26:17AM -0800, Ethan Merritt wrote:
> On Thursday 07 December 2006 03:42 am, Dr. Johannes Zellner wrote:
> >
> > - I just implemented pm3d for emf which was really easy, as
> > everything was already prepared.
> > - I implemented for the emf terminal the point types as suggested in
> >   term/README.
> >
> > is it ok to commit these changes to CVS?
> 
> Sound good to me.
> 
> Do you understand emf well enough to add enhanced text mode
> support as well?  I have never found decent emf documentation,
> and so have not been able to figure out how to trigger some
> of the necessary operations.
> 
> Another item on my emf wishlist is allowing UTF-8 character sets.
> If I understand the comments in the code correctly, it used to
> allow this but someone decided to revert it to handle single byte
> encodings only.  It's not clear to me whether this was intended
> to fix a known problem, or was done for some other reason.

I don't understand emf at all ;-)
But I was smart enough to understand the existing code in emf.trm.

UTF-8 would be nice IMHO as well as some sort of enhanced text.
I found

    http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnargdi/html/msdn_enhmeta.asp

a 13 year old techical article from microsoft. Maybe the file emfwr.cxx
from openoffice could also serve as documentation of the format. I will
very likely not have the time to do any coding myself.

Btw. I would find it quite useful, if the color sequence of the line
colors would be more similar in all terminals. Emf is quite different
from postscript and X11 for example.

-- 
Johannes

Re: x2tics out mirror bug

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

Ethan A Merritt wrote:
> Bug:
> 
>> set x2tics mirror
>> show x2tics
>>    x2tics OFF
> 
> 
> Bleah.  Someone didn't notice the comments warning that
> NO_TICS is a bit mask, not an integer constant.
> 
> All the tests (ticmode == NO_TICS) are incorrect, and must be changed to
> (ticmode & NO_TICS == 0)

Oh, that explains it.  I couldn't make rhyme or reason out of what was happening.

Thanks,

Dan

Re: x2tics out mirror bug

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

Bug:
>  set x2tics mirror
>  show x2tics
>     x2tics OFF

Bleah.  Someone didn't notice the comments warning that
NO_TICS is a bit mask, not an integer constant.

All the tests (ticmode == NO_TICS) are incorrect, and must be changed to
(ticmode & NO_TICS == 0)

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

Re: direction field in gnuplot

[Leo <sd...@gm...>]

On FRI, 8 DEC 2006, Hans-Bernhard Bröker wrote:

> Leo wrote:
>> I learned from Maxima mailing list that direction field can't be done
>> in Gnuplot. 
>
> If you describe what exactly "direction field" is supposed to mean, odds 
> are you'll find out that's untrue.
>
> I suspect that what you mean is a plain and simple vector field, which 
> gnuplot can do quite fine.  For starters, have a look at 'vector.dem' 
> and supporting documentation (--> help vectors)
>

Jaime E. Villate replied on the issue of direction field and gnuplot
in maxima here:
http://thread.gmane.org/gmane.comp.mathematics.maxima.general/13159/focus=13255

I believe Gnuplot can do the same even though probably not as
integrative as those shown in
http://maxima.sourceforge.net/docs/manual/en/maxima_63.html#SEC228.

Could someone do an reply on this issue to the thread in maxima list?
Thank you.

-- 
Leo

Re: direction field in gnuplot

[Leo <sd...@gm...>]

On FRI, 8 DEC 2006, Hans-Bernhard Bröker wrote:

> Leo wrote:
>> I learned from Maxima mailing list that direction field can't be done
>> in Gnuplot. 
>
[...]
> I suspect that what you mean is a plain and simple vector field, which 
> gnuplot can do quite fine.  For starters, have a look at 'vector.dem' 
> and supporting documentation (--> help vectors)
>

Thank you for the pointer. That's exactly what I am looking for. I
have started a discussion on maxima list on this issue.

-- 
Leo

Re: direction field in gnuplot

[<HBB...@t-...>]

Leo wrote:
> I learned from Maxima mailing list that direction field can't be done
> in Gnuplot. 

If you describe what exactly "direction field" is supposed to mean, odds 
are you'll find out that's untrue.

I suspect that what you mean is a plain and simple vector field, which 
gnuplot can do quite fine.  For starters, have a look at 'vector.dem' 
and supporting documentation (--> help vectors)

4.2rc2: "set style fill transparent" does not work

[Wagner M. Jr <me...@dc...>]

Hi all,

I just downloaded and compiled 4.2rc2. It is running OK.

I understood that it supports transparent 2D figures as the
transparent.2.gnu demo shows. 

Am I missing something?

Should I enable something for compilation?

Best,

Wagner

Re: x2tics out mirror bug

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

Ethan A Merritt wrote:

> Strangely. If you do this sequentially then the problem doesn't occur.
> Instead of your 3 commands above, try
> 
> unset xtics
> set x2tics
> set x2tics out
> set x2tics out mirror
> plot x
> 
> That produces the expected plot, and furthermore "show x2tics" now
> admits that the tics are not OFF.

OK, well that certainly changes things in more ways than can be explained, and it at least looks consistent.  Note that this sequencing seems necessary for ytics and y2tics as well.

I've entered a bug report into the (now graphics-laden) SourceForge tracker.

Dan

Re: x2tics out mirror bug

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

On Friday 08 December 2006 02:27, Daniel J Sebald wrote:
> Is this a bug that should be considered to fix before 4.2?
> 
> unset xtics
> set x2tics out mirror
> plot x

> I thought it would be one simple thing.  But it appears to be a couple things.

Yeah, there seems to be a bookkeeping problem.  If you ask for status at
this point you get

gnuplot> show x2tics
xyplane ticslevel is 0.5
        x2-axis tics are OUT,   major ticscale is 1 and minor ticscale is 0.5
        x2-axis tics:   OFF

Huh? OFF?  They are showing in the plot.

Strangely. If you do this sequentially then the problem doesn't occur.
Instead of your 3 commands above, try

unset xtics
set x2tics
set x2tics out
set x2tics out mirror
plot x

That produces the expected plot, and furthermore "show x2tics" now
admits that the tics are not OFF.

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

x2tics out mirror bug

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

Is this a bug that should be considered to fix before 4.2?

unset xtics
set x2tics out mirror
plot x

Note that the tic text is written on the wrong side of the tic mark anchor point.  Leaving off the "mirror" part seems to work OK.  Note that this works properly

unset ytics
set y2tics out mirror
plot x

Oh wait.  No it doesn't.  The placement of the tic text is correct, but the positioning of the border isn't.

I thought it would be one simple thing.  But it appears to be a couple things.

Dan

direction field in gnuplot

[Leo <sd...@gm...>]

Hi list,

I learned from Maxima mailing list that direction field can't be done
in Gnuplot. That's quite a disadvantage for such a wonderful tool. The
solution in maxima is to used another app (xmaxima) for that matter.

I am wondering is this true in the latest CVS that gnuplot does not
support direction field plot.

Many thanks.

-- 
Leo

Re: pm3d for emf terminal and point types

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

On Thursday 07 December 2006 03:42 am, Dr. Johannes Zellner wrote:
>
> - I just implemented pm3d for emf which was really easy, as
> everything was already prepared.
> - I implemented for the emf terminal the point types as suggested in
>   term/README.
>
> is it ok to commit these changes to CVS?

Sound good to me.

Do you understand emf well enough to add enhanced text mode
support as well?  I have never found decent emf documentation,
and so have not been able to figure out how to trigger some
of the necessary operations.

Another item on my emf wishlist is allowing UTF-8 character sets.
If I understand the comments in the code correctly, it used to
allow this but someone decided to revert it to handle single byte
encodings only.  It's not clear to me whether this was intended
to fix a known problem, or was done for some other reason.

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

Re: latest gnuplot

[Dr. J. Z. <joh...@ze...>]

On Thu, Dec 07, 2006 at 02:05:48PM +0100, Petr Mikulik wrote:
> > I just fetched the latest gnuplot from CVS and obverved a few oddities:
> > 
> > 1. The first "splot ... w pm3d" command does nothing at all. Typing the
> >    command again pops up the X11 window as desired.
> > 2. pm3d seems not to work in X11 any more. It just shows a solid red
> >    surface.
> > 
> > Any ideas? -- everything worked ok with a verion of about end of june
> > this year.
> 
> Of course it works! We would notice it immediately.
> 
> Isn't gnuplot_x11 mixed from an older release?

thanks for the hint ;-)
and sorry for bandwidth. Everything is ok now.

-- 
Johannes

Re: latest gnuplot

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

> I just fetched the latest gnuplot from CVS and obverved a few oddities:
> 
> 1. The first "splot ... w pm3d" command does nothing at all. Typing the
>    command again pops up the X11 window as desired.
> 2. pm3d seems not to work in X11 any more. It just shows a solid red
>    surface.
> 
> Any ideas? -- everything worked ok with a verion of about end of june
> this year.

Of course it works! We would notice it immediately.

Isn't gnuplot_x11 mixed from an older release?

---
PM

latest gnuplot

[Dr. J. Z. <joh...@ze...>]

Hello,

I just fetched the latest gnuplot from CVS and obverved a few oddities:

1. The first "splot ... w pm3d" command does nothing at all. Typing the
   command again pops up the X11 window as desired.
2. pm3d seems not to work in X11 any more. It just shows a solid red
   surface.

Any ideas? -- everything worked ok with a verion of about end of june
this year.

-- 
Johannes

pm3d for emf terminal and point types

[Dr. J. Z. <joh...@ze...>]

Hello,

- I just implemented pm3d for emf which was really easy, as everything
  was already prepared.
- I implemented for the emf terminal the point types as suggested in
  term/README.

is it ok to commit these changes to CVS?

-- 
Johannes

Re: --enable-thin-spline

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

> Any plot using dgrid3d is expected to come out different with 
> --enable-thin-splines.  Some will differ more than others.
> 
> In the longer term, --enable-thin-splines really should be replaced by 
> an 'algorithm' option in 'set dgrid3d'.
> 
> And for what it's worth: I'm with Ethan on this: now is certainly not 
> the time to change the default state of this setting.

Thanks for explanation. Please consider adding such an option into 4.3.

---
PM

Re: --enable-thin-spline

[<HBB...@t-...>]

Ethan Merritt wrote:

> On the other hand, if SuSE has been shipping it that way for some
> years and we have not received any bug reports on it, that may be
> evidence that it is in good shape.

--enable-thin-spline differs from most other options in gnuplot in that 
it doesn't just enable or disable a feature, but rather chooses a 
different method to implement the same feature: set dgrid3d.

Thin-plate splines provide a radically different way of producing a 
continuous surface from non-gridded data that can then be sampled to 
yield a grid.

I.e. it's not really a question of receiving bug reports, it's one of 
getting different output from the same gnuplot script, caused by a build 
option reported only where most people never look: in 'show version 
long', in a form they won't understand.

> Could somebody provide an example plot where this option makes
> a difference?

Any plot using dgrid3d is expected to come out different with 
--enable-thin-splines.  Some will differ more than others.

In the longer term, --enable-thin-splines really should be replaced by 
an 'algorithm' option in 'set dgrid3d'.

And for what it's worth: I'm with Ethan on this: now is certainly not 
the time to change the default state of this setting.

Re: --enable-thin-spline

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

On Tuesday 05 December 2006 11:14 am, Petr Mikulik wrote:
> Looking into gnuplot's rpm file on OpenSUSE Linux, its ChangeLog says
> that they compile gnuplot with --enable-thin-spline. What about
> having this option default?

I have no personal experience with it, so I do not know how much
difference it makes, or whether there are any problems with it.

I am reluctant to change the defaults for the 4.2 release at this
late date, just because I assume 99% of the testing so far has used
the existing set of defaults.

On the other hand, if SuSE has been shipping it that way for some
years and we have not received any bug reports on it, that may be
evidence that it is in good shape.

Could somebody provide an example plot where this option makes
a difference?

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

--enable-thin-spline

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

Looking into gnuplot's rpm file on OpenSUSE Linux, its ChangeLog says that 
they compile gnuplot with --enable-thin-spline. What about having this 
option default?

---
PM

Re: Mac wxt build errors with gnuplot-4.2.rc2

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

Joe Koski wrote:
> on 11/25/06 2:00 PM, Timoth=E9e Lecomte at tim...@en... wrot=
e:
>
>  =20
>> Joe Koski wrote:
>>    =20
>>> Ethan, Timoth=E9e,
>>>
>>> I tried building gnuplot-4.2.rc2 on my G5 Mac with OS X 10.4.8, Xcode=
2.4
>>> Developer tools, and same pango/cairo that I had built previously. Th=
ere
>>> have been no changes to my build routines since I successfully built
>>> gnuplot-4.2.rc1.
>>>
>>> During the build, all goes well until:
>>>
>>> <snip> I seem to be missing some parts (a header file?) necessary to =
build
>>> the wxt
>>> terminal.
>>>  =20
>>>      =20
>> You still need to patch in src/wxterminal with wxmac.diff
>> I have not committed it yet to the CVS, although I should have...
>>
>> Thank you again for your efforts in testing this.
>>
>> Best regards,
>>
>> Timoth=E9e
>>    =20
>
> Timoth=E9e,
>
> Yes, that fixed the problem. Thanks. Yes, I think that the patch can be
> submitted, and then we can worry about bundling later.
>
> Joe
>  =20
I have just committed the patch to both CVS HEAD and 4.2 branch. Let's=20
hope we'll find how to bundle it correctly now.

Best regards,

Timoth=E9e

Re: RC2 on Suse 9.3

[Jacques Le B. <Jac...@ob...>]

> On Monday 27 November 2006 01:16 pm, Timoth=E9e Lecomte wrote:
>> Jacques Le Bourlot a =E9crit :
>> * libgd:
>>    I had to manually create a link from libgd.so.2 to libgd.so in
>> /usr/lib. It was not found by configure. Also gd was installed, but
>> not gd-devel so that "make" crashed when looking for gd.h
>
> This is telling you that you should have installed gd-devel.
> Forcing the build process to continue when a required package is
> missing is not a good idea.
>
That's what I did immediattely! I did not "force" the build process any
further.

>> > * Pango:
>> >    SuSE comes with pango 1.10.2 and I could not find newer
>> > packages. I compiled 1.10.4 and had no further problems at
>> > configuration/compilation time. But...
>> >
>> > * Wxt:
>> >    The terminal works (i.e. I get all the nice plots in the
>> > window). However all texts are ridiculously small (size 1 point?)
>> > and useless. I could not figure out why.
>>
>> It is precisely the problem I was trying to address when I added the
>> restriction on pango not being 1.10.2.
>> Here is the corresponding thread:
>> http://comments.gmane.org/gmane.comp.graphics.gnuplot.devel/5319
>
> The wxt terminal works just fine with libpango 1.10.0
>
> I think the symptom of invisibly small font sizes comes from not
> having properly initialized fontconfig.  I originally suffered from
> the same problem, but installing and initializing fontconfig fixed it.
>
I will try that. However, It'll have to wait for a few days (I'm an
astrophysicist and teacher at the University: I have very few time to
spare).

>
>> > * UTF8:
>> >   Results of "utf8.dem" are unreliable. May come from my fonts
>> > installation (which I never really understood). More specifically,
>> > I can not set encoding to "utf8"
>
I'll explore also the font issue. I usually use X11 as a term, then turn
to postscript at the very end.

Thank you for the advices.

Jacques Le Bourlot

Re: RC2 on Suse 9.3

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

On Monday 27 November 2006 01:16 pm, Timoth=E9e Lecomte wrote:
> Jacques Le Bourlot a =E9crit :
> * libgd:
>    I had to manually create a link from libgd.so.2 to libgd.so in
> /usr/lib. It was not found by configure. Also gd was installed, but
> not gd-devel so that "make" crashed when looking for gd.h=20

This is telling you that you should have installed gd-devel.
=46orcing the build process to continue when a required package is
missing is not a good idea.

> > * Pango:
> >    SuSE comes with pango 1.10.2 and I could not find newer
> > packages. I compiled 1.10.4 and had no further problems at
> > configuration/compilation time. But...
> >
> > * Wxt:
> >    The terminal works (i.e. I get all the nice plots in the
> > window). However all texts are ridiculously small (size 1 point?)
> > and useless. I could not figure out why.
>
> It is precisely the problem I was trying to address when I added the
> restriction on pango not being 1.10.2.
> Here is the corresponding thread:
> http://comments.gmane.org/gmane.comp.graphics.gnuplot.devel/5319

The wxt terminal works just fine with libpango 1.10.0

I think the symptom of invisibly small font sizes comes from not
having properly initialized fontconfig.  I originally suffered from
the same problem, but installing and initializing fontconfig fixed it.


> > * UTF8:
> >   Results of "utf8.dem" are unreliable. May come from my fonts
> > installation (which I never really understood). More specifically,
> > I can not set encoding to "utf8"=20

It is not necessary to set encoding to utf8.
The "encoding" tells how to interpret 1-byte characters.
utf8 uses multibyte characters *instead* of using the 1-byte
representations.
=20
> > and could not find how to get such characters as "=E9", "=E0", etc...

=E9 is Unicode code point 00E9
=E0 is Unicode code point 00E0

If your locate is set to fr_FR.UTF-8, then when you type =E0 on the
keyboard it generates a two-byte utf-8 sequence that represents that
Unicode code point.  This is *different* than the 1-byte representation
used by iso_8859_15.  You cannot mix them.  You must pick one or the
other (preferably utf-8).

If you are using KDE, a convenient tool to explore this is kcharselect. =20
I'm sure some equivalent tool must exist on other desktops.

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

Re: RC2 on Suse 9.3

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

Jacques Le Bourlot a =E9crit :
> Bonjour,
>
> I just compiled and installed RC2 on a Linux Laptop with SuSE 9.3 (+ al=
l
> latest upgrades I could find). I had very few issues. Thank you for the
> nice job! Here are the pbs:
>
> <...>
> * Pango:
>    SuSE comes with pango 1.10.2 and I could not find newer packages. I
> compiled 1.10.4 and had no further problems at
> configuration/compilation time. But...
>
> * Wxt:
>    The terminal works (i.e. I get all the nice plots in the window).
> However all texts are ridiculously small (size 1 point?) and useless. I
> could not figure out why.
>  =20
It is precisely the problem I was trying to address when I added the=20
restriction on pango not being 1.10.2.
Here is the corresponding thread:=20
http://comments.gmane.org/gmane.comp.graphics.gnuplot.devel/5319

I don't clearly remember if I tried with pango 1.10.4. Would you mind=20
trying with a newer version of pango, in the 1.12 or 1.14 series ?
I'll try to compile gnuplot with pango 1.10.4, but I won't be able to do=20
it until tomorrow evening.


> * UTF8:
>   Results of "utf8.dem" are unreliable. May come from my fonts
> installation (which I never really understood). More specifically, I ca=
n
> not set encoding to "utf8" (I know it is not in the list...), and could
> not find how to get such characters as "=E9", "=E0", etc... which are
> mandatory in french. Note: I use the standard SuSE setting : LANG =3D
> fr_FR.UTF-8, so neither "default" nor "iso_8859_15" work.
>  =20
Please tell us what terminal you're using since text encoding is=20
terminal specific.

Best regards,

Timoth=E9e Lecomte

Re: RC2 on Suse 9.3

[<HBB...@t-...>]

Jacques Le Bourlot wrote:

> * libgd:
>    I had to manually create a link from libgd.so.2 to libgd.so in
> /usr/lib. 

You should never have to do that.  Either ldconfig should do that 
automatically at installation time, or there must be some good reason it 
didn't.

 > It was not found by configure.

That was actually a good thing, since it didn't really work.  configure 
should only find actually working libraries.

 > Also gd was installed, but not
> gd-devel so that "make" crashed when looking for gd.h (which was not
> there). probably configure should look for both libgd and gd.h

Not really.  It only has to look for gdlib-config and trust its output.