Improving text positioning

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

from "Re: Suggestions for 5.0: Margin (and Key)"

On 06/19/14 00:53, Ethan A Merritt wrote:
> I think you are correct that it could only be done by adding a
> new parameter equivalent to "offset".   The default positioning
> uses an empirical try/oops/try-again approach that is basically
> impossible to document usefully.   Note that the empirical positioning
> can easily come out differently on different terminals, so even if
> we were to add a tweak parameter you'd have to tweak all over
> again if you changed the output device.
>
> 	Ethan


This is the perennial problem of text size and placement coming up again 
and I think it is one of the major flaws in this otherwise excellent 
software.

I know this fundamentally comes from the way gnuplot architecture was 
designed with a plotting core and independent rendering "terminals"

Terminal communication is a one way process and there is currently no 
way for the text rendering facilities available to each terminal to be 
know by the plotting core in order to correctly place text elements. 
This forces some rather crude guessing and often excessive padding to 
avoid text over running axes etc.

This is clearly sub-optimal.

Now I know there are a lot of different contexts to be handled, like a 
postscript file does not even know the  available fonts until it is 
rendered on a particular machine. However, some terminals could do this 
a lot better and it seems everything is being dragged down to a lowest 
common denominator in the present situation.

Here are some suggestions of possible ways to improve things.

  Add some kind of two way communication to terminals like png so that 
precise text extent can be known. Prior to plotting, the plotting core 
sends an extent enquiry with a text sample and the terminal returns text 
extent values that the plotting core can use to precisely place text 
elements.  Then by the time it sends the plot to be rendered it will be 
optimally placed.

For terminals that are too dumb to do this or that themselves do not 
render immediately, so do not have the font metrics available to provide 
a text extent, the fall-back would be the same as it currently is.

Most of the live terminals x11, wxt, qt should be able to provide text 
extent data and that would at least mean working live would give nice 
clean text placements without all the large gaps that are currently 
produced, especially with longer text elements.

A switch could be provided to force the fall-back case for instances 
where a live terminal is being used to prototype output for PS or whatever.


I may be missing something, but I don't see why many of the most common 
and sophisticated terminals could not be made to handle this a lot more 
accurately than is presently the case.

Regards, Peter.