#1928 ytic sometimes shown without label in pdfcairo

[NicoK]

I'm having trouble with gnuplot 5.0.6 (openSUSE Tumbleweed, x86_64) sometimes not showing a ytic label in pdfcairo although the ticmark is printed. The (minimal) example creates a pdf file where the given ytic at 0.01811 has no label.
Working around this by e.g. using sprintf or giving the number manually does not work. I included some more working and non-working examples.

set terminal pdfcairo

set grid layerdefault

set output 'test.pdf'

set format x ""
set format y "%1.5f"
set yrange [0:0.05]

# does not work:
set ytics (0.01811)
# set ytics ("0.01811" 0.01811)
# set ytics ("t0.01811s" 0.01811)
# set ytics (0.01811, 0.02)

# works:
# set ytics (0.0181)
# set ytics ("s" 0.01811)
# set ytics (0.01811, 0.01)
# set ytics (0.0182)
# set ytics (0.0299022968168612, 0.0417547225952148, 0.01811, 0.01)

plot x

[Ethan Merritt]

I cannot reproduce this problem using any of versions 5.0.0, 5.0.1, 5.0.6, or current cvs.

Does it make any difference if you make the left margin larger? E.g. "set lmargin at 0.25"

[NicoK]

I can even reproduce it with 5.2-rc1 :( - this is using cairo 1.15.4 (will try 1.15.6 tomorrow).

I even have some more font-related bugs but let me show you this one first in the attached example output files generated from the posted script

[NicoK]

unfortunately, cairo 1.15.6 did not improve anything :(

[NicoK]

getting there...
using set lmargin at screen 0.5 for the set ytics (0.01811, 0.02) command yields to the attached result with one label being correctly aligned and the other too far away from the plot's border

[NicoK]

FYI: using another terminal, e.g. set terminal png, does not result in this behaviour

[Ethan Merritt]

All I can do is scratch my head.
I still don't see anything like that here (lib64cairo2-1.14.0).

• Have you tried different fonts?

• You say "set term png" is OK. I assume that's the libgd png terminal. What about other cairo-based terminals? Try "set term pngcairo" or "set term wxt". If the display in the wxt terminal is correct, you could go one step further and test whether the "export to pdf" button on the display window matches the (good) wxt version or the (bad) pdf version.

[NicoK]

• pngcairo works just fine
• wxtalso works fine in the window
• wxt export to png or svg looks good
• wxt export to pdf shows the same behaviour than pdfcairo except for the actual distance of the label from the plot (see the attached test-with-lmargin-from-wxt.pdffile)
• now here's another strange thing: the first export to pdf from wxt shows bad version and results in a 7.7KB file, if I hit export to pdf a second time, the resulting file will be 8.2KB and looks just fine - following up on this, by adding this technique to the original code, it also works, i.e. having the script end with:

plot x
set output 'test.pdf'
plot x

---

On a second set of experiments with different fonts: I do have msttfonts installed and with that:

• the default, i.e. Sans family (according to the docs), chooses arial.ttf and shows the bad version
• choosing font "Liberation Sans,12" instead works fine
• similarly for font "Serif" vs. font "Liberation Sans"

---

To sum up: there seems to be some bug with the MS true type fonts which only seem to work correctly on the second plot. Now this, or setting another font specifically, are both only (ugly) workarounds.