Re: key positioning problem

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

Ethan A Merritt wrote:
> On Monday 23 February 2009, pl...@pi... wrote:
>> Ethan A Merritt wrote:
>>> 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.
>> 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.
> 
> Sure. You could write a cairo-based graphics program, or a libgd-based
> graphics program, that queried the libraries for exact character widths.
> But gnuplot is not such a program.  The core gnuplot code is separate
> from, and independent of, individual terminal drivers.

So the code snippet I posted could go in the cairopng terminal , others
would have simliar code where it can be supported.

> 
>> 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.
> 
> So far as I can see, that would require major restructing of the program.
> If you want to work on it, I suggest that the first step is to block out
> what such a restructuring would look like.  Remember that some of the
> most capable terminal drivers, e.g. PostScript and svg, cannot know about
> font metrics at the time gnuplot is running.  How would you take that into
> account?
> 

Well that's what I meant about not going for lowest common demoninator.
It does not make sense to limit all output to monochrome because some
terminals can't handle colour.

Each terminal's capabilities are known.

To take advantage of this capability, instead of relying on h_char and
v_char, it would need a new function like term_get_text_extent() . Those
that can't handle it return a zero or other flag and the main core code
calls the existing output. If a valid text extent is returned it gets used.

That does not sound like a major rewrite. Probably a couple of lines in
core to clean up key formatting plus the extra function added to the
terminal interface.

Maybe even svg and ps could provide a better estimation in this context.

/Peter.