'Role' is what dictates the prescribed behaviour of methods
The gist of the explanation below is "No".
Being aware of your knowledge of the language restrictions (is it allowed or not), I assume this is more a question on the principles guiding a design, I'll try to explain in such terms.
The basis on which it is to be decided, if a method or even all the methods of a given class should or should not print to the screen, is Role.
Trying to follow the Single responsibility principle as far as possible, a class would generally either be one that interacts with users or one that doesn't interact with users. Only the classes that reside on the edge of the system (UI edge, not n/w edge) would generally be either printing to the console or GUI as designed, mind you these classes will be created only after the decision about UI (console or GUI) is made.
All other classes would generally exist to perform functions that assist in intermediate stage of the result being formed. If they face a situation where some unexpected information needs to be shared outside, they should preferably use channels like logging, raising exceptions or returning error values. This can then be consumed, interpreted and shared outside to the user, as per the decided interface.
For instance, if I create a math library which prints out a message to the console when it faces divide by zero scenario, it would need to be re-written if I later want to use the same algorithm/library for a GUI based environment. This would be in disregard of the concept of modularity/reusability, a major pillar of OOP. Note that the 'role' of my math classes is to perform calculation and not to present it to user. There should be a different class that handles the job of interacting with users. This other class (or set of classes) would deal with how to present it to the user (Console/GUI), how to format/display it (Text/Tables/Graphs/etc).
This is a direct outcome of considering two of the class designing principles namely, Single responsibility principle and Interface segregation principle, in order to avoid indulging in fat interfaces.
Hope that doesn't sound rather vague.