gnuplot-beta

boxed text

[Mojca M. <moj...@gm...>]

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?

If not - how exactly should this work?

Mojca

Re: boxed text

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

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. and the implementation e.g. for cairo clearly shows how 
things are supposed to work.  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.

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?

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.

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.

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.

   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?
>
> If not - how exactly should this work?
>
> Mojca

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

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