Font loading doesn't fail

Using Cinder
1

Hey Embers,

When I load a non-existent font using ci::Font(), like say ci::Font("All chars are cat gifs", 44), then ci::Font() happy provides such a font with the mName property set to All chars are cat gifs. Underneath, I think it’s good ol’ Arial and I’m wondering the following:

  1. Was this always the case? I feel like font loading was once able to fail as I have some exception catching code which is now never triggered.
  2. Is there some internal switch, possibly on the OS level I’ve ignorantly altered to always provide a backup font?
  3. I’m not keen on font loading not failing, and my best idea for a work-around currently is query ci::Font() for all available fonts and manually check the incoming name against that list. I’d much prefer to have ci::Font() just go sideways.

Anyone else have any similar experience with ci::Font() just providing a default font if it can’t find the one asked for?

Cheers,
Gazoo

2

This silently fails on windows. You’re probably comparing to ci::Font(DataSourceRef font), which does throw if it doesn’t exist.

I haven’t used cinder’s font handling for years, but try to remember you’re not forced to stay within cinder. If it doesn’t provide the functionality you need, write it. It’s extra easy if you’re only supporting the one platform, the OS will provide all sorts of APIs you can lean on that cinder is often just a thin wrapper around anyway.

In your specific case, you can just check your font name exists in the vector returned by Font::getNames() before constructing your font and you should be fine, since cinder is already wrapping the relevant winapi function for you.

3

Possibly - It’s a vague memory. Either way, there’s probably a reason it fails silently, but it was a surprise to me.

I’ve not forgotten that I can write my own stuff :slight_smile: In my experience, most developers are all too eager to re-invent the wheel, so I think it’s generally wise to explore if an existing library can solve the issue rather than just start to bolt on new code, even if the latter tends to feel far more productive.

I agree as I note this approach myself in point 3 in my original post.

Appreciate the response as always @lithium .