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 16 Mar 2008 06:27:40 PM UTC  
 
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 30 Jul 2008 09:54:43 AM UTC, comment #8:

Have this behaviour on Linux as well.

Dennis Schridde <devurandom>
Project AdministratorIn charge of this item.
Wed 30 Jul 2008 09:35:06 AM UTC, 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 17 Mar 2008 07:48:35 PM UTC, 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 17 Mar 2008 07:24:09 AM UTC, 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 17 Mar 2008 07:23:49 AM UTC, 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 16 Mar 2008 09:10:55 PM UTC, 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 16 Mar 2008 07:20:15 PM UTC, 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 16 Mar 2008 07:18:17 PM UTC, 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 16 Mar 2008 06:27:40 PM UTC, 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

Digest:
   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.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 14 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 10 Oct 2008 12:51:34 PM UTCcaoticCarbon-Copy-=>Added caotic
    Wed 30 Jul 2008 10:10:00 AM UTCkreuvfDependencies-=>bugs #11615 is dependent
    Wed 30 Jul 2008 09:54:43 AM UTCdevurandomOperating SystemMicrosoft Windows=>All
    Wed 30 Jul 2008 09:35:06 AM UTCkreuvfStatusFixed=>Confirmed
      Open/ClosedClosed=>Open
      Release2.1_beta2=>2.1_beta4
      Operating SystemAll=>Microsoft Windows
    Mon 17 Mar 2008 07:25:07 AM UTCdevurandomStatusNone=>Fixed
      Assigned toNone=>devurandom
      Open/ClosedOpen=>Closed
    Sun 16 Mar 2008 07:20:15 PM UTCdevurandomSeverityImportant=>Blocker
      Priority5 - Normal=>7 - High
    Sun 16 Mar 2008 07:18:17 PM UTCdevurandomOperating SystemMicrosoft Windows=>All
      Planned ReleaseNone=>2.1
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup