[roberto]

Hello,

I made a simple plot using the cairolatex terminal and got two different results by using gnuplot under debian and Windows 7.
debian : gnuplot 4.6.4
Windows 7: gnuplot 4.6.3 (gp463-win32-setup.exe)

In the attachment you can see the difference. The more up to date versions gp465-win32-setup.exe and gp50rc1-20140519-win32-mingw.exe.zip yield no better results.

From my point of view the result of gnuplot 4.6.4 under debian looks more aesthetically and provides more space for the plot. I already posted a similar case ( #1089 cairolatex-improper space between axes and labels ). After that the problem was fixed temporary.

Please find a solution to reduce the too large space between axes and tics/labels. Thanks.

Kind regards,

Roberto

In general you'll always need some fine-tuning for the axes and tics labels with epslatex or cairolatex terminals, because the complete rendering of the text is delegated to LaTeX.

That means, that gnuplot cannot estimate the width and position of all labels correctly. Use the offset options to adjust your labels, e.g. with set ylabel offset 1 etc.

"... because the complete rendering of the text is delegated to LaTeX." this is true, but the vertical position of the xtics and xlabel e.g. is defined by gnuplot. As you can see the frame size of the plot is different.

Yes, you are right. Cannot test on Windows, on Linux I get the same results with 4.6.0 to 4.6.5

I cannot explain why the output is different on Windows and linux. But I can maybe help you to understand the spacing.

The .tex output requests a font with size 11pt, and a fallback to size 10pt if this isn't found. I honestly don't know which piece of software is responsible for this, maybe cairo? Anyhow, depending on the requested size of the plot this may be too large or too small compared to the eventual viewing size. In that case you will have to fix it by editing the .tex file to request a different font size.

But gnuplot can't see any of that. All it knows is that for the "default" latex font to look approximately right in the default *.pdf size (5in x 3in) it must be scaled by a factor of 0.6. That's why if you look at the output from "set term cairolatex" you will see:

gnuplot> set term cairolatex pdf
Terminal type set to 'cairolatex'
Options are ' pdf input blacktext nobackground fontscale 0.6 size 5.00in, 3.00in '

Your script asks for a plot with size 16cm x 10cm. That is bigger than the default size, so logically you would need to scale up the font by the same amount to keep the visual balance the same. That is, set fontscale to (0.6 * size-increase) which in your case comes out to about 0.76.

If your personal preference is to have less space reserved for the text, you can "fool" gnuplot by giving it a too-small fontscale.

Thank you for the explanation.
Do you really think that the effective plotting area depends on the available LaTeX font size? Is it not true, that the sole plot can be generated by gnuplot independently of the presence of a LaTeX installation?
I tested your suggestion to set the font size to 9 e.g. but the result is unchanged.

Yes of course gnuplot can (and does) generate the figure independent from the local LaTeX installation. But when it leaves space for the text it obviously has to make some guess as to how big the font will be. If that guess is wrong, then the amount of space that is reserved will also be wrong.

Or look at it from the other side. Gnuplot makes the figure first and then tells LaTeX "here is a nice figure. Please add some text in the space provided". If LaTeX chooses a too-small font then there will be extra space. If LaTeX chooses a too-big font then there will not be enough space.

In the figures you attached, the Windows installation of LaTeX apparently chooses a larger font than the linux installation of LaTeX. That is a difference in LaTeX, not gnuplot.

Actually the font sizes in the two example files should be equal, but are not (10 in debian and 12 in Windows7).
The size of the plotting frame (left y-axis to right y-axis and lower x-axis to upper x-axis) is different indeed, but the size of the characters differs only a little. The ratio of the frames is much bigger than the ratio of the font sizes.

Its quite hard to debug this. Could you please provide the generated .tex and the -inc.pdf files? Also I think it would help if you could do the tests with the very same gnuplot versions. Also please double-check if you have the very same testing script on both platforms (why is the plot of the Windows image black and the Debian one red?)

I tested the script with gnuplot 4.6.5 on Windows as well as on debian. There is still a difference between both platforms, but it is much smaller than in my previous example. But still the result of gnuplot on debian looks more aesthetic.

I do not think this difference can be due to gnuplot per se. You are running the same script through the same version of gnuplot, yet you get different coordinates output to the *.tex file. The only way I can see for this to happen is if the call to pango_layout_get_extents() returns different values on the two systems.

One possibility is that the pango library version on your Windows system is different than the one on your linux system. Or perhaps it is the same version but using different fonts.

Either way I think you have to treat this as a font-scaling problem, and try to compensate using the fontscale parameter in "set term".

I could not reproduce large scacing on gnuplot 4.6.7, 5.0.3 and 5.1.0 (2016-05-19) on windows and MiKTeX 2.9.5840.