Menu
▾
▴
gnuplot-info
|
From: Daniel B. <dbo...@gm...> - 2018-02-07 17:20:41
|
Hi, Take the following script, minimally modified from https://stackoverflow.com/a/30832843 set terminal svg background rgb 'black' > set output 'bw.svg' > > set xlabel 'ylabel' tc rgb 'white' > set ylabel 'xlabel' tc rgb 'white' > set border lc rgb 'white' > set key tc rgb 'white' > > set linetype 1 lc rgb 'white' > plot x lc 1, x**2 lc 1 > It renders an SVG with a black background and white everything else. Now add "mousing" to the "set terminal" line. That results in the background being lost, so everything is white on white, and thus invisible. It looks like the code that creates the mousing bounding box unconditionally sets a white rectangle with a black stroke, thus overridding or hiding the background the user wants. Is this bugworthy, or is there a reason that it has to be this way? I would really like to be able to render white (and other colours) on black, as I prefer "inverted" colours - but I also want to be able to use mousing in my reports. At present, it doesn't look like I can have both. Hopefully that's solvable. Thanks, Daniel |
|
From: Daniel B. <dbo...@gm...> - 2018-02-07 17:26:41
|
Another apparent bug is that, this time in both SVG and PNGcairo (and probably others), the key "title" does not obey the "textcolor" set in the key command (regardless of whether it comes before or after the "title" clause) Therefore adding a title to the above sample results in it always being rendered in black, and thereby not visible when the black background is working properly. |
|
From: Ethan A M. <eam...@gm...> - 2018-02-07 18:03:15
|
On Wednesday, 07 February 2018 17:26:33 Daniel Boles wrote:
> Another apparent bug is that, this time in both SVG and PNGcairo (and
> probably others), the key "title" does not obey the "textcolor" set in the
> key command (regardless of whether it comes before or after the "title"
> clause)
Please always show what version of gnuplot you are using and
provide an example of the command that fails.
I do not see this problem in current gnuplot (5.2.2).
I would not expect this sort of problem to depend on the terminal
type, but I confirmed that the following commands produce correct
key title color for qt, svg, and pngcairo.
set key title "TITLE" tc "blue"
plot for [i=1:5] i*x
> Therefore adding a title to the above sample results in it always being
> rendered in black, and thereby not visible when the black background is
> working properly.
If there is some separate interaction of the key title with
the background and mousing commands, you'll have to show a
particular command sequence that reproduces it. I don't see
any problem here even after setting the background to black.
cheers,
Ethan
|
|
From: Ethan A M. <eam...@gm...> - 2018-02-07 18:17:44
|
On Wednesday, 07 February 2018 17:20:31 Daniel Boles wrote: > Hi, > > Take the following script, minimally modified from > https://stackoverflow.com/a/30832843 > > set terminal svg background rgb 'black' > > set output 'bw.svg' > > > > set xlabel 'ylabel' tc rgb 'white' > > set ylabel 'xlabel' tc rgb 'white' > > set border lc rgb 'white' > > set key tc rgb 'white' > > > > set linetype 1 lc rgb 'white' > > plot x lc 1, x**2 lc 1 > > > > It renders an SVG with a black background and white everything else. > > Now add "mousing" to the "set terminal" line. > > That results in the background being lost, so everything is white on white, > and thus invisible. Yes. That seems to be a bug. > It looks like the code that creates the mousing bounding box > unconditionally sets a white rectangle with a black stroke, thus > overridding or hiding the background the user wants. Other way around I think. If you set a background color then normally the plot output begins with a filled rectangle of that color. However if you select "standalone mousing" the program starts the output with a copy of the mousing code and omits the filled background rectangle. > Is this bugworthy, or is there a reason that it has to be this way? According to the code, it was intentional. But quick testing does not show any obvious problem so I am not sure why that was. I will investigate further. > I would really like to be able to render white (and other colours) on > black, as I prefer "inverted" colours - but I also want to be able to use > mousing in my reports. At present, it doesn't look like I can have both. Sure you can. No problem. You can always include a filled background rectangle as a separate command. This should work independent of anything else: set obj 1 rectangle from screen 0,0 to screen 1,1 behind set obj 1 fillstyle solid fillcolor "black" cheers, Ethan > > Thanks, > Daniel |
|
From: Daniel B. <dbo...@gm...> - 2018-02-07 18:35:16
|
On 7 February 2018 at 18:17, Ethan A Merritt <eam...@gm...> wrote: > > Now add "mousing" to the "set terminal" line. > > > > That results in the background being lost, so everything is white on > white, > > and thus invisible. > > Yes. That seems to be a bug. > > > It looks like the code that creates the mousing bounding box > > unconditionally sets a white rectangle with a black stroke, thus > > overridding or hiding the background the user wants. > > Other way around I think. If you set a background color then > normally the plot output begins with a filled rectangle of that color. > However if you select "standalone mousing" the program starts the > output with a copy of the mousing code and omits the filled background > rectangle. > > > Is this bugworthy, or is there a reason that it has to be this way? > > According to the code, it was intentional. But quick testing does > not show any obvious problem so I am not sure why that was. > I will investigate further. > Thanks for that! > I would really like to be able to render white (and other colours) on > > black, as I prefer "inverted" colours - but I also want to be able to use > > mousing in my reports. At present, it doesn't look like I can have both. > > Sure you can. No problem. > You can always include a filled background rectangle as a separate > command. This should work independent of anything else: > > set obj 1 rectangle from screen 0,0 to screen 1,1 behind > set obj 1 fillstyle solid fillcolor "black" > Ta again - I found others suggesting this method shortly after posting. It'll probably be fine for now, at least since you revealed the secrets of the key title textcolor(s). :D |
|
From: Daniel B. <dbo...@gm...> - 2018-02-07 18:33:44
|
Thanks for the replies. On 7 February 2018 at 18:03, Ethan A Merritt <eam...@gm...> wrote: > On Wednesday, 07 February 2018 17:26:33 Daniel Boles wrote: > > Another apparent bug is that, this time in both SVG and PNGcairo (and > > probably others), the key "title" does not obey the "textcolor" set in > the > > key command (regardless of whether it comes before or after the "title" > > clause) > > Please always show what version of gnuplot you are using and > provide an example of the command that fails. > > I do not see this problem in current gnuplot (5.2.2). > I would not expect this sort of problem to depend on the terminal > type, but I confirmed that the following commands produce correct > key title color for qt, svg, and pngcairo. > > set key title "TITLE" tc "blue" > plot for [i=1:5] i*x > Yeah, 5.2 patch 2. I must not have properly tested all combinations... or realised that I need 2 textcolor clauses. It looks like (A) the textcolor after the title determines its color and (B) another textcolor anywhere else determines the color of the individual series titles. I guess this is intended and I just didn't read the docs properly? |
|
From: Daniel B. <dbo...@gm...> - 2018-02-07 18:36:03
|
On 7 February 2018 at 18:33, Daniel Boles <dbo...@gm...> wrote: > It looks like (A) the textcolor after the title determines its color and > (B) another textcolor anywhere else determines the color of the individual > series titles. > That is to say, something like this: set key title "TITLE" textcolor rgb "blue" textcolor rgb "red" > |
|
From: Daniel B. <dbo...@gm...> - 2018-02-08 00:23:31
|
Hi, One last hijack of this thread... while we're on the subject of SVG and colours: Is there any way to change the colour of the coordinate label that follows the mouse pointer in SVGs, from its default black to something visible on the new black background? I'm having no luck finding an option in the docs, or googling generally, and I don't understand the JS well enough to conclude either way. Thanks, Daniel |
|
From: Ethan A M. <eam...@gm...> - 2018-02-08 06:27:33
|
On Thursday, 08 February 2018 00:23:23 Daniel Boles wrote: > Hi, > > One last hijack of this thread... while we're on the subject of SVG and > colours: Is there any way to change the colour of the coordinate label that > follows the mouse pointer in SVGs, from its default black to something > visible on the new black background? I'm having no luck finding an option > in the docs, or googling generally, and I don't understand the JS well > enough to conclude either way. Find these lines in the javascript <text id="coord_text" text-anchor="start" pointer-events="none" font-size="12" font-family="Arial" visibility="hidden"> </text> and add fill="white" after the font-family There is currently no program option to do this automatically. Ethan |
|
From: Daniel B. <dbo...@gm...> - 2018-02-10 19:49:58
|
Hi Ethan, Just to say thanks for the quick fix on the background colour. Look like it was just a mixup between > and >=, then! Anyone who's ever programmed can sympathise with that, I think. :) Thanks, Daniel |
