#2161 There isn't a factor that correlates the dashes length to an actual length on the plot

[Anonymous]

I'm using gnuplot version 5.2 over linux

There's a discussion over stackoverflow https://stackoverflow.com/questions/55625024/how-to-make-dashed-grid-lines-intersect-making-crosshairs-in-gnuplot

The code itself

reset session

set multiplot
set ticscale 0,0

Units = 24   # pattern (5,5,4,5,5,0) are 24 units
Factor = 11.

# set interval and repetition parameters
IntervalsY = 10
RepetitionsY = 1
IntervalsX = 4
RepetitionsX = 3

# initial plot to get graph size and base dash length for x and y
plot x**2
gX = real(GPVAL_TERM_YMAX-GPVAL_TERM_YMIN)/IntervalsY/Units/Factor/RepetitionsY
gY = real(GPVAL_TERM_XMAX-GPVAL_TERM_XMIN)/IntervalsX/Units/Factor/RepetitionsX

# first plot with x-grid lines
set grid xtics lt 1 lc rgb "black" dt (gX*5,gX*5,gX*4,gX*5,gX*5,0)
replot
unset grid

# second plot with y-grid lines
set grid ytics lt 1 lc rgb "black" dt (gY*5,gY*5,gY*4,gY*5,gY*5,0)
replot

Works on wxt. But doesn't work on other terminals like qt or pngcairo, even changing the Units variable. There's no way to predict how the solid lengths and empty spaces will appear on the plot on those terminals.

Using the qt terminal there's also a persisting QPen warning that can't be disabled (revealing a bug?):
QPen::setDashPattern: Pattern not of even length

The point is that one would expect s and e dt (s, e) to have some implicit units. This isn't the case except for wxt.

As an enhancement proposal there should be a variable that makes the effect of s and e predictable. Plotting and checking several times breaks automation.

And I get that the terminals don't need to produce the exact same plot. But this difference is no minor one. More so because that grid style can't be accomplished because of this (and in other platforms this is already contemplated, so it isn't unreasonable).

[Ethan Merritt]

Just a note: dash length scales with linewidth, not size of plot.

[Ethan Merritt]

Thoughts:

• Most terminals support a "dl <multiplier" option that adjusts the length of dot/dash patterns.
• The length is further multiplied by line width.
• The idea of changing the meaning of a dot/dash pattern when the size of the plot changes seems very odd to me. Every little change to plot layout, titles, tic labels, aspect ratio, etc would change the appearance of the lines.
• In my view the purpose of the dot/dash support is to create linetypes that are easily distinguished from each other. It was never intended to position a specific dash in a specific place, which is what you are asking from it.

Maybe a better approach to creating the sort of grid you want is to think of it as a regular array of crosses rather than as a set of intersecting parallel lines. I imagine you could construct such a grid using the cross shape of pointtype 1 adjusted by pointsize and linewidth to suit. How about this:

cross = 101

do for [ix=1:9] for [iy=1:9] {
    set label cross "" at ix*0.1, iy*0.1 point pt 1 ps 5 lw 0.5 lc 'grey50'
    set label cross "" back
    cross = cross+1
}

set xrange [0:1]
set yrange [0:1]
set tics 0.1
set key opaque box left reverse
set sample 1000

plot abs(sin(10.*x**2)) lw 3

If this is a popular style maybe a new variant of "set grid" that sets it up for you?

[Karl Ratzsch]

I like the idea of preset styles for set grid, e.g. crosshair, invcrosshair, doublecrosshair (smaller cross at intersection of tics and mtics lines). Or, more versatile, a keyword for each x/y(m)tic grid line that says to break the line inbetween + optional to invert that pattern