Re: key positioning problem

[<pl...@pi...>]

Ethan A Merritt wrote:
> On Sunday 22 February 2009, Allin Cottrell wrote:
>> Problem: with both the png (libgd) and cairopng terminals,
>> depending on the font selected the gnuplot "key" may overflow the
>> plot data region (even if the key terms are in no way excessive,
>> e.g. n <= 8 characters per term).
> 
> Gnuplot does not do any font handling on its own. It leaves this
> to the individual external devices or libraries.  The corresponding
> drivers are supposed to provide approximate information about the
> average character width in the fields term->h_char, but the 
> approximation can be pretty terrible depending on what font you pick.
> And anyhow, at best it contains the estimated width of an "average"
> character.  In your case the titles are in all caps, and these are
> wider characters than average.
> 
> So if you think that the png terminals *always* underestimate the
> font width, then you could multiply term->h_char by some constant
> everywhere that it is set in the driver.  But I find it more likely
> that some font widths will be underestimated and others will be
> overestimated, and there is not much we can do about it.
> 
> In other words,  I don't think this is fixable. 
> Not for png, and not for any other terminal unless it is using a
> monospaced font and correctly reports the corresponding fixed width.
> 
> This is why there are fudge factors for the key layout, so that you
> can tweak the layout if the automated estimation is failing.
> In the example you give, it is sufficient to reserve a little extra width:
> 
>   set key width 2
> 

Hi,

that gives some kind of manual work around which is helpful but all this
seems rather unsatisfactory in this day and age. Are there really none
of these terminals that can correctly return the space needed to render
a character string? X11 must surely be able to give that. I'd be a
little surprised if cairo can't.

A little googling came up with this which , on the face of it , seems to
be doing just that in order to produce rendered text for http images.

http://www.aeracode.org/2007/12/15/django-and-cairo-rendering-pretty-titles/

surface = cairo.ImageSurface(cairo.FORMAT_ARGB32, 1, 1)
context = cairo.Context(surface)
context.select_font_face(font, style, weight)
context.set_font_size(size)
width, height = context.text_extents(text)[2:4]

While separating out the rendering detail into different terminals has
advantages it should not end up reducing things to a lowest common
denominator. If some terminals can correctly calculate text extents it
would be nice to use that capability.

/Peter.


> 
>> Example:
>> set term pngcairo font "FreeSans,8" size 680,400
>> set output 'test.png'
>> set key left top
>> plot x title "PRIME" w lines , \
>>  2*x title "UNEMP" w lines
>>
>> In the resulting plot, the 'U' of "UNEMP" is vertically bisected
>> by the y axis.  The desired result is that all the key text
>> appears within the data area (i.e. to the right of the y axis);
>> and this is achieved if we change the first line of the plot file
>> to (for example)
>>
>> set term pngcairo font "Vera,8" size 680,400
>>
>> I'd be happy to try to work up a patch for this, but I'm having
>> difficulty figuring out where to start -- i.e., determining where
>> the left limit of the key block is computed, given the selected
>> font.
>>
>> P.S., on further investigation this does not seems to be very
>> terminal-specific: I'm getting the same issue with the pdf,
>> pdfcairo, and 'post eps' terminal types.
>