bugWarzone 2100 Project - Bugs: bug #11277, Text becomes invisible when...

Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

bug #11277: Text becomes invisible when Umlaute are in it

Submitted by:  Steven Koenig <kreuvf>
Submitted on:  Sun Mar 16 18:27:40 2008  
Category: Engine: GUISeverity: Blocker
Priority: 7 - HighStatus: Confirmed
Assigned to: Dennis Schridde <devurandom>Open/Closed: Open
Release: 2.1_beta4Operating System: All
Planned Release: 2.1

(Jump to the original submission Jump to the original submission)

Wed Jul 30 09:54:43 2008, comment #8:

Have this behaviour on Linux as well.

Dennis Schridde <devurandom>
Project AdministratorIn charge of this item.
Wed Jul 30 09:35:06 2008, comment #7:

This bug is still present in 2.1 Beta 4 and has been tested under Windows 98 and Windows XP SP2.

Same behaviour as before: When entering Umlaute or ß the whole line of text becomes invisible.

Steven Koenig <kreuvf>
Project Member
Mon Mar 17 19:48:35 2008, SVN revision 4127:

From trunk r4118: Fix bug #11277: Strings containing non-ascii characters missing

(Browse SVN revision 4127)

Dennis Schridde <devurandom>
Project AdministratorIn charge of this item.
Mon Mar 17 07:24:09 2008, comment #5:

I already needed to compile libiconv to be able to compile gettext/libintl, so I guess that should work.
This fixes it: (void)bind_textdomain_codeset(PACKAGE, "UTF-8");
-> r4118

Dennis Schridde <devurandom>
Project AdministratorIn charge of this item.
Mon Mar 17 07:23:49 2008, SVN revision 4118:

Fix bug #11277: Strings containing non-ascii characters missing

(Browse SVN revision 4118)

Dennis Schridde <devurandom>
Project AdministratorIn charge of this item.
Sun Mar 16 21:10:55 2008, comment #3:

Actually, the only encodings that GLC is aware of are : UCS-1, UCS-2, UCS-4 and UTF-8. If you try to use GLC with any other encoding, the result is undefined.

In Warzone, the string is not displayed by QuesoGLC because GLC fails internally to convert the string from UTF-8 to UCS-4. Indeed, when the string is not UTF-8 encoded, the GLC converter reports an error about an ill-formed UTF-8 string which causes glcRenderString() to raise a GLC_PARAMETER_ERROR and to abort. This error is not raised for other encodings because the conversion from UCS-1 (or UCS-2) to UCS-4 never fails. However, this conversion leads to rubbish in most cases.

I already received e-mails of complaints of users who tried to use QuesoGLC with a "locale encoded" string. So far, there is nothing to do but to convert the locale string into one of the encoding that QuesoGLC knows about. At first, I would say that libiconv is our friend but I do not know if it is portable or not (especially for Windows).

Finally, the escape sequence "\<xxx>" is obtained when the character is correctly interpreted by GLC but the corresponding glyph can not be found out. In other words, escape sequence are issued because the font coverage is insufficient not because the encoding is unknown.

I hope this helps.

Bertrand Coconnier <bcoconni>
Sun Mar 16 19:20:15 2008, comment #2:

Filed a support request as bug number 1915631 for QuesoGLC: https://sourceforge.net/tracker/index.php?func=detail&aid=1915631&group_id=53918&atid=472059

Dennis Schridde <devurandom>
Project AdministratorIn charge of this item.
Sun Mar 16 19:18:17 2008, comment #1:

If we use glcStringType(GLC_UTF8_QSO); while the locale is not an UTF-8 locale, this happens. (In reversion: If we do not set the string type to utf-8 for those locales, they seem to work.)

Dennis Schridde <devurandom>
Project AdministratorIn charge of this item.
Sun Mar 16 18:27:40 2008, original submission:

The summary says it all. Strings that contain German Umlaute (äÄöÖüÜ) do not appear in-game. This may be true for certain other characters as well, but I did not test it (e. g. áàâ).

I suspect that the problem has something to do with UTF-8, but this suspicion is not based on facts, so you are free to try finding the real culprit.

If a screenshot is needed, that won't be a problem at all.

Steven Koenig <kreuvf>
Project Member


No files currently attached


Depends on the following items: None found

Items that depend on this one

   bug dependencies.


Carbon-Copy List
  • -unavailable- added by caotic
  • -unavailable- added by bcoconni (Posted a comment)
  • -unavailable- added by devurandom (Posted a comment)
  • -unavailable- added by kreuvf (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 14 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri Oct 10 12:51:34 2008caoticCarbon-Copy-=>Added caotic
    Wed Jul 30 10:10:00 2008kreuvfDependencies-=>bugs #11615 is dependent
    Wed Jul 30 09:54:43 2008devurandomOperating SystemMicrosoft Windows=>All
    Wed Jul 30 09:35:06 2008kreuvfStatusFixed=>Confirmed
      Operating SystemAll=>Microsoft Windows
    Mon Mar 17 07:25:07 2008devurandomStatusNone=>Fixed
      Assigned toNone=>devurandom
    Sun Mar 16 19:20:15 2008devurandomSeverityImportant=>Blocker
      Priority5 - Normal=>7 - High
    Sun Mar 16 19:18:17 2008devurandomOperating SystemMicrosoft Windows=>All
      Planned ReleaseNone=>2.1
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup