Re: key positioning problem

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

Ethan Merritt wrote:
> 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.
> 

I thought I just did. If you don't understand maybe you missed what I
posted or I did not explain it clearly enough.


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

I don't know what you meant by framework if it was not that: a new
function in the terminal interface that can deliver the true text extent
of a given string as and when needed.

Each terminal capable of delivering a precise text extent will implement
its own low level function, eg. png_text_extent() , those that can't
will return a value indicating they can't.

Now, the key output in the core code can determine the correct text
extent where possible, where not it will fall back to the existing code
based on h_char.

Is that what you mean by a framework? does that approach make sense?

/Peter.