Re: key positioning problem

[Ethan M. <merritt@u.washington.edu>]

On Monday 23 February 2009 10:14:03 pl...@pi... wrote:
> 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.

Huh?
I don't understand at all.
There is already similar code in various terminal drivers, called when
a new font is selected. For example, this bit from gd.trm:

    /* Find approximate character width and height of selected TTF font */
    if (png_state.ttffont) {
        int brect[8];
        char *err;
        err = gdImageStringFT(NULL, &brect[0], 0,
                png_state.ttffont, (double)png_state.ttfsize,
                0.0, 0, 0, "f00000000g");
        if (!err) {
            term->h_char = .11 * (float)(brect[2] - brect[0]) + 0.5;
            term->v_char = 1.1 * (float)(brect[1] - brect[7]) + 0.5;
        }

But there is no framework in place for the core code to invoke this for
individual strings, nor make use of the result.  You would need to design
such a framework.

> >> 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.

I look forward to any code you care to prototype.


-- 
Ethan A Merritt