When I use the "replot" command, my (blue) area chart is twice as dark. Also, the (blue) line on top of it is twice as heavy. This means the original plot wasn't removed before replotting.
This wasn't happening with v5.4.10.
Let me know if you need further explanation.
At the very least we need to know what terminal type you are using. Are these figures the direct output from either the png or pngcairo terminals? Are they screen captures from an interactive terminal?
One thought: If this is a multiplot, then you should take into account that gnuplot version 6 is the first version that can actually do a "replot" for a multiplot. All previous versions could only replot the most recent component of the multiplot. Even so, the existing screen or output device should be cleared first. At least that was the intent.
Thanks for your reply.
I have attached the plot and data files I'm using. Much of it is probably irrelevant; sorry for the fact it's so complicated.
As you can see, I'm using the 'png' terminal. The images I supplied were the direct output from said terminal.
Ah. I see. That's because the replot was inside the multiplot. Since the whole point of a multiplot is to allow more than one plot to be drawn on the same page/screen/canvas of course it cannot clear that canvas between plots. So
replotredraws exactly the same plot on top of the one that was already there. The result is darker because you have drawn two semi-transparent surfaces one on top of the other. The exact result of superimposing two transparent areas can vary depending on what graphics library is used, so you might see different degrees of darkening depending on what your output terminal is set to. If you really don't want that effect, you could in this particular case add aclearcommand before thereplot. Normally one doesn't want to do that inside a multiplot because it would erase the parts you have already drawn.Thanks very much for the detailed reply.
I just added 'clear' before 'replot', but unfortunately the problem still occurs. Where to from here?
You've closed the ticket, but the solution didn't work. I don't think the 'clear' command has been implemented on the 'png' terminal.
Can we go back to the very beginning? What exactly is "the problem" that you are facing? I thought, based on the pair of tracker issues #2688 and #2689, that the issue was an object with attribute 'back' showing through a transparent surface. But "clear" has nothing to do with that.
For what it's worth, the documentation for the
clearcommand says:One more thought - I may not fully understand what your script needs to deal with, but it looks to me that no
replotis needed. Omitting replot may bypass all of the concerns other than whether or not make the filled area transparent or opaque. You can rewrite these three commands:with the following two commands (no replot):
Thanks very much for getting back to me (with another detailed reply). I will try to answer your questions/suggestions as best I can.
Unfortunately, using the two commands you have supplied (in that order and with no 'replot') causes other problems. As you can see in the attached image, the horizontal yellow line is now in the wrong place vertically. It is supposed to reflect the current price. Also, the bottom (volume) part of the chart is now missing.
So, going back to the 'clear' (and 'replot') method: I'm noticing that the output file size is a lot larger when using v6.0.0 (than v5.4.10) on the 'png' terminal. However, when I switch to 'pngcairo', they are identical. This is what leads me to believe that the 'clear' command hasn't been (properly) implemented on the 'png' terminal.
The yellow line appearing on top of the blue area chart was a separate issue. There's no need to worry about it here. That problem was correctly solved (by you) in the other ticket. Thank-you very much again for that!
Now that the transparency issue has been overcome, there's the matter of the blue line (on top of the blue area chart) being twice as heavy as it should be. It, along with the file-sizes matter I've mentioned above, tells me that the 'clear' command (on the 'png' terminal) isn't removing the original items before replotting them.
For the record, I think gnuplot is a wonderful program. I use it every single day of my life. With these tickets, I hope it doesn't sound like I'm being critical of it.
Actually, I don't think the 'clear' command is the problem. Below are the output file sizes for each case (without the 'clear' command).
The 'png' terminal:
The 'pngcairo' terminal:
As you can see, the 'pngcairo' terminal is behaving correctly. It is removing the original plot before replotting. This is not the case in v6 with the 'png' terminal.
I think someone has added code to the 'png' terminal for v6.0.0 that's causing this problem. Maybe it occurred in one of the commits you haven't seen.
No replot - Sorry, my mistake. I forgot that selecting the "graph" coordinate system for the x coordinate would also affect the y coordinate. See
help coordinatesfor a full explanation of using alternative coordinate systems to specify a position. The correct command is:File size - The gdlib-based png terminal can generate images using either indexed color (1 byte per pixel) or truecolor (4 bytes per pixel Red+Green+Blue+Alpha). Gnuplot version 5.4 defaulted to indexed color; version 6.0 defaults to truecolor. Using 4 bytes per pixel rather than 1 byte of course makes for a larger file size. Indexed color was the original use-png-instead-of-proprietary-gif format from the 1990s. It is limited to 255 colors and no partial transparency. It is still supported but not used much any more.
Use of 'clear' - The
clearcommand is supported by both png terminals. You can use the script below to see how it works in a multiplot.Thickness of blue line I am not noticing anything unusual about the thickness of this line. But if you want you can set a different linewidth.
Thanks very much for another detailed reply.
Re "No replot": Thanks, that prevents the need to replot. I will use it from now on (if only to speed things up on my 10-year-old computer).
Re "File size": Ok, understood. That makes sense. If I want to go back to using indexed color, what's the command? A quick Google search didn't yield the answer.
Re "Use of 'clear'": Thanks for that demo. I tested it with both the 'png' and 'pngcairo' terminals. It looked good in both cases.
Re "Thickness of blue line": I've taken a closer look, and I think the v6 'png' terminal is smoothing the line rather than making it thicker. That's probably a good thing.
Also, I brought back 'transparent' (just momentarily) for argument's sake. The colour of the area chart is still much darker in v6, despite the fact that we're not replotting anymore. Is that because of the switch to truecolor?
Also, considering how much I use gnuplot, I thought I should probably donate some money. Unfortunately, there doesn't seem to be a 'donate' link on your website. Do you guys accept donations?
To request use of indexed color:
set term png notruecolorhttp://gnuplot.info/docs_6.0/loc21492.html
Ok, that did the trick. The file-size is now back down to 27.2 KiB (in v6.0.0). As a minimalist, I'm much appreciative. Thanks for all of your help across both tickets.
Always happy to accept donations of time, code, or expertise. Or inspiration - getting pointers to examples of plot styles used by people in an unfamiliar disciplines can lead to ideas for things that gnuplot could do better or more easily in a future version.
I used to code professionally in C (more than 15 years ago). I don't think I'd be at the gnuplot level anyway. You guys are pretty switched on.
If your goal is to get the same output as
v5.4.10.pngusing gnuplot 6.0.0, it might work by replacingwith
This would mean excluding transparency from the fill attribute for the filledcurves style. You will probably get similar results on both png and pngcairo terminals.
If a transparent
v6.0.0.pngis preferable, and simply overlaying by replot is a problem, then it is better to adopt the suggestion by Ethan not to use GPVAL_X_MIN or GPVAL_X_MAX inset arrowand omitreplot.Thanks for your input as well, Hiroki -- also in the other ticket. Both your and Ethan's explanations make a lot of sense.