On 10/12/12 10:03, Daniel J Sebald wrote:
> On 10/12/2012 01:08 AM, plotter@... 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'
>>>>>> 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
>>>> 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
>> 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
>> 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.
What you are suggesting would mean a active, self-modifying document.
That is probably possible with SVG though I doubt whether it could be
applied to PS.
I would imagine that kind of solution opening up a lot of possibilities
for bugs , though in some ways seeing what you get given at render time
is the only definitive way to get the text size spot on.
As I recall previous comments for Ethan on this problem have stated that
absence of any call back mechanism in certain terminals is why gnuplot
does not use this strategy in any terminal.
Maybe those than can, should when that can be determined at plotting time.
Even aside from the render time problems I find significant differences
between live output in wxt and rendering to png , for example.
Sometimes I end up doing a screenshot of the wxt rendition and saving it
as png :(
I think some worthwhile improvements could be made without going to the
lengths involved in documents self-modifying at display time.