The docs say: “The text is drawn into the TargetRect. If it doesn’t fit, then it will be clipped.”
But my tests seem to indicate otherwise. Should text be clipped if it overflows the Target rectangle?
Your tests results would mirror mine. I’ve found that text will wrap, but not truncate. One way around it would be to use roFontMetrics and a custom font (the metrics don’t work with the built in fonts for some reason) to measure and clip the string yourself, but there is a definite performance penalty doing that, so you’ll probably want to do some local caching.
"TheEndless"the metrics don’t work with the built in fonts for some reason[/quote wrote:
I’ve asked that support be added for the built-in fonts for just this reason. It shouldn’t be necessary to use a custom font just for the ability to get the length of a displayed string.
-JT
“renojim” wrote:
“TheEndless” wrote:
the metrics don’t work with the built in fonts for some reason
I’ve asked that support be added for the built-in fonts for just this reason. It shouldn’t be necessary to use a custom font just for the ability to get the length of a displayed string.-JT
Agreed. In MainSqueeze I bounced back and forth between custom and system fonts. I ended up coming up with an average character width for each of the different system fonts, and calculate based on that. It can be wildly off on occasion, but it works for the most part.
If it helps, this is what I came up with…
If font = "Small" Then
letterWidth = 11
Else If font = "Medium" Then
letterWidth = 15
Else If font = "Large" Then
letterWidth = 21
Else If font = "Huge" Then
letterWidth = 35
End If
I actually spent a while one night mapping the exact character pixel widths for the Medium font in HD one night. Haven’t bothered to use the results yet. Maybe we should just crowdsource this and be done with it? If I supply code to step through the characters and make it obvious to note the pixel length, is anyone interesting in running it for a font size/definition and submitting the results? If so, I’ll put together a librokudev library to compute the size of a string (and lines required given a bounding box, etc)
“kbenson” wrote:
I actually spent a while one night mapping the exact character pixel widths for the Medium font in HD one night. Haven’t bothered to use the results yet. Maybe we should just crowdsource this and be done with it? If I supply code to step through the characters and make it obvious to note the pixel length, is anyone interesting in running it for a font size/definition and submitting the results? If so, I’ll put together a librokudev library to compute the size of a string (and lines required given a bounding box, etc)
I was going to do that, then I got lazy..
It should be pretty easy to draw each letter on a background image that has “registration marks” if you want to do it manually. Save a screenshot as a bitmap, and it should actually be possible to write a simple script that runs through the byte array and measures every one for you… Sounds like awfully tedious work just to workaround something that should be pretty straightforward for Roku to implement, though, especially since the built-in screens already truncate text.
“TheEndless” wrote:
I was going to do that, then I got lazy..
It should be pretty easy to draw each letter on a background image that has “registration marks” if you want to do it manually. Save a screenshot as a bitmap, and it should actually be possible to write a simple script that runs through the byte array and measures every one for you… Sounds like awfully tedious work just to workaround something that should be pretty straightforward for Roku to implement, though, especially since the built-in screens already truncate text.
Yeah, that’s sort of what I did for the medium font. I scripted a loop that displayed a few characters (x10 for each one) at a time, each overlaid onto some standard size ImageCanvas background colors. It was pretty easy to determine the sizes. Displaying 10 characters at a time makes it trivial, since the last character will end on a 10 pixel border, which is fairly easy to distinguish visually.
It wouldn’t be hard to script something let you choose the font, and to do a screen per char (cycled with a button press) with the background boxes to make it obvious exactly what size the character is.
In an exercise in stupidity, I took my own challenge, and wrote a channel to crowd source this like I suggested I would. I could have just found all the sizes in that time, but that wouldn’t have been as much fun (err, I guess).
https://owner.roku.com/Account/ChannelC … =FONTSIZER
Size the fonts, and when done (or you’ve had enough), press PLAY to submit the stored data to a server. If enough people do it, I’ll sanitize the data and post the results. It submits the data separated for SD and HD running sets, so numbers for both would be good (although I haven’t run it on SD yet, so it may look funky).
Blah. Time to watch some Netflix.
Thanks for pointing out the issue of getting fontmetrics from system fonts… I’m not sure why we can’t do this, but we’ll investigate.
–Kevin
Just a couple of comments: targetrect clipping may be the documented way it is supposed to work, but most programs that draw text in a scaleable rectangle wrap the text (microsoft word, adobe photoshop etc etc), so this is expected behavior for anyone who didn’t read that page of the manual. I would hope that the wrap behavior does not change or you will probably break lots of channnels. Maybe add a wrap/clip switch with wrap as a default.
- Joel
“jbrave” wrote:
Just a couple of comments: targetrect clipping may be the documented way it is supposed to work, but most programs that draw text in a scaleable rectangle wrap the text (microsoft word, adobe photoshop etc etc), so this is expected behavior for anyone who didn’t read that page of the manual. I would hope that the wrap behavior does not change or you will probably break lots of channnels. Maybe add a wrap/clip switch with wrap as a default.
- Joel
Wrapping makes sense if the TargetRect is big enough to hold the text. What we’re talking about here is the fact that the text isn’t clipped, even if it overruns the bounds of the TargetRect.
My expectation is that it would work similar to an HTML div with its CSS overflow property set to “hidden” where the text would wrap within the bounding box’s width but clip on the height.
(Note in CSS you can set the white-space to nowrap which would clip the text on the width if the overflow is hidden)
“mike.ryan” wrote:
My expectation is that it would work similar to an HTML div with its CSS overflow property set to “hidden” where the text would wrap within the bounding box’s width but clip on the height.(Note in CSS you can set the white-space to nowrap which would clip the text on the width if the overflow is hidden)
The strange thing is that the built-in UI elements behave exactly like that. Not sure why it’s different on the image canvas.
Anyone found a solution for this? I am guessing one would have to check the width with GetOneLineWidth() and clip the txt if greater than bounding width?
