Re: key text placement in SVG

[Daniel J S. <dan...@ie...>]

On 10/12/2012 01:08 AM, pl...@pi... wrote:
> On 10/12/12 01:43, Allin Cottrell wrote:
>> On Thu, 11 Oct 2012, Ethan A Merritt wrote:
>>
>>> On Thursday, October 11, 2012 04:13:55 pm Ethan A Merritt wrote:
>>>> On Thursday, October 11, 2012 12:42:22 pm Allin Cottrell wrote:
>>>>> I'm comparing the output of gnuplot's svg and pngcairo
>>>>> drivers, with a thought of making greater use of SVG. But
>>>>> there seems to be a slight problem with the placement of key
>>>>> text in the SVG output. Here's a little test script
>>>>>
>>>>> set term svg font "Sans,8" size 680,400
>>>>> set output 'test.svg'
>>>>> set key left top
>>>>> plot sin(x) title "PRIME" w l, \
>>>>>     cos(x) title "UNEMP" w l
>>>>> set term pngcairo font "Sans,8" size 680,400
>>>>> set output 'test.png'
>>>>> replot
>>>>>
>>>>> In the PNG version the key is just fine, but in SVG the "U" of
>>>>> "UNEMP" gets tangled up with the y-axis (more or less,
>>>>> depending on the magnification).
>>>>
>>>> The underlying issue is that for SVG, like PostScript, gnuplot has
>>>> to guess at the font properties for a font that will not actually
>>>> be selected until the file is later viewed in another program.
>>>
>>> By the way, if you turn on the "box" attribute of the key you can
>>> see that the key box itself is properly placed.  The problem is that in
>>> your case the width of the box is too small because the size of the text
>>> was underestimated.
>>>
>>> As a work-around, you could use "set key left Left".
>>> That anchors the left end of the text rather than the right end,
>>> so it is not at risk of overwriting the left plot border.
>>> Instead the right end of the text might run into the line sample ;-)
>>
>> Ah, that's a nice suggestion. I can manipulate the key placement so
>> as to try to avoid colliding with the plot lines, just so long as
>> I'm reasonably confident it won't collide with the axes.
>>
>> But on the more general point, does this mean I might have better
>> luck if a specified the font more precisely than just "Sans"?
>>
>> Allin Cottrell
>>
>
> Yes, I have taken to specifying the font size and name explicitly and
> using spaces to avoid this kind of over-run as Daniel suggested.
>
> It really would be good if some improvement could be made in this area.
> With longer key titles, the errors can be substantial.
>
> It is a bit of a guessing game but it seems that the guesses are
> always(?) rather poor.

It's awful.  Working with fonts has historically been a headache.  Save 
tweaking font position for the last touch up on graphs.


> Counting capitals would be a good first step. Since this is a once per
> plot overhead, some detailed accounting would not have any noticeable
> performance hit.

Counting capitals goes along the lines one doesn't want to go.  The 
proper way of doing this is either to have scalable fonts, or for the 
library to have a convenient function by which the programmer can 
provide the font type/size and an ASCII string of the text to be placed 
and the routine returns the size when rendered.  Font substitution is a 
get-what-you-get sort of thing.


> Clearly text content can not be counted on to average out on such short
> samples, 'emmission spectrum" with not have the same average letter
> width as " illiterate infallibility"
>
> Perhaps some quantitative study of real examples of which fonts render
> poorly on which renderers would permit better guesses to be build into
> gnuplot.
>
> Clearly there are thousands of fonts but maybe certain families are
> consistently wider / narrower so more knowledge would help improve
> built-in guesses and also help users avoid fonts that can't be estimated
> reliably.
>
> There may well be some platform dependency in all this as well. That
> would be harder to fix but probably needs assessing.  Are fonts
> consistently rendering different widths on linux / Mac / Win. ?

That should be factored into the routine that indicates rendered widths, 
if one existed.

Dan