Re: boxed text

[Ethan M. <eam...@gm...>]

On Tuesday, 21 May 2013, Bastian Märkisch wrote:
> Mojca, I think your interpretation of things is about right.  The 
> treatment you describe is needed to handle e.g. multiline labels. 
> Please note that term/README provides some more information concerning 
> parameters etc. 

Yes.  The description is in term/README.
All uses of the new terminal entry point in the current code are in
gadgets.c (write_label). 

> and the implementation e.g. for cairo clearly shows how 
> things are supposed to work.  

The implementation for Qt turned out to be the simplest.

> While implementing the code for Windows I 
> noticed some oddities, though:
> 
> 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.

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

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

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

> Concerning the spacing around the labels, I personally think it is 
> unfortunate to let terminals decide about the default spacing.  For 
> things like tic marks etc. the core code uses term->hchar/vchar as a 
> "unit" of length.

There is a partially-implemented "margin" property of the textbox
style.   I didn't document it yet because only some of the terminal
types support it at this point.  The various terminals require amazingly
different treatment.    

	Ethan
 
>    Bastian
> 
> Am 21.05.2013 14:15, schrieb Mojca Miklavec:
> > Dear developers,
> >
> > I'm trying to understand how exactly the boxed text should be
> > implemented in a terminal, but it's not clear to me how it even works.
> >
> > Is the implementation of enhanced text mode necessary? I see that the
> > terminal should provide a function
> >      boxed_text(unsigned int x, unsigned int y, int option)
> > but it's not clear to me what the function needs to do.
> >
> > Can I expect a scenario like this one?
> >     boxed_text(...,...,0) # initialize
> >     put_text(<x>,<y>,"some") # label1
> >     put_text(<x>,<y>,"text") # label2
> >     put_text(<x>,<y>,"floating") # label3
> >     put_text(<x>,<y>,"around") # label4
> >     boxed_text(...,...,1)
> > where the last command is supposed to draw a frame around all four
> > labels, no matter where on the picture they are?

No.  The box is drawn around the output from a single call to
term->put_text().   The tricky part is making it work for text
containing enhanced text mode markup like font size changes
and superscripts.

> > If not - how exactly should this work?
> >
> > Mojca