[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(): supportmultiple lines
Hm, doesn't fl_measure() do all this already? - chris 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(): supportmultiple lines
On 03/27/13 11:41, chris wrote:
Hm, doesn't fl_measure() do all this already?
No, fl_measure() measures typographical area,
whereas fl_text_extents() measures the 'inking area'.
These are very different.
See the test/unittests program, text rendering test for a comparison
of the two functions (red vs green boxes)
In particular how the two functions calculate differently the bounding
region
for the characters ('), (-), and (_); fl_measure() returns the x,y and
height
for those characters, whereas fl_text_extents() does not.
___
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(): supportmultiplelines
*Correction*
In particular how the two functions calculate differently the bounding
region
for the characters ('), (-), and (_); fl_measure() returns the *SAME*
x,y and height
for those characters, whereas fl_text_extents() does not.
___
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(): supportmultiplelines
Ah, I think I understand the difference now, will have a look at the test
tomorrow...
Though at now cannot imagine a use case for knowing the inking area.
Thanks for clarifying.
- chris
*Correction*
In particular how the two functions calculate differently the bounding
region
for the characters ('), (-), and (_); fl_measure() returns the *SAME*
x,y and height
for those characters, whereas fl_text_extents() does not.
___
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(): supportmultiplelines
On 27 Mar 2013, at 20:16, chris wrote: Ah, I think I understand the difference now, will have a look at the test tomorrow... Though at now cannot imagine a use case for knowing the inking area. Ah, but it turns out that there are quite a lot of uses for knowing the inked area of a typographical element. Not so much for rendering strings of text though; in that case fl_measure if usually the right thing. But if you are rendering text for other purposes, it is often beneficial to know what the actual extents are, since they are usually smaller, some times much smaller, than the sizes reported by fl_measure. Even using fonts decoratively, it is useful to know the extents... For my own part, for example, I often use fl_text_extents to measure glyphs from musical fonts, to ensure that they are positioned on the staff accurately, and suitably sized. The values returned by fl_measure are pretty well useless for this purpose. So, maybe not all that everyday a use case for most folks, I guess, but a real one nonetheless! Cheers, -- Ian ___ 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
