STR #1150

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Roadmap 1.1 ]

STR #1150

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:3 - Moderate, e.g. unable to compile the software
Scope:2 - Specific to an operating system
Summary:FLUID fails when saving and reloading german umlaute
Created By:Ed
Assigned To:mike
Fix Version:1.1-current (SVN: v4782)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Name/Time/Date Filename/Size top right image
#1 mike
08:21 Jan 31, 2006
bottom left image   bottom right image

Trouble Report Comments:

Name/Time/Date Text top right image
#1 Ed
05:57 Jan 20, 2006
FLUID destroys code when there is a label using german umlaute (äöü). If I label a button for example "Bläh", save the file and reload it, there is no "Bläh" but a "Bl" and some unexpected changes of FLUID-dialog.

Using FLTK 1.1.7, German Windows XP, MinGW/MSYS and GCC 3.3.1
#2 mike
13:30 Jan 20, 2006
Please attach a sample .fl file...

#3 Ed
04:43 Jan 21, 2006
Saving the file works, but reopening fails at "ä".

# data file for the Fltk User Interface Designer (fluid)
version 1.0107
header_name {.h}
code_name {.cxx}
Function {make_window()} {open
} {
  Fl_Window {} {open
    xywh {700 337 120 85} type Double visible
  } {
    Fl_Button {} {
      label {Bläh}
      xywh {25 15 70 25}
    Fl_Button {} {
      label button selected
      xywh {25 50 64 25}
#4 matt
06:03 Jan 21, 2006
FWIW, it works fine on VC6. It seems to be a MinGW clib issue that sees ä as a space in "isspace()" - which I cannot test due to a missing installation of MinGW... .  
#5 wilson.afn
08:56 Jan 22, 2006
Very strange.  I have MINGW.  Here's what I see:

I use Mozilla mail to view the fltk.bugs list.  Edzard's posted fluid source has his umlatted a (which I choose not to figure out how to type :) is corrupted into a tilded (~) A followed by a spikey ball in both places where he intended an umlatted a.  Sure enough, fluid faithfully preserves this mangled character (pair?) into its displayed button.

However, when I view his fluid source on the fltk bugs website, the umlatted a is *NOT* corrupted.  Using the uncorrupted source works fine in fluid.  The umlatted a appears as a single character wearing a colon (:) for a hat.
#6 matt
11:16 Jan 22, 2006
I am slowly getting behind the secret. I have installed Cygwin on my German machine and had no problems with the Umlaut until I realised that I am using an Amerian keyboard. The browser thing is not too surprising as every browser translates garbled character to whatever it thinks makes sense. Now, if the Umlaut is in the current code page, it'll be stored as a one byt character, but it seems that if you loaded another code pace, the Umlaut is coverted to UTF-8 when typing or when saving the file.

Anyway, FLTK does not support code pages and even emulates the Win32 codepage (ISO-???) on the Mac. So my next steps are to verify this theory and then fix the bug - probably in the keyboard input function somewhere.
#7 Ed
11:17 Jan 22, 2006
I don't understand what wilson tells about umlatted a's and spikey balls. Also there is no "ä" - this all might be problems of posted text?

The german characters "ä", "ö", "ü" are just one character and I opend the saved fluid file with another editor, which definitely shows one sign per character and didn't change anything, so {Bläh} means, there are four characters between the brackets. FLUID seems to recognize the special character, because the label is put into brackets. The problem occurs when reloading and the brackets didn't seem to work, because the "ä" should be ignored at all.
#8 matt
22:57 Jan 22, 2006
Well, as long as the umlaut a stays a single character, it loads just fine in my version of fluid, no matter if compiled under Cygwin or VisualC.  
#9 matt
07:14 Jan 23, 2006
I am sorry, but i really can not duplicate this. I taught my Cygwin German, compiled with and without --enable-cygwin, but I just can not get this to produce any kind of error. Can you give me some more hints on what may be different on your machine?  
#10 Ed
08:00 Jan 23, 2006
I only see the obvious difference MinGW vs. Cygwin and I don't think, my system is special in any way. I would look for the problem myself, but in the moment I'm very busy to release our first FLTK software. :o)
Maybe in two or three weeks - in the moment there are some things I need much more urgent than a new FLUID. ;o(
Sorry about that, but if it is only a problem of mine, there is no need to hurry, because FLUID 1.1.6 works fine.
#11 Ed
08:06 Jan 23, 2006
Ups, I was wrong: I'm using FLUID 1.1.4 which works fine. Just tried FLUID 1.1.6 and there is the same mistake as using 1.1.7. So it is not a new problem of 1.1.7, but must have appeared at 1.1.5/1.1.6.  
#12 mike
08:21 Jan 31, 2006
Try the attached patch - I'm guessing that there may be an issue with signed vs unsigned chars here, and we are missing the necessary masking to cope with that...  
#13 Ed
09:08 Jan 31, 2006
No, the patch doesn't work - it seems obvious to me, because binary AND of 255 leaves the lowest byte unchanged. But the problem is easy to find, after your pointing out to "file.cxx" I found it in some minutes reading of source and changed line 264 by comments:
    for (;;) {
      x = getc(fin);
//      if (x<0) {read_error("Missing '}'"); break;}
//      else
      if (x == '#') { // embedded comment
        do x = getc(fin); while (x >= 0 && x != '\n');

Now it works. Why should "x<0" tell a read error?
#14 Ed
09:28 Jan 31, 2006
Hmmm - I just learned a bit about plain old C. Maybe you could use the following:

 if (x<0 && feof(fin)) {read_error("Missing '}'"); break;}
 else if (x == '#') { // embedded comment
#15 mike
11:01 Jan 31, 2006
Regarding the masking of the upper bits, we need to do this so that signed characters don't break isspace() (which is only defined to work for 0 to 255 and EOF (usually -1).

It looks like Cygwin's getc is seriously broken - it is defined to return an int which is either EOF (-1) or 0 to 255, and *not* a signed character value.

The secondary check for feof() sounds like a good workaround, however I'd recommend filing a bug with the Cygwin folks - their stdio implementation is broken.

Anyways, I've committed the feof stuff in r4782, so we should be good to go.
bottom left image   bottom right image

Return to Bugs & Features ]


Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.