Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): support multiple lines
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature 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... Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): support multiple lines
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature 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. Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): support multiple lines
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature 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. Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): support multiple lines
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature 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.. Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): support multiple lines
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature 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. Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): support multiple lines
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. I actually needed this feature in my app, which coincidentally, was also rendering musical symbols. I took the brute force approach: I draw each symbol (which is actually multiple glyphs composed together) on a white buffer and then see how many pixels of white border there are. There are a small number of symbols so I can easy cache the sizes. It was a real pain to implement but seems to mostly be working. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): support multiple lines
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature @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. Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
