You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
LoadFont() does different things on the various backends. In nanovg it throws if a font is not found, it's unimplemented for Canvas, etc. One consistent way for it to work would be:
if the Font is already cached in the given backend, return true
attempt to load the Font from the a resource or, failing that, the installed fonts
if successful, cache the font for lookup by name in the backend and return true
else return false
Canvas doesn't actually cache fonts itself but can return true iff the font is installed, which will allow consistent behavior. Other backends may have other quirks, can these all be accommodated by the above?
The text was updated successfully, but these errors were encountered:
I'm working on this at the moment. It definitely needs to be consistent. I haven't got to canvas yet, so I'm not quite sure what will happen there, but Cairo and AGG are fine (NanoVG I also need to complete).
The issue with this (and the etc request) is that the LoadFont signature as it is might not cover all of this. As I understand it LoadFont will load a single face, but IText has a style option, which is ignored by NanoVG right now.
In cairo and AGG I am ignoring the style field when its a font loaded from disk, and I cache installed fonts on the fly using the style field as well. It would be good to be able to load them all ahead of time, but we might need multiple LoadFont() type methods or overloads. For ttc if it is a collection I presume we might need a way to select from the collection also? What would that look like?
LoadFont() does different things on the various backends. In nanovg it throws if a font is not found, it's unimplemented for Canvas, etc. One consistent way for it to work would be:
Canvas doesn't actually cache fonts itself but can return true iff the font is installed, which will allow consistent behavior. Other backends may have other quirks, can these all be accommodated by the above?
The text was updated successfully, but these errors were encountered: