FLTK logo

STR #2941

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]

STR #2941

Application:FLTK Library
Status:5 - New
Priority:1 - Request for Enhancement, e.g. asking for a feature
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:RFE: fl_text_extents(): support multiple lines
Version:1.3-feature
Created By:greg.ercolano
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]

No files


Trouble Report Comments:

Post Text ]
Name/Time/Date Text  
 
#1 greg.ercolano
11:17 Mar 27, 2013
Would be nice if an alternate version of fl_text_extents() were available
that could handle crlfs in the string.

Probably wouldn't be too hard; just need to break the one string
into separate lines, then run the existing fl_text_extents() on each line.

The tricky part would be to take into account FL_ALIGN_* flags..
 
 
#2 ianmacarthur
16:05 Mar 27, 2013
Yes, I thought about that at the time, but chose not to do it.

The problem is, it is not obvious what the right answer is, for a string that has carriage returns / line feeds in it.

In particular; What is the resulting vertical height?

It will presumably *not* be the sum of the vertical heights of the constituent "sub-strings", since that will not account for the vertical leading between the rows of text - assuming the rows are rendered by the host system's regular text drawing mechanism.

So, for multi-line text, you probably *need* to render each line yourself, if you care about the inked extent, so that you can directly control the vertical leading between rows. Or, use fl_measure and accept that it will return a bounding box that is "larger" than the inked extent... I suspect that in the case of multi-line text that fl_measure will usually be more useful anyway.

Hmm, now I think about it, I'm not even sure I know what the various different host text systems do with measuring the extents of wrapped text... It is even possible that *some* of them might even "get this right", i.e. return a bounding box that describes the inked extents, incorporating the vertical leading.

But I do not know for sure, and certainly some of the text systems Do Not "get this right", so...

It's tricky.
 
 
#3 greg.ercolano
18:51 Mar 27, 2013
@Ian, can't blame you -- impressed you took on fl_text_extents()
at all.. big job, multiple platforms!

But isn't the multiline issue simpler? Perhaps I'm missing
something, but I would think the hard work has been done already..
The case of multiple lines, a three line example might be:

    First line
    Middle line
    Last line

Forgetting alignment for now, and assuming first and last lines
aren't blank (can be determined with fl_text_extent() to see if
there's no inking area) and we want the dx/dy/w/h extents of
this multiline string, wouldn't the overall 'h' of all three lines
be the sum of FH+MH+LH, where:

    FH = fl_height()-dy of "First line"
    MH = fl_height()
    LH = dy of "Last line"

e.g:

                                        _____________________
                                        _____ dy          |
 ######     #    #####    ####    #####   |               |
 #          #    #    #  #          #     |               |
 #####      #    #    #   ####      #     | FH            | fl_height()
 #          #    #####        #     #     |               |
 #          #    #   #   #    #     #     |               |
 #          #    #    #   ####      #     |               |
. <-- baseline                          __|_______________|__
                                          |               |
 #    #  #  ####   ####   #     ####      |               |
 ##  ##  #  #   #  #   #  #     #         |               |
 # ## #  #  #   #  #   #  #     ###       | MH            | fl_height())
 #    #  #  #   #  #   #  #     #         |               |
 #    #  #  #   #  #   #  #     #         |               |
 #    #  #  ####   ####   ####  ####      |               |
. <-- baseline                            |_______________|__
                                          |               |
 #         ##     ####    #####           |               |
 #        #  #   #          #             | LH            |
 #       #    #   ####      #             | (dy of last)  | fl_height()
 #       ######       #     #             |               |
 #       #    #  #    #     #             |               |
 ######  #    #   ####      #           __|___            |
. <-- baseline                          __________________|__


And this would of course extend to any number of middle lines.

The trick would be to watch out for leading and trailing blank lines,
but these could be detected by the existing fl_text_extent() on each
line to detect the first and last inked lines, and adjust dy and h.

What I figure gets tricky is the mixture of the FL_ALIGN_* flags
which affect horiz + vertical orientation (INSIDE, OUTSIDE)
as well as the origin of each line (CENTER).

Tabs might be another issue, not sure.
But I guess all this nothing the multiline fl_draw() doesn't
already do to calculate text alignment, and you've already done
the hard work to calculate font inking sizes.
 
 
#4 ianmacarthur
10:52 Mar 28, 2013
This may be possible, but I didn't do it (thinking about it was making my head hurt...)

I guess the idea is to use the "typographical height" of the folded string, which will take into account the vertical leading between rows of text and so forth; but "tailor" that to take account of the "inked height" of the first and last rows... Or something...

In any case, I think we'd maybe want to make that a distinct function from fl_text_extents() if we did that ?

I also wonder about (somehow) handling fltk "@" symbol expansion and so forth in the "improved" mechanism. If we go that way...
 
 
#5 greg.ercolano
12:08 Mar 28, 2013
Based on fl_measure(), I'd say symbol support isn't hard.

The symbols simply scale to the current string height, whatever it is.

So if it's a single line, it's exactly fl_height().

If it's multiple lines, it scales to the fl_height() x #lines.

The new code I intend to replace fl_measure()'s with will probably
be good reference for that. Perhaps I should make it a function that
returns the (potentially two) symbol sizes.

The symbol size calculations in fl_measure() appear to assume
symbols are square, which makes computation easy.

Apparently symbol scaling (e.g. "@+9->" and "@-9->") doesn't affect
fl_measure() calculations, so I guess it just over-draws or under-draws
when the user supplies that in a string.
 
 
#6 greg.ercolano
12:21 Mar 28, 2013
> symbols simply scale to the current string height, whatever it is.

I should add fltk's @ symbols are not really like "characters",
they're more like "graphics that fill the left and right margins".

See this screenshot, esp. see the last example for the behavior
of @ symbols in a multiline string:
http://www.fltk.org/strfiles/2940/symbol-examples.png

I never knew it worked that way; want to add that to the docs,
which is what STR# 2940 covers.
 
     

Return to Bugs & Features | Post Text | Post File ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.