
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi,<div><br></div><div>Currently there are several ways to display messages to the user in ScummVM: GUI::MessageDialog, GUI::TimedMessageDialog and OSystem::displayMessageOnOSD. The first two work fine with translations I think, but the last one doesn't. On some platforms it apparently uses a TimedMessageDialog, which should be fine, but on SDL, OpenGL, Android and PS2 backends it doesn't and accentuated characters are not displayed correctly (at least on the SDL backend which is the only one I tested). The documentation says "<span class="Apple-style-span" style="font-family: Geneva, Arial, Helvetica, sans-serif; font-size: 10px; ">Currently, only pure ASCII messages can be expected to show correctly.</span>" so I consider the problem as normal. But that means that the messages displayed using OSystem::displayMessageOnOSD() cannot currently be translated and I would like to fix that. So here is what I am proposing to do.</div><div><br></div><div><br></div><div>I looked quickly at the code, and for the SDL backend at least (and probably OpenGL backend as well) it is only a font issue. The kOSDFont (ScummFont) only has ASCII characters, but a quick hack in FontManager to use the same font for OSD as the one used for GUI make OSD display correctly accentuated characters.</div><div>So I was thinking of doing the following:</div><div><br></div><div>1) Move <span class="Apple-style-span" style="font-family: Menlo; font-size: 11px; ">ThemeEngine::genLocalizedFontFilename(</span><span class="Apple-style-span" style="font-family: Menlo; font-size: 11px; "><span style="color: #b818a3">const</span> Common::String &filename</span><span class="Apple-style-span" style="font-family: Menlo; font-size: 11px; ">)</span>into FontManager class and maybe add a similar function that takes the FontUsage instead of the font name (or make getFontByUsage() return the localized font for the current translation if it can be found in the _fontMap).</div><div><br></div><div>2) Make localized fonts available for OSD in FontManager.</div><div><br></div><div>3) Modify SDL and OpenGL backends if needed to use a localized font to display OSD (if I change getFontByUsage() to return the localized font, there is no need to modify these backends).</div><div><br></div><div>The issue with this plan is for Android and PS2. The PS2 backend uses a printf (why not keep the default implementation that uses a TimedMessageDialog by the way?) while Android uses some Java stuff apparently, which seems to take UTF8 strings.</div><div><br></div><div>I have several questions regarding this plan:</div><div><br></div><div>a) Do we want to keep a separate font for OSD or would using the GUI or Console font be fine?</div><div>Since those last two are already present in both built-in and localized fonts (in theme packages) that would be the easiest way to go. If we want to keep the ScummFont, is there any information on that font somewhere (e.g. where does it come from) to make it possible to generate localized fonts? A possibility would be to keep ScummFont for OSD if we don't use translations, but switched to the localized GUI (or Console) font if needed.</div><div><br></div><div>b) According to your knowledge, is there any other backend (other than SDL, OpenGL, Android and PS2) that reimplement displayMessageOnOSD() and that I missed?</div><div><br></div><div>c) Loading localized font is still handled by the ThemeEngine. I am fine with that since the fonts have to be loaded from the theme zip files anyway. But can this be a problem to use these fonts in classes not related to the GUI? I can't see one but maybe I missed something.</div><div><br></div><div>d) Any idea for the Android backend?</div><div>I could let the Android porter fix that or maybe try iconv to convert messages from the current TranslationManager encoding to UTF8. But since I have no way to test my code (or even check that it compiles - and I don't even know if iconv is available on Android) I would prefer the Android porter to take care of it.</div><div><br></div><div>e) Is there anything else I am forgetting?</div><div><br></div><div>f) Finally (and the most important) is it fine to say that displayMessageOnOSD() should assume the message uses the current encoding of the TranslationManager and to implement the change I am proposing or is there any objections to it (or a better way to achieve the goal)?</div><div><br></div><div>As soon as I have the green light, and some answers to my questions above, I will start working on that and then make more strings translatable in the code.</div><div><br></div><div>Thierry</div><div></div></body></html>