Access to system fonts

techdojo

Can it be possible to access the device system fonts for use with the TextField functions?
I know passing nil, gives access to a default font, but it would be nice if we could pass in a series of other constants instead such as

TextField.SYSTEM TextField.SYSTEM_BOLD TextField.SYSTEM_ITALIC TextField.SYSTEM_FANCY

It'll save a lot of hassle setting up true type fonts (and potentially avoid any font licencing issues as well)

Also - I noticed a typo on the api docs, TextField.getText() is listed when it should be TextField:getText()

atilim

Here the problem is I cannot access raw data of system fonts on iOS and therefore cannot render by using FreeType2. And when I use CoreGraphics to render fonts, the size doesn't match with FreeType2.

I don't know if it's possible to freely distribute fonts coming with Linux (KDE, Gnome)? For example, this font family http://en.wikipedia.org/wiki/Droid_(font) has Apache license.

> Also - I noticed a typo on the api docs, TextField.getText() is listed when it should be TextField:getText()
Fixed

atilim

One other possibility can be embedding a font into Gideros runtime. Here are the sizes of Roboto family http://en.wikipedia.org/wiki/Roboto in bytes:

Roboto-Bold.ttf --> 79,620 Roboto-BoldCondensed.ttf --> 80,508 Roboto-BoldCondensedItalic.ttf --> 83,364 Roboto-BoldItalic.ttf --> 82,880 Roboto-Condensed.ttf --> 80,000 Roboto-CondensedItalic.ttf --> 82,968 Roboto-Italic.ttf --> 82,580 Roboto-Regular.ttf --> 79,396

Maybe some of them can be embedded (e.g. Roboto-Regular.ttf) and ~80k is not very much per font.

techdojo

When you say the size doesn't match, what do you mean?
Is it just that the returned string pixels sizes are wrong (something we can live with) or is it more serious than that?

techdojo

I think Roboto is freely distributable anyway - in that case would embedding give any advantages?

atilim

> Is it just that the returned string pixels sizes are wrong?
Yes. for example when you render the font with size 16, on one system it is rendered bigger than the other.

atilim

> - in that case would embedding give any advantages?
I think no. I prefer adding the .ttf file to the project instead of embedding to the gideros runtime. (both are same in terms of rendering).

techdojo

> Is it just that the returned string pixels sizes are wrong?
Yes. for example when you render the font with size 16, on one system it is rendered bigger than the other.

Sorry, if I'm just being picky, but if it's just the case that size 16 in a system font is not the same as size 16 with a ttf font, is it really a problem?

Personally I'd just pick the most appropriate "size" to fit the layout requirement and not worry about it, the advantages (on ios at least) is that you get access to all the nice Apple font's for free and if your doing a utility app it means you can keep to the same "look and feel" as the rest of the apps.

atilim

Sorry, if I'm just being picky, but if it's just the case that size 16 in a system font is not the same as size 16 with a ttf font, is it really a problem?

yes, honestly this is the only problem

I totally agree with the "look and feel" issue. It's hard to achieve the same look and feel with user provided .ttf fonts and FreeType2 rendering. Let me do some tests with CoreGraphics and FreeType2. I can put this to the roadmap.

techdojo

Much appreciated, that roadmap is getting closer to being "a journey of a 1000 miles" every day

atilim

)

techdojo

Someone's burning the midnight oil - don't you guys ever sleep?