> Sounds to me like if the upside down font is an indication > the requested font doesn't exist, you'll probably still need to > investigate what fonts do exist, and use those. > > In your app's case, are you using something like Fl::set_font() > to use a font other than the default FLTK font? > > I'm not sure why, but FLTK's set_font() seems to not return > an error code indicating if the font can't be found. > (return is void)
It's been a while since I looked at any of this, so I don't know either - it is possible that the Apple font engine always returns *something* so we don't know that the lookup failed? Not sure about that at all, though... > Not quite sure why this is (anyone?), but maybe you can either > request a font you know all machines have, or maybe do > a 'precheck' > using the native font calls to test if the machine has the font > you want, and only use Fl::set_font() if that test passes. Rambling and probably unhelpful anecdote follows: In an earlier iteration of an app, I had added an Fl_Preferences option to allow the user to set the font they liked for various text widgets, menus, dialogs, all that stuff. By default, these were all set to "safe" defaults, but the user could use my font-picker to set a different font, and the choice was stored in the prefs. Now, here's where I messed up - I simply stored the font index (a number) and used that to re-load the selected font the next time the app started. This worked just fine for a long time, until reports started to come in of the fonts getting "lost" or "messed up" and needing to be reset... The cause: if some other app installs a new font, all the font indexes change... So... What I do now is store the name of the selected font as a text string, and look for that one at start-up. So far that seems to be more robust. However, it doesn't address the problem of coding in a font name that you assume will exist on the end-user's system but which is not there... I am not sure there is an easy fix for this one, actually. When I was in this situation, I simply took to bundling my custom font along with my app. On OSX it is easy to embed a font inside the app bundle and load it, and win32 systems can load an arbitrary font from a given path, so they were both very easy to do. The only vaguely tricky one was XFT on Linux, where I had to contrive to place the font into a well known place in the users home dir and update the fontcache (which might entail a basic installer mechanism in that case, which is a nuisance, or do what I do and just assume Linux users are competent.) And then there's the whole issue of whether you are permitted to redistribute the font in question or not... > I think FLTK's default fonts never have this problem, as it > (I think) it only uses fonts that are known to be on > each platform. That's the idea, but in practice it doesn't always work - support for the FL_SYMBOL or FL_ZAPF_DINGBATS faces is somewhat variable across platforms. The text based faces pretty much work as intended however. -- Ian SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
