| [ 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: | |
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post 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 ]
|
| |