| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
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 |
|---|
| Subsystem: | FLUID |
|---|
| Summary: | FLUID fails when saving and reloading german umlaute |
|---|
| Version: | 1.1.7 |
|---|
| Created By: | Ed |
|---|
| Assigned To: | mike |
|---|
| Fix Version: | 1.1-current (SVN: v4782) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| 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...
Thanks! | |
| |
| 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. | |
| |
| 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? | |
| |
| 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. | |
| |
| 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... | |
| |
| 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');
lineno++;
Now it works. Why should "x<0" tell a read error? | |
| |
| 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. | |
[ Return to Bugs & Features ]
|
| |
