Re: [Gnuplot-bugs] small defects in 4.2

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

On Mon, 30 Apr 2007 23:36:31 +0200, Hans-Bernhard Bröker  
<HBB...@t-...> wrote:

> pl...@pi... wrote:
>
>> 1.
>> resizing the wx window the graph scales well but so does the text. Once
>> the drag is finished it remains too large until a replot is done.
>
> Done on purpose by the implementors of the wx driver.
>
>> 2.
>> Dragging the window by any size handle or corner does resize the graph  
>> but
>> it remains at the same aspect ratio. Again hitting the replot button (or
>> reloading the .gnu) will resize to fit the new window fully.
>
> Ditto.
>
Fine , I guess there must be some reason for doing it that way then  
although it makes resizing the plot an iterative process which seems a bit  
untidy.

>> 3. colours do not come out the same in outputting to png , for example.
>
> The same ... as what?
>

Er , same as wx terminal.

>> It's rather confusing seeing different output stored as an image and
>> annoying in transmitting to others since I cant say "look at the green
>> line" because it's probably blue in the other output format.
>
> You _could_ look at the actual file you're sending them, though ;->
>

Yes , clearly it _can_ , but pulling up another app. to see how it  
rendered that colours differently from the gnuplot terminal I work in is a  
drag.

Also , I sent a plot to a college as svg , which is great for this sort of  
thing but it repeated some colours making the graph a lot less clear. I  
dont see any technical reason why svg should be limitted to fewer colours  
so this would seem to be defect.

> There's a price to be paid for having a tool that just works, without
> you having to rewrite the entire script, for so many different output
> formats.  One part of that price is that while gnuplot will try to do
> something useful for a given script regardless of the terminal driver
> it's run over, it can't be guaranteed that it'll do the _same_ for all
> of them.
>

Not a big issue but one thing that could improve gnuplot should an  
occasion arise to fix it. There seems no intrinsic reason why wx, png and  
svg should assign different colours.


>> 4. I had a lot of time wasted trying to get y2 scale markings. I found  
>> the
>> label readily enough but could not understand why I was not getting the
>> tics and numerical markings. I now realise it required that I explicitly
>> set y2tics . What confused me is that this is not the case with y1 they
>> just come up automatically.
>
> That's because every graph has *some* data on the y1 axis, while most
> graphs neither neither nor want a y2 axis.

Which is *exactly* why I suggested it was only done once a y2scale was  
defined. At this point mirroring y1tics becomes wrong and the lack of y2  
numbering is inappropriate to the newly displayed label.

> There's also historic
> precedent to be maintained.  y2 axes were added to gnuplot a long time
> after the default behaviour of y1 axes was defined to have the tics
> mirrored to where the y2 axis would go.  This default behaviour would
> get in the way of y2 tics.
>
Ditto.

>> It would seem more logical and consistant if y2tics behaved in the same
>> way as the main y-axis, ie as soon as there is a y2scale defined the
>> default tics and numerical label come up as well.
>
> That's not actually how the y1 axis behaves, so why should y2?  The
> trick being that "there is a y1scale defined" is a non-event.  It's
> always defined.
>

Sorry. Maybe I explained this badly.

I curreny have a graph with y1 and y2 .

set xdata time
set timefmt "%H:%M"

set format x "%02H:%02M"
set xr ["11:30":"18:30"]

set title "150 litre tank forced flow test 12 - PC cover"
set yrange [-5:85]
set y2range [-50:850]
set y2tics 0,100,800
set xlabel "time CES: sol +2h"
set ylabel "temp / C"
set y2label "power / W"


I do not define ytics yet I get the numbers , if I do not define y2tics  
explicitly as done here , I don't get any numbers on y2, I just get the  
y2label. There is inconsistancy between the two which is confusing when  
learning to use gnuplot.

The difference in behaviour , if there is a reason to retain it which I  
dont see, probably ought to be documented.

Thanks for you reply. I hope my comments are useful in improving this very  
useful tool.

Kind regards.