I believe the same goes for vertical white space as well,
ie. \nTesting\n\n\n and Testing would I think return
the same vertical size.
Yes - that is what I expect/believe it does!
fl_text_extent() does, however, give you the offset from the
string origin, so
Okay, so if we'd look directly at the label on a higher level draw
function, then wrapping and symbol expansion would be needed, and
fl_measure() would be appropriate, but here in the given context
we're probably looking at broken-up strings ready to be rendered,
and then fl_text_extents()
On 05/03/2012 11:14 PM, Matthias Melcher wrote:
Yes, it's all there. You can override draw(). Ye can also easily make
FL_xxx::draw(void) call the corresponding fltk3::xxx::draw(int, int, int,
int). In fact, we have to something similar anyway because FL coordinates are
relative to the next
On 05/04/2012 07:05 AM, Matthias Melcher wrote:
On 04.05.2012, at 15:30, Edzard Egberts wrote:
Matthias Melcher schrieb:
For composite widgets, I would like to propose something else though.
It should be possible to derive a new widget from any other widget,
based on the data that widget
If you are using xft there is no round-trip for measuring text.
Xft loads the font into local memory and does all the rendering in local
memory, and sends images over to the X server for Xrender to composite
onto the screen. All the extents and measuring information is stored
locally.
Lots of
