I’m using an image canvas to display a bunch of text and I need to change the font per line. Does anyone know the valid weights for the “Default” font to be used with the GetDefaultFont(integer size, Boolean bold, Boolean italic) call. Also, why does the BrightScriptReferenceManual.pdf in the SDK have the Object GetFont(String Family, integer size, Boolean bold, Boolean italic) call documented, but the docs online don’t specify it.
Is there a way to turn an roFont into a string to use with TextAttr on an imageCanvas?
Which docs are valid/most recent? There also seem to be missing documentation on many of the interfaces on the online SDK reference.
The wiki is the most up to date, but the PDFs still include some documentation that’s not available in the wiki (as you’ve discovered). There are two different versions of the roFontRegistry. In the PDFs, the roImageCanvas version is in the component reference, while the roScreen version is in the BrightScript reference. In the wiki, currently only the roImageCanvas version is documented. RokuMarkn mentioned that he was going to update it in this thread (viewtopic.php?f=34&t=51521&p=350111#p350111), but it doesn’t look like that’s happened, yet.
For the roImageCanvas, the only valid default fonts are “Small”, “Medium”, “Large”, and “Huge”, and they don’t correspond in any way, as far as I can tell, with the GetDefaultFont() that’s used with the roScreen. If you want custom sizes and weights on the image canvas, you’ll need to use our own TTF or OTF font.
I and set normatlFont to the font key in the TextAttr I get a 25 pt normal font and if I bump the font from 25 to 36 it gets bigger. I just don’t know what the magic font weight numbers are other than the 50 for normal. I know there is a bold weight it’s just what is the magic number?
“destruk” wrote:
Drawing text in the same place with the same size on the same buffer also increases the ‘weight’ that is displayed on the screen.
Really? Does this effect happen with fully opaque text? I have overwritten multiple transparent images and the result on screen is less transparency which could be mistaken (or referred to) as “weight”. Real font weight I think incorporates more pixels. One way to (kind of) do that is to draw multiple times offset by one in one or more directions. In fact, combining the offset with transparency overwrite, might be a better way overall to get a weight kind of effect.
I’ve used drawtext with black (or gray) offset by 1,1 then drawtext white (or other color) to create a shadow effect. Works very well for visibility on top of an image without requiring a background shaded box.
I appreciate the ideas, but I can’t imagine that drawing the same text multiple times is very efficient. Any of the Roku devs want to enlighten me as to what weights are in the default font?
“eockh” wrote:
I appreciate the ideas, but I can’t imagine that drawing the same text multiple times is very efficient. Any of the Roku devs want to enlighten me as to what weights are in the default font?
The font weight effect destruk is talking about is strictly a result of the anti-aliased edge transparency getting doubled up. Not a particularly effective way to make a font bold, as it has an obviously detrimental effect on the smoothness of the text.
As for the default font weights, if you want to figure it out objectively, you could just write a loop that draws multiple weights to the screen to see what, if any, difference there is. As I mentioned before, however, for the roImageCanvas, the only documented default fonts are “Small”, “Medium”, “Large”, and “Huge”. There are no weights available for those. For the roScreen, boldness is boolean, so there are only two weights available. If GetFont(“Default”…) works on the roImageCanvas, then the loop will probably get you an answer faster than waiting for Roku to respond will.
“eockh” wrote:
I can’t imagine that drawing the same text multiple times is very efficient.
Slightly off topic, but in the roScreen world, you will typically be redrawing every element on the screen as often as possible, in pseudocode your app will look like something like this (note the second line is the no-delay method of reading the messageport):
while true
msg=port.getmessage()
calculate Graphics Positions On Screen
draw bitmaps
draw text
for each sprite, adjust position based on calculate logic
compositor DrawAll
swapbuffers
end while
If you find that redrawing text is slowing your app down, you can draw text once to a bitmap of the correct size to to fit the text and then draw that bitmap in your loop instead.
Yeah, in my table view implementation this is what I do and only draw the new text, each cell is a sprite that just gets moved. However I have another view where I am using an image canvas and I can use the default font and modify the size, but I don’t know what the valid weights are. Is there any Roku developer that knows them?
If I call it with Get(“Default”, 36, 50, false) I get a 36 point regular weight font. The 3rd parameter is defined in the font. 50 is regular but what is bold?
I wasn’t ignoring you. I just didn’t see your response and was responding to RokuJoel’s after you had posted. I had intended on going back and writing a render loop to try all the parameters, but I’ve been busy writing all the other custom pieces of the channel I’m working on. Thanks for doing the work it is very useful information.
The docs are wrong. There is no integer weight parameter in the Get() function on roFontRegistry. It is a boolean value indicating bold or not.
There is a firmware bug translating between the bool value given to the Get() for bold and the weight value passed. The result of this is that it’s impossible to get a Bold font for the ImageCanvas. All integer values given to Get() for weight are converted to a boolean value for bold. But the true boolean value is converted to an internal weight of 2 which is not bold.
There is a backwards compatibility problem with fixing this in that any app that uses an integer other than 0 is currently getting a normal font, but after the fix they will get a bold font. This could break some apps.
We have opened a bug report for this, the fix is trivial but it is yet to be determined if or when we will fix it.
In the meantime, manually creating the font string as I described earlier will allow you to have bold fonts, which should survive any firmware fixes/updates as well.
