#2687 Incorrect box width for key/legend

[Anonymous]

When setting the key/legend outside the graph, I would expect that the box will take the minimal width required to hold the text, and the graph width is reduced accordingly.
This is not the case for proportional fonts. However, it seems to be ok for monospace fonts.

Apparently, when placing boxed labels, gnuplot knows how to calculate the correct width. But maybe this is a different process "internally".

Check the following example:
This shows the same behavior for probably all gnuplot versions. Tested only until 5.5.0 under Windows.

reset session
text1 = "mmmmmmmmmmmmmmm"   # 15x m
text2 = "iiiiiiiiiiiiiii"   # 15x i

set style textbox border
set label 1 text1            at graph 0.3, 0.9 boxed
set label 2 text2            at graph 0.3, 0.8 boxed
set label 3 text1."\n".text2 at graph 0.3, 0.7 boxed
set key out top box

plot x**2 ti text1, \
     x**2 ti text2

[Ethan Merritt]

gnuplot does not know anything about fonts other than their nominal size. And font sizes are pretty nominal! It is the price one pays for trying to be device-independent.

The details are entirely up to the output device. Consider, for example, that you can request any font by name in the PostScript terminals and that request will be passed through in the output *.ps or *.eps file. Only at the time the file is printed will your printer, or printer driver software, try to look up a font by that name or try to select at an acceptable equivalent. Gnuplot is long since out of the picture by that point.

So yeah, gnuplot has no way of knowing what eventual size a label in a proportional font will take up.

[theozh]

Thank you, Ethan, for that background information.
Sorry, I was not logged in that's why this appeared under "anonymous".

The example above was with wxt terminal and I would be interested in a correct width for wxt, qt, png, gif, pdf terminals, but probably it's similar there. I don't care about .ps or .eps.

So, as I understand, generally, this can't be done.

For curiosity and better understanding, in the example of wxt terminal:
1. how is gnuplot making its guess about the width of the key box? Does it just assumes a certain number of pixels depending on number of characters and fontsize? And if you're lucky, it fits?
2. why seems this guess to be perfect in the case of the labels?

So, then what would be a "solution" for this issue? According to help key:
set key width <increment>
Try manually adjusting different increments until you find the "correct" width?

[Ethan Merritt]

Each gnuplot "terminal type" has to accommodate the capabilities of some physical device or some graphics support library. Some of these are more flexible than others when it comes to fonts. Back in the last century, when gnuplot was written, most printers and terminals offered a single font or at best a small number of fixed-width fonts. In the modern era most devices make a much larger variety of fonts available, but in general gnuplot has no way of querying those devices to ask what they have done to format a particular text string. The more sophisticated the text processing done by the output device, the less chance gnuplot has of guessing in advance how it's going to come out. The extreme case is probably TeX/LaTeX output. A very long string of characters passed to a TeX output terminal may describe a very compact mathematical formula. How should gnuplot know how much space to reserve for it?

It isn't completely hopeless. Some output devices, and some graphics support libraries, accept a command that essentially means "put a box around the next string of text". Gnuplot can use that command to request a correctly sized box around a text label, but only if the output device provides such a command.

A smaller number of devices or graphics libraries provide commands that essentially mean "put a box around everything I tell you to draw starting now and ending when I say 'stop'". That allows the box around a multi-line gnuplot label to come out more or less OK on those particular terminals but most terminals to a poor job of it.

Even that multi-line support doesn't help for the key box, however, because the key is built up in pieces as the plots making up the full graph are individually drawn. There is no single set of sequential drawing commands that gnuplot can wrap in a "box start ... box stop" request. In principle for some terminals (latex/tikz, qt, gdlib, but not I think for cairo/wxt) you could imagine accumulating a separate output stream of commands relevant to the key and then drawing it all at once after the rest of the plot. That would for those terminals result in a box that was correctly clipped to the key content. But even so gnuplot would not know in advance how big that box was going to be, so it could not reserve the correct amount of space for it when laying out the graph.

TL;DNR: The best you can do inside gnuplot to adjust the key box size is to play with the height and width options for set key. Or you can post-process the output file using a tool that matches the output type and add the box to the completed graph. That tool might be Acrobat or Inkscape for vector formats, Gimp or ImageMagick for bitmap formats.