While I tend to lean on the side of singletons being just as bad as globals, at some point it comes down to how you define a "singleton," and I suspect we're on the verge of talking past each other because of that.
The key thing in this context is that the resources (fonts and texts) should have a clear ownership and access policy that the implementer consciously chose. Globals and singletons typically result from programmers not bothering to think about that, which is the real reason they're so problematic.
paupav has to make this choice since he knows far more about his program than we do. But I can think of at least three sane options that might fit:
1) If the "menu" class is the only thing that ever uses these resources, then those resources should be static members of menu, the constructor loads them if necessary, and nobody except menu's methods gets access to them. Nice and simple.
2) If there are multiple GUI objects that all share these resources (say a few menus, some buttons, some labels, and so on), it may make sense to have a class like GUIManager that owns the common resources and passes them to the individual objects (hopefully in the form of a const reference). Maybe you already have a class managing all these objects and this should simply be added to it.
3) If multiple objects share these resources and a manager class doesn't make a lot of sense for whatever reason (nothing else for it to manage, the objects are all of very different types, etc) then you should create a class that does nothing but manage resources and instantiate it in main(). You then pass the rest of your objects/subsystems a reference (again, ideally const) to either the manager itself or specific resources it loaded. There may be a little bit of #2 involved here if your program has a lot of layers.
#3 is probably what most of us would recommend doing in most game-like programs. It may seem like a pain because you have to pass a resource or a resource manager through a bunch of functions instead of just making them globally accessible, but that's a good thing. It forces you to design your classes and their interfaces in a way that makes it easy to inject dependencies like this, rather than relying on a singleton or a bunch of globals just "being there".
Personally, the only thing that I have no qualms about making global/singleton is a logger. You want the ability to log stuff in literally every single function in your program, and you want there to be only one logger for all those functions, but adding an extra parameter to literally every function is a bit silly. A resource manager class definitely shouldn't be used in every function, so you should at least make an effort to do that without a global/singleton.
