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

Re: widthflag in enhanced text mode

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

On Tuesday 01 November 2005 07:59 am, Timoth=E9e Lecomte wrote:
>=20
> After a review of the code of the enhanced text mode, I think the
> 'widthflag' argument is never used (I mean it's always true). It's a
> flag which is told to mean that the size of the character to draw must
> not be taken into account if it's set to false.

As you state, this flag indicates whether or not the current text
position should be set at the beginning (FALSE) or end (TRUE) of
the string being passed.  This flag is set to FALSE in order to
overprint text (enhanced text mode symbol '~').

See line 2507 of term.c


	Ethan














> The code in term.c=20
> (enhanced_recursion) just propagates its value without modifying it, and
> terminals initialize it to true. For example, see post.trm
> (ENHPS_put_text). It may be interesting to remove this flag... It may
> help me (and other terminal developpers) to avoid to implement useless
> code ;-) ... and maybe to avoid possible errors ...
>=20
> Any idea about this ? (Ethan A Merritt especially, as it was you who
> abstracted this text mode)
>=20
> Best regards,
>=20
> Timoth=E9e Lecomte
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Downl=
oad
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>=20

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

Re: widthflag in enhanced text mode

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

Hans-Bernhard Broeker wrote:

> Timoth=E9e Lecomte wrote:
>
>> After a review of the code of the enhanced text mode, I think the
>> 'widthflag' argument is never used (I mean it's always true).=20
>
>
> Your review missed the important part of the code.
>
> Yes, "widthflag" is always passed into the recursion as TRUE, by the
> terminal drivers.  But it will sometimes be changed to FALSE in
> recursive calls from enhanced_recursion to itself.  Basically,
> widthflag is the implementation of the '~' overprinting feature ---
> find it in the source and you'll see this argument being passed as
> 'FALSE'.
>
Wow ! I missed my magnifier ;-)
Indeed, I had forgotten the way overprinting works. So, let's forget my
suggestion, as implement this widthflag...

Thanks you very much for your quick answer. I will try to pay more
attention the next time I think something is useless !

Timoth=E9e Lecomte

Re: widthflag in enhanced text mode

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

Timoth=E9e Lecomte wrote:
> After a review of the code of the enhanced text mode, I think the
> 'widthflag' argument is never used (I mean it's always true).=20

Your review missed the important part of the code.

Yes, "widthflag" is always passed into the recursion as TRUE, by the=20
terminal drivers.  But it will sometimes be changed to FALSE in=20
recursive calls from enhanced_recursion to itself.  Basically, widthflag =

is the implementation of the '~' overprinting feature --- find it in the =

source and you'll see this argument being passed as 'FALSE'.

widthflag in enhanced text mode

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

Hi !

After a review of the code of the enhanced text mode, I think the
'widthflag' argument is never used (I mean it's always true). It's a
flag which is told to mean that the size of the character to draw must
not be taken into account if it's set to false. The code in term.c
(enhanced_recursion) just propagates its value without modifying it, and
terminals initialize it to true. For example, see post.trm
(ENHPS_put_text). It may be interesting to remove this flag... It may
help me (and other terminal developpers) to avoid to implement useless
code ;-) ... and maybe to avoid possible errors ...

Any idea about this ? (Ethan A Merritt especially, as it was you who
abstracted this text mode)

Best regards,

Timoth=E9e Lecomte

wxWidgets terminal : new round

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

Hello !

I am happy to provide an updated patch for the wxWidgets terminal, which =
goes, as
usually, a little further !

The patch on sourceforge :
http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1267434&grou=
p_id=3D2055&atid=3D302055
Some screenshots :
http://tipote.free.fr/wxt12.png
http://tipote.free.fr/wxt13.png
http://tipote.free.fr/wxt14.png

Changes in this patch :
* rendering is done offscreen via the cairo library. This gives to the us=
er really good-looking plots thanks to line antialiasing !
And it gives me a more consistent drawing library... Of course, you need =
to have cairo installed.
It may seem another overhead, but in fact cairo is needed by gtk>2.8.

* No longer use the readline thread, do all gnuplot<->term communication =
via _waitforinput.
It avoids to modify core gnuplot files, the main loop is no longer affect=
ed.
The patch is now completely safe as far as other terminals are concerned.

* implement 'pause mouse'
( not very exciting : * implement 'suspend' )

Bug fixing :
* should compile cleanly with a unicode-enabled wxwidgets library
* reworked pattern/solid fill, much consistent

What is remaining in my 'todo' list ? The following :
* I plan to use the pango library to manage text. As you will see, cairo =
draws text almost correctly (symbol font is working - in
particular), but there are still some alignement problems. Pango will giv=
e solid functions to calculate complete text extents.
The pango dependency is not a problem under unix, as wxwidgets already de=
pends on gtk, which depends on pango and cairo.
* I have still not tested under Windows.
* clipboard bug (two plots in clipboard) remains

I hope you will enjoy these changes and I will be pleased to have your ad=
vice.

Best regards,
Timoth=E9e Lecomte

Re: color loop for gd.trm

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

> | But both should not "differ too much". Maybe a "screen_color_sequence"
> | option for postscripts?
>
> I don't know such option of postscript terminal.

That was a pure proposal.

> | It would be really great if someone unitifies the sequence for at least 16
> | colors.
>
> I am sorry I can't understand many good opinions from many
> authors well, and I seem the topic have spreaded too widely.

If someone writes down a sequence of 16, 32, or ... colors which will be the 
same on all terminals, than we can vote to put it there.

> In png terminal, we can set any color sequence. And some users
> want to know how to set it to the same one of x11 (or win) term.
> I use the color sequence setting of png terminal, but the test
> command don't make the same image because png terminal use
> original color over the user setting.

Currently "many" terminals have the same color seq as the postscript 
terminal, for at least the first "few" color items.

> Is not useful to introduce such looping option (limitation of use
> of colors) to png terminal ?

It would be nice to have this feature consistent for all terminals.

---
PM

Re: mozilla plugin

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

On Tuesday 25 October 2005 11:01 am, Mangas wrote:
> hi all,
> Having a gnuplot plugin for mozilla would be quite useful to me for a web
> application I'm writing (my server is too resource limited for gnuplot).  Before
> I dive into the task, I figured I would check if others have already put some
> thought or development effort into a gnuplot browser plugin.  Would folks (other
> than me) find such a plugin useful?   Any feedback would be appreciated.

Please see my web page for examples of gnuplot use via the web:

  http://www.bmsc.washington.edu/people/merritt/gnuplot_test.html

Now that you remind me, I realize that I have not tested that
demo page since moving it to a new web server, so I don't promise
that the actual demo is functional at the moment, although the
description and instructions should still be valid.

You might also have a look at using the svg terminal driver.
It produces svg files that can be embedded in normal html and
viewed server-side by an svg plugin.  A lot more could be done
to test and improve this driver, so if you are looking for
a place to start this might be a good one.  For instance,
it is possible to add client-side mousing interactions with
embedded svg code. Here are some web pages that point to 
examples using svg + mousing:

  http://www.mit.edu/afs/athena/course/11/11.951/www/media/SVG.html
  http://www.carto.net/papers/svg/samples/


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

Re: color loop for gd.trm

[Shigeharu T. <sh...@ie...>]

shige 10/27 2005
----------------

| Date: Fri, 21 Oct 2005 18:01:56 +0200 (CEST)
| From: Petr Mikulik <mi...@ph...>
| To: Shigeharu TAKENO <sh...@ie...>
| Cc: merritt@u.washington.edu, gnu...@li...
| Subject: Re: color loop for gd.trm
=====
| > | So your goal is not to reduce the total number of colors, instead
| > | it is to have the same default colors on all terminals?
| >
| > No. I only want to realize x11 or win term's color loops on png
| > term simply.
=====
| Then there should be these groups of color terminals, each group with the 
| same color sequence:
|    screen&bitmaps:
|         x11, windows, pm, wx
|         png, gif, jpeg, ...
|         svg, cgm, wmf, ...
|         xfig, corel, ...
|    postscript and other paper printings:
|         postscript, pdf, pslatex, pstex
| 
| But both should not "differ too much". Maybe a "screen_color_sequence" 
| option for postscripts?

I don't know such option of postscript terminal.

| It would be really great if someone unitifies the sequence for at least 16 
| colors.

I am sorry I can't understand many good opinions from many 
authors well, and I seem the topic have spreaded too widely. So I
explain my opinion.

In png terminal, we can set any color sequence. And some users 
want to know how to set it to the same one of x11 (or win) term.
I use the color sequence setting of png terminal, but the test
command don't make the same image because png terminal use 
original color over the user setting. 
So, I think I will be able to set simply if png terminal has the
color loop option.

Is not useful to introduce such looping option (limitation of use
of colors) to png terminal ?

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

mozilla plugin

[Mangas <man...@gm...>]

hi all,
Having a gnuplot plugin for mozilla would be quite useful to me for a web
application I'm writing (my server is too resource limited for gnuplot).  Before
I dive into the task, I figured I would check if others have already put some
thought or development effort into a gnuplot browser plugin.  Would folks (other
than me) find such a plugin useful?   Any feedback would be appreciated.

cheers,
-mangas

Re: [ gnuplot-Patches-1218873 ] Change text rotating angle from int to float

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

On Monday 24 October 2005 12:04 pm, mi...@ph... wrote:
> > rotated text, you can easily use some variant of
> >  set label "`date`".
> 
> This is not portable to Windows.

Windows doesn't support rotated text to begin with,
so this seems like a quibble.


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

Re: [ gnuplot-Patches-1218873 ] Change text rotating angle from int to float

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

> rotated text, you can easily use some variant of
>  set label "`date`".

This is not portable to Windows.

---
PM

Re: [ gnuplot-Patches-1218873 ] Change text rotating angle from int to float

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

Harald Harders wrote:

> With your argument that I could use an ordinary label I also could say
> that the function timestamp was useless.

It quite possibly might be.  That's what happens if you add generic 
implementations of some features (the sprintf() function) several years 
after other people added some very specifically target special cases 
('set timestamp', my number-printing extension to 'set label').

OTOH, there are still some things that 'set timestamp' does, but a 
similar 'set label' doesn't: it gets space reserved for itself by the 
global layout function, boundary().

Re: [ gnuplot-Patches-1218873 ] Change text rotating angle from int to float

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

On Sun, 23 Oct 2005, Ethan A Merritt wrote:

> On Sunday 23 October 2005 03:00 pm, Harald Harders wrote:
> > float a = 0.0;
> > if (a == 0) ...
> >
> > always is true? I don't think so.
>
> IEEE standard guarantees this.  Even in the case that an architecture
> can represent both +0 and -0,  it is required that +0 == -0.

Good to hear. But as Petr sais, this does not count for angles
that are multiples of 90 deg. Thus, I think it is the saves way to
introduce a range in the test for horizontal or vertical texts.

> >> The only place a rotation angle gets set is in parse_label_options().
> > I find more: 3555, 4020
>
> True. This may be telling us that these places
> ("set tics" and "set {xyz}tics") should call parse_label_options()
> rather than duplicating the code locally.

Independent of this problem, yes.

> > Sooner or later, this will also have to be added in line 3715 (by the
> > way, funny that there still are texts not rotatable by arbitrary
> > angles).
>
> You want to rotate the time-stamp?  That seems a little bit overboard.
> If you really want to write the data on a plot in a fancy font or
> rotated text, you can easily use some variant of   set label "`date`".

I think all text objects should be handled equally. Thus, every text
object should be rotatable. This would eas handling and documentation. We
could say 'Text can be rotated by using the option `rotate by`'. If you or
I find it useful to rotate a specific type of text does not matter there.

With your argument that I could use an ordinary label I also could say
that the function timestamp was useless.

> > Another thing could be thought of:
> > Terminals that can only set term horizontally or vertically should
> > switch from horizontal to vertical text when exceeding 45 degrees, not
> > when going from zero to one. What do you mean?
>
> I think that if someone really wants 45 degree text, they will be
> equally unhappy with either 0 or 90.

45 Degrees was an arbitrary example. A user that gives 10 deg will be more
happy with horizontal text than with vertical text. And vertical text is
what happens at the moment.

Best regards
Harald

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

Re: 'help matrix' -- Re: [Bug #1264105] In currrent CVS version plotting matrix is broken

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

>> I would keep the x, y and z for both plot and splot cases, and add that
>> the default using for plot is
>>     plot 'a.dat' matrix using 1:3
>> and not using 1:2 which makes no good sense for matrices.
>
> Sorry, I must be really dense today.
> I am just not understanding your way of naming things.
>
> In a 2D plot we are plotting y = f(x).
> x is taken from the first using spec.
> y is taken from the second using spec.
> There is no z.
>
> So when you say   "plot 'a.dat' matrix using 1:3"
> you are asking for x from column 1 and y from column 3.
> How can it be correct to document column 3 as being z
> in this case?

I consider matrix as a 3D object, and I draw its section in 2D.

See 'help binary general' and 'help binary general examples' -- it's the 
same thing, just binary not ascii, and also plot as (x,y,z) via "plot" in 
2D.

> Maybe we need to write totally separate sections for the 2D case
> and the 3D case.

I tried that in my proposal text for the two help sections, with examples.

> section. I'll hand it back to you.
> Or maybe somebody else wants to take a stab at it?

At the moment I stay with the proposed text.

---
PM

Re: [Bug #1264105] In currrent CVS version plotting matrix is broken

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

>>>>> x = $1, y = $2 (autogenerated row and column index of the matrix)
>
> That's indeed at least slightly strange.  It boils down to two questions, 
> which are strongly inter-connected:
>
> 1) Why not use existing pseudo-column numbers 0 and -1, instead of 1 and 2?

I think $1, $2 and $3 is logic for this matrix case.

> 2) Should
>
> 1 2 3
> 4 5 6
> 7 8 9
>
> read by the ordinary routines, or to
>
> 0 0 1
> 1 0 2
> 2 0 3

yes, to this one, as it now works -- just the docs is missing

>> You don't find it confusing that in 2D plots you need to say
>>    plot 'data' matrix using ($1):($3)

No, because you "plot" (in 2D) a 3D object (matrix with axes). That's the 
same as for "plot ... with image".

> Thus my suggestion is: we make up our mind about the answers to the above 
> questions, and add to 'help matrix' accordingly.

That's what I meant when sending proposal for the new text of 'help matrix' 
and 'help matrix ascii'. Please update it if  you like.

---
PM

Re: color loop for gd.trm

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

>> Then there should be these groups of color terminals, each group with the 
>> same color sequence:
>>   screen&bitmaps:
>>     x11, windows, pm, wx
>>     png, gif, jpeg, ...
>
> Neither of the below is particular 'screen', and none of them is a bitmap. 
> So I don't see convincing reasons they should use the 'screen'
> colour sequence, instead of the 'paper' one.
>>     svg, cgm, wmf, ...
>>     xfig, corel, ...

What is your proposal for the color unification?

---
PM

Re: color loop for gd.trm

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

Petr Mikulik wrote:

> Then there should be these groups of color terminals, each group with 
> the same color sequence:
>   screen&bitmaps:
>     x11, windows, pm, wx
>     png, gif, jpeg, ...

Neither of the below is particular 'screen', and none of them is a 
bitmap.  So I don't see convincing reasons they should use the 'screen'
colour sequence, instead of the 'paper' one.

>     svg, cgm, wmf, ...
>     xfig, corel, ...

Re: [ gnuplot-Patches-1218873 ] Change text rotating angle from int to float

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

Harald Harders wrote:
> I don't trust C compilers that they will return exactly 0 when you set a
> variable to 0 in all cases. Does the ANSI C standard define
> that
> 
> float a = 0.0;
> if (a == 0) ...
> 
> always is true? 

Pretty much so. For zero literals, that is. As soon as you use any kind
of computation that your maths book says yields zero, all bets are off.

> Another thing could be thought of:
> Terminals that can only set term horizontally or vertically should switch
> from horizontal to vertical text when exceeding 45 degrees, not when going
> from zero to one. What do you mean? 

As part of your change from integer to float, which is a complete break 
of the existing terminal API anyway, that modification makes sense.  As 
part of the previous extension, where we just extended the 
interpretation of an int argument that was meant to be boolean (rotate 
by 90 degrees or not), it wouldn't have.

Re: [Bug #1264105] In currrent CVS version plotting matrix is broken

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

Ethan A Merritt wrote:
> On Saturday 22 October 2005 02:55 pm, Petr Mikulik wrote:
> 
> 
>>>> x = $1, y = $2 (autogenerated row and column index of the matrix)

That's indeed at least slightly strange.  It boils down to two 
questions, which are strongly inter-connected:

1) Why not use existing pseudo-column numbers 0 and -1, instead of 1 and 2?

2) Should

1 2 3
4 5 6
7 8 9

read as 'matrix' be equivalent to a file

1
2
3

4
5
6

7
8
9

read by the ordinary routines, or to

0 0 1
1 0 2
2 0 3

0 1 4
1 1 5
2 1 6

0 2 7
1 2 8
2 2 9

The current implementation seems to be implying the latter format, which 
  in turn makes column numbers 1, 2 a suitable choice.  It effectively 
gives x values $1 = $0, and y vales $2 = column(-1).

> You don't find it confusing that in 2D plots you need to say
>    plot 'data' matrix using ($1):($3)

Well, given the current documentation (as in: lack of) what 'matrix' 
actually means in terms of column numbers, any expectations would be 
wrong by default.

Thus my suggestion is: we make up our mind about the answers to the 
above questions, and add to 'help matrix' accordingly.

Re: 'help matrix' -- Re: [Bug #1264105] In currrent CVS version plotting matrix is broken

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

On Sunday 23 October 2005 10:38 pm, mi...@ph... wrote:
> > "Column 3" may or may not be a Z value, depending
> > on what kind of graph you are describing.
>
> I would keep the x, y and z for both plot and splot cases, and add that
> the default using for plot is
>     plot 'a.dat' matrix using 1:3
> and not using 1:2 which makes no good sense for matrices.

Sorry, I must be really dense today.
I am just not understanding your way of naming things.

In a 2D plot we are plotting y = f(x).
x is taken from the first using spec.
y is taken from the second using spec.
There is no z.

So when you say   "plot 'a.dat' matrix using 1:3"
you are asking for x from column 1 and y from column 3.
How can it be correct to document column 3 as being z
in this case?


> >   Matrix values are read in a row at a time, i. e.,
> >           M11 M12 M13 M14 ...   (i=1)
> >           M21 M22 M23 M24 ...   (i=2)
> >           M31 M32 M33 M34 ...   (i=3)
> >           ... ... ... ... Mij
> >
> >   The interpretation of columns in the "using" specification for
> >   matrix data is different from the usual case. "$1" refers to the
> >   matrix row index i, "$2" refers to the matrix column index j,
> >   and "$3" refers to the matrix entry Mij.
>
> Indexing starts from 0. 

Oops. Yes.

> Further, x is the column index j, y is row index i.

Yeah, I'm not doing so well in describing this either.
And on top of that we may be suffering from a difference in
naming conventions.  I am now uncertain whether the term
"row index" means the same thing to you that it does to me.
And even if it does, there are people in the world that use
a different convention so maybe it is better not to use the
terms at all.

I agree that the x value of the plot is taken from the index j.

But neither i nor j is "y" in the sense of a 2D graph coordinate.
The y value is take from Mij.

If there are multiple lines in the data file, then i will be
counting out successive plots in the 2D graph. So it is neither
"x" nor "y", but rather it is "plot number".

Maybe we need to write totally separate sections for the 2D case
and the 3D case.

Anyhow, I don't seem to be having much luck at writing this
section. I'll hand it back to you.
Or maybe somebody else wants to take a stab at it?

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

Re: [ gnuplot-Patches-1218873 ] Change text rotating angle from int to float

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

>> But where can these rounding errors occur?
>> Not internal to gnuplot, because gnuplot does not calculate
>> text rotation angle internally anywhere that I can think of.
>
> I don't trust C compilers that they will return exactly 0 when you set a
variable to 0 in all cases.

The rounding error correction could be useful for all multiples of 90 deg
rotations, if they were calculated from n*pi/2; mainly if there are
special terminal routines for vertical text.

---
PM

Re: 'help matrix' -- Re: [Bug #1264105] In currrent CVS version plotting matrix is broken

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

> I'm still confused by the documentation, and will try to
> clarify it. For example, you suggest
>
>> X- and y-indices of the matrix correspond to column and row index of the
>
> But this is not really correct, as the use of "plot <foo> matrix"
> demonstrates.  "Column 3" may or may not be a Z value, depending
> on what kind of graph you are describing.

I would keep the x, y and z for both plot and splot cases, and add that
the default using for plot is
    plot 'a.dat' matrix using 1:3
and not using 1:2 which makes no good sense for matrices.

>   Matrix values are read in a row at a time, i. e.,
>           M11 M12 M13 M14 ...   (i=1)
>           M21 M22 M23 M24 ...   (i=2)
>           M31 M32 M33 M34 ...   (i=3)
>           ... ... ... ... Mij
>
>   The interpretation of columns in the "using" specification for
>   matrix data is different from the usual case. "$1" refers to the
>   matrix row index i, "$2" refers to the matrix column index j,
>   and "$3" refers to the matrix entry Mij.

Indexing starts from 0. Further, x is the column index j, y is row index i.

> Does this description seem OK to you?

Please combine it with my longer description with example for both 'help
matrix' and 'help matrix ascii'.

---
PM

Re: [ gnuplot-Patches-1218873 ] Change text rotating angle from int to float

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

On Sunday 23 October 2005 03:00 pm, Harald Harders wrote:
> float a = 0.0;
> if (a == 0) ...
>
> always is true? I don't think so. 

IEEE standard guarantees this.  Even in the case that an architecture
can represent both +0 and -0,  it is required that +0 == -0.

Yes, I know that not all C compilers require IEEE floating point.
But I am inclined to say that if your compiler is so broken that
it fails to store 0 as 0, then using it to build gnuplot will reveal
bigger problems than accurate text rotation :-) 

>> The only place a rotation angle gets set is in parse_label_options().
> I find more: 3555, 4020

True. This may be telling us that these places 
("set tics" and "set {xyz}tics") should call parse_label_options()
rather than duplicating the code locally.

> Sooner or later, this will also have to be added in line 3715 (by the
> way, funny that there still are texts not rotatable by arbitrary
> angles).

You want to rotate the time-stamp?  That seems a little bit overboard.
If you really want to write the data on a plot in a fancy font or
rotated text, you can easily use some variant of   set label "`date`".

> Another thing could be thought of:
> Terminals that can only set term horizontally or vertically should
> switch from horizontal to vertical text when exceeding 45 degrees, not
> when going from zero to one. What do you mean?

I think that if someone really wants 45 degree text, they will be
equally unhappy with either 0 or 90.

> And we really should find out which terminals are capable of arbitrary
> text angles but do not use it right now.

Sure. I originally added it to all the terminal types I could test
at the time. And there's a patch on SourceForge that adds it to metapost.
But there remain other terminal types I cannot test, or I do not have
documentation for their output device capabilities.

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

Re: [ gnuplot-Patches-1218873 ] Change text rotating angle from int to float

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

Ethan,

I will also post this mail to the mailing list because at least parts of
it can be interesting to the gnuplot community.

On Sun, 23 Oct 2005, Ethan A Merritt wrote:

> On Sunday 23 October 2005 01:50 pm, you wrote:
> > I do not agree that (angle == 0) is sufficient. Many
> > terminals switch from horizontal text to vertical text
> > (angle 90) if the given angle is different from 0. If small
> > rounding errors lead to vertical text instead of horizontal
> > text, this is a severe bug.
>
> But where can these rounding errors occur?
> Not internal to gnuplot, because gnuplot does not calculate
> text rotation angle internally anywhere that I can think of.

I don't trust C compilers that they will return exactly 0 when you set a
variable to 0 in all cases. Does the ANSI C standard define
that

float a = 0.0;
if (a == 0) ...

always is true? I don't think so. May be, most architectures do so. But
all? When learning programming I have always been told not to test against
an exact value when using floating variables.

> The only place a rotation angle gets set is in
> parse_label_options().
> So it should be sufficient to check in that one place.
>
> --- gnuplot/src/set.c   2005-10-09 19:44:36.000000000 -0700
> +++ gnuplot-cvs/src/set.c       2005-10-23 14:27:18.995207128 -0700
> @@ -4741,7 +4788,9 @@

I find more: 3555, 4020
Sooner or later, this will also have to be added in line 3715 (by the way,
funny that there still are texts not rotatable by arbitrary angles).

With the approach in my patch, all newly introduced angles are covered
automatically. And rounding errors of a bad C compiler implementation are
eliminated. The number of calles to these functions is not too bad to slow
down plots since normally, not too many texts are put into a plot (in
comparison to lines, for instance).

Another thing could be thought of:
Terminals that can only set term horizontally or vertically should switch
from horizontal to vertical text when exceeding 45 degrees, not when going
from zero to one. What do you mean? But I think this could be a seperate
patch after this one.

And we really should find out which terminals are capable of arbitrary
text angles but do not use it right now. I have found at least one of
them.

Best regards
Harald

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

Re: 'help matrix' -- Re: [Bug #1264105] In currrent CVS version plotting matrix is broken

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

On Sunday 23 October 2005 12:23 am, Petr Mikulik wrote:
>
> It would be nice to organize that
>  	plot 'a.dat' matrix
> is equivalent to
>  	plot 'a.dat' matrix using 1:3

OK. That part is now in cvs.
I'm still amazed that this works.
Who knew that you could plot data rows?

I'm still confused by the documentation, and will try to 
clarify it. For example, you suggest

> The z-values are read in a row at a time, i. e.,
>         z11 z12 z13 z14 ...
>         z21 z22 z23 z24 ...
>         z31 z32 z33 z34 ...
> X- and y-indices of the matrix correspond to column and row index of the

But this is not really correct, as the use of "plot <foo> matrix"
demonstrates.  "Column 3" may or may not be a Z value, depending 
on what kind of graph you are describing. My current best effort
at writing a description is:

  Matrix values are read in a row at a time, i. e.,
          M11 M12 M13 M14 ...   (i=1)
          M21 M22 M23 M24 ...   (i=2)
          M31 M32 M33 M34 ...   (i=3)
          ... ... ... ... Mij

  The interpretation of columns in the "using" specification for
  matrix data is different from the usual case. "$1" refers to the
  matrix row index i, "$2" refers to the matrix column index j,
  and "$3" refers to the matrix entry Mij.

  Example:
    set view map
    splot <foo> matrix using ($1 * 5.):2:(sqrt($3))

  This example will plot the value sqrt(Mij) at the coordinates
  x=5i, y=j for each entry i,j represented in the matrix.

Does this description seem OK to you?  


> ***
>
> Proposal for 'help matrix', please modify:
>
> Datafile can be in an ascii or binary matrix format. The `matrix` flag
> indicates that the file is ascii, the `binary` or `matrix binary` stands
> for a binary format. For details, see `matrix ascii` or `matrix binary`.
>
> Basic usage in `splot`:
>       splot 'a.dat' matrix
>       splot 'a.gpbin' {matrix} binary
> Advanced usage in `splot`:
>       splot 'a.dat' matrix using 1:2:3
>       splot 'a.gpbin' {matrix} binary using 1:2:3
> allows to manipulate the axes coordinates and the z-data.
>
> Usage in `plot`:
>       plot `a.dat` matrix using 1:3
>       plot 'a.gpbin' {matrix} binary using 1:3
> will plot rows of the matrix, while using 2:3 will plot matrix columns,
> and 1:2 point coordinates. Applying the `every` option you can specify
> explicit rows and columns.
>
> Example -- rescale axes for an ascii matrix:
>       splot `a.dat` matrix using (1+$1):(1+$2*10):3
>
> Example -- plot the 3rd row of an ascii matrix:
>       plot 'a.dat' matrix using 1:3 every 1:999:1:2
> (rows are enumerated from 0, thus 2 instead of 3).
>
> ***
>
> Proposal for 'help matrix ascii', please modify:
>
> The `matrix` flag in
>         {s}plot 'a.dat' matrix
> indicates that the ASCII data are stored in matrix format.
>
> The z-values are read in a row at a time, i. e.,
>         z11 z12 z13 z14 ...
>         z21 z22 z23 z24 ...
>         z31 z32 z33 z34 ...
> and so forth.
>
> X- and y-indices of the matrix correspond to column and row index of the
> matrix, starting from 0. You can rescale or transform the axes as usual
> for a data file with three columns (x=$1, y=$2, z=$3), for example
>         splot 'a.dat' matrix using (1+$1/100):(1+$2*10):3
>
> A blank line or comment line ends the matrix, and starts a new
> surface mesh. You can select among the meshes inside a file by the
> `index` option to the `splot` command, as usual.
>
>
> ---
> PM

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