Re: boxed text

[Bastian M. <bma...@we...>]

Am 21.05.2013 17:49, schrieb Ethan Merritt:
>> The core code does not apply linetype before calling boxed_text.  I
>> guess in principle the color of the box should match the current line
>> color, but at least for wxt it always comes out black.  There actually
>> is a corresponding FIXME in the core code.
>
> Please offer suggestions.  Should the linetype be a property of
> "set style textbox"?  Should it be the same as the text color?
> Some new attribute?
> I think the line width is more likely to be an issue than the color.
>

Maybe, but I could image that one could use the colour e.g. to mark 
datasets instead of using a key box.  Anyway, I would at least expect 
that the "with labels" plot style would respect the linewidth/linecolor 
setting.  I guess it is reasonable to want to be able to set a different 
colour for the text, though.

>> It is also not clear to me how to handle rotated labels.  Currently,
>>     set label 1 "rotated text" rotate by 45 boxed
>> does produce rotated text, but the box is not rotated (wxt terminal).
>> Should that case be handled by enlarging the box or by rotating it?
>
> Rotated text is just too hard to deal with, with the obvious exception
> of 90 degree rotation.   I think that will remain a necessary limitation,
> since we have no control over the interpretation of a rotated
> "bounding box" by the various underlying graphics libraries.

In case we promise not to change the angle in between the boxed_text 
calls, implementing a rotated text box should be doable.  Otherwise that 
behaviour should be documented.


 >> For sake of clarity, I would also propose to provide an enum to define
 >> actions (instead of magic numbers).  Also most API sets provide a "draw
 >> a filled rectangle with border" function.  So instead of using two
 >> successive boxed_text calls, we could save one API call per filled box.
 >
 > Yeah, that would be a reasonable change.
 >

Depending on the investigations on the latex terminals, one extra call 
to boxed_text might be needed:  After all the text labels have been 
written, those terminals might need another call to indicate the "end" 
of the boxed label and to output some closing curly brackets etc.  For 
the other terminals that would just be a no-op.

>> The terminal code should also reserve room for enhanced text. But
>> according to the comment, that doesn't work just yet for the cairo
>> terminals.
>
> It works perfectly for enhanced text. That was in fact a major part of the
> original motivation.   It's not so hard to use strlen() and font size to
> approximate the box dimensions required to enclose normal text, but the
> bounding box required for enhanced text with its various fonts, subscripts,
> symbols,  etc cannot be approximated well.
> Which comment is confusing?  Maybe it was left over from an early version.
>

Nice. I didn't do any actual testing. I just assumed this from the comment
  /* Bookkeeping for boxed text (Not working yet) */
in gp_cairo_enhanced_finish().

   Bastian