Reading past bug 26903, I do see an error about saving files with accented characters (é ç à è ù) in filename with simple-scan 3.38.2 under M8 GNOME. That's drive me crazy is that the bug is reproducible with GNOME 3.38 BUT under Plasma, same machine, same user account, I ** CAN save ** with accented characters. So: to be precise, on same machine, same user account: M8 GNOME + simple-scan = accented characters forbidden. M8 Plasma + simple-scan = accented characters allowed. I really don't know why a GTK-app behaves differently regarding desktop environment. I really don't understand. Workaround: save without accented characters, rename in Files. Bhoo. That's work here... As this is a no one package, I added commiters and contributors about last bug 26903.
Assigning globally.
Assignee: bugsquad => pkg-bugs
Yes, that earlier & long bug 26903 is important, and confusing. You need to read it all. It suggests, which is probably right, thet the accent problem relates to the *GTK file picker*. https://bugs.mageia.org/show_bug.cgi?id=26903#c13 https://bugs.mageia.org/show_bug.cgi?id=26903#c25 https://bugs.mageia.org/show_bug.cgi?id=26903#c26 I have an idea I have seen the same problem with a different GTK application; if I can find it... I will try the current Mageia 8 version under all the desktops; accepting that scanned documents *are* actually saved (at one point they were not).
(In reply to Lewis Smith from comment #2) > Yes, that earlier & long bug 26903 is important, and confusing. You need to > read it all. It suggests, which is probably right, thet the accent problem > relates to the *GTK file picker*. > https://bugs.mageia.org/show_bug.cgi?id=26903#c13 > https://bugs.mageia.org/show_bug.cgi?id=26903#c25 > https://bugs.mageia.org/show_bug.cgi?id=26903#c26 > > I have an idea I have seen the same problem with a different GTK > application; if I can find it... > I will try the current Mageia 8 version under all the desktops; accepting > that scanned documents *are* actually saved (at one point they were not). I do think a fix has been implemented for M7 that did not landed in M8 version. The fix appears in https://bugs.mageia.org/show_bug.cgi?id=26903#c26 But, again, strange thing this is: Under Plasma, without modifying whatever, simple-scan CAN save files with accented characters and NOT under GNOME... for GTK app... (Un comble = a shame!).
The original, broken, fix was applied in cauldron, but later reverted. My fix to the fix was only applied in the Mageia 7 update. From a quick look, it seems the upstream code uses the native file chooser for the DE (which is why you see different behaviour when using different DEs), but the "fix" forces it to use the GTK file chooser. I'll dig a bit further to see what's really going on.
But testing with 8-beta2-Live-Plasma, I find this bug is also present.
The bug was in the sane-backends-iscan package. It temporarily sets the LC_CTYPE setting to "C" whilst reading its config file, but due to the bug, failed to set it back again, thus causing the GTK file chooser to reject characters not in the ASCII character set. Please test with sane-backends-iscan-1.0.13-2, which fixes the bug for me.
Source RPM: simple-scan-3.38.2-1.mga8.src.rpm => sane-1.0.31-1.mga8Assignee: pkg-bugs => mageiaStatus: NEW => ASSIGNED
Fixed! Under Gnome, I am able to save a file with non-ASCII characters, like é è ç à. This is Great. (Also in Plasma, which was previously the case). Closing.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
FWIW I have an Epson Perfection V500 scanner, not directly supported by Sane. I have had great trouble getting it to work on M8; as previously for M7, where I have: sane sane-backends + proprietary iscan-data iscan [ImageScan for Linux] iscan-plugins-gt-x770 the last being the magic bit for my scanner - otherwise not found. The same packages make it work under M8, although the most recent iscan bundle does *not* include the last one... I tried the accent problem under all desktops (Cinnamon, Gnome, IceWM, LXDE, Mate, OpenBox, Plasma, Xfce) and it occured *everywhere*, even under Plasma. Trying to install sane-backends-iscan-... insists on pulling iscan-2.30.4-2.x86_64 & iscan-data-1.39.1-2.noarch for dubious reasons concerning them alone; and the end result was no scanner found. All this for info.
Lewis, I take it you are using the latest version of iscan, obtained directly from Epson. sane-backends-iscan contains an older version, with non-free stuff stripped out, so I would expect it to (a) conflict with the version you are using and (b) probably not work for all devices. However, the bug I found is very likely to still be present in the version you are using. Unfortunately there's no obvious route for reporting such bugs to Epson. I don't know why Aurelien didn't see the bug when using Plasma. I saw it with all DEs I tried. People without Epson scanners got hit by this bug because task-scanning requires sane-backends, which in turn recommends (indirectly) sane-backends-iscan.
(In reply to Martin Whitaker from comment #6) > The bug was in the sane-backends-iscan package. It temporarily sets the > LC_CTYPE setting to "C" whilst reading its config file, but due to the bug, > failed to set it back again, thus causing the GTK file chooser to reject > characters not in the ASCII character set. > How do you find this? Your name is now Martin Sherlock Whitaker !
(In reply to papoteur from comment #10) > How do you find this? > Your name is now Martin Sherlock Whitaker ! It was definitely a three-pipe problem :-) Using grep, I located the code in the GTK library that generated the error message and from there traced back to the code that checked that a file name was valid. From reading that I could tell that it used the LC_CTYPE setting to determine what characters to allow. Reading the simple-scan code, I could see that it correctly set the locale settings when it started up, so something had to be resetting them. So I used gdb, set a breakpoint on the setlocale function, and ran simple-scan until I hit a call to setlocale that set LC_CTYPE to "C". I then used the gdb 'bt' command to show the call stack, which identified the culprit.