[SOLVED]Gnumeric and problem with non-US characters

I am trying here to get Gnumeric to recognize the UTF-8 or ISO-8859-15 characters, but there even doesn't seem to be any locale option in menus? Googling didn't show up anything spectacular.
I tried this:
LC_ALL=fr_FR gnumeric &
but got an error from command line:
(gnumeric:7559): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
And everything is still in the US format, even how dates are represented.

Thanks, rdoggsv - I got the menus in my language in gnumeric and as a bonus - I got the euro sign to work with your advice
But still I don't have characters like ä,ö,õ,ü at gnumeric. I get them nicely at kwrite, konsole, konqueror, openoffice and opera.
This missing chars - thing seems to be Gnome-specific. For example I can't get those chars visible at Gimp, graveman and galculator. But in Abiword the chars are visible in the editor's text editing field but not when for example I try to save a file.

Similar Messages

Problems with non-ASCII characters on Linux Unit Test Import

I found a problem with non-ASCII characters in the Unit Test Import for Linux. This problem does not appear in the Unit Test Import for Windows.
I have attached a Unit Test export called PROC1.XML It tests a procedure that is included in another attachment called PROC1.txt. The unit test includes 2 implementations. Both implementations pass non-ASCII characters to the procedure and return them unchanged.
In Linux, the unit test import will change the non-ASCII characters in the XML file to xFFFD. If I copy/paste the the non-ASCII characters into the Unit Test after the import, they will be stored and executed correctly.
Amazon Ubuntu 3.13.0-45-generic / lubuntu-core
Oracle 11g Express Edition - AL32UTF8
SQL*Developer 4.0.3.16 Build MAIN-16.84
Java(TM) SE Runtime Environment (build 1.7.0_76-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.76-b04, mixed mode)
In Windows, the unit test will import the non-ASCII characters unchanged from the XML file.
Windows 7 Home Premium, Service Pack 1
Oracle 11g Express Edition - AL32UTF8
SQL*Developer 4.0.3.16 Build MAIN-16.84
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
If SQL*Developer is coded the same between Windows and Linux, The JVM must be causing the problem.

Set the System property "mail.mime.decodeparameters" to "true" to enable the RFC 2231 support.
See the javadocs for the javax.mail.internet package for the list of properties.
Yes, the FAQ entry should contain those details as well.

[AS] Problem with non English characters in file path

I wrote a script that exports a pdf file from ID, rasterizes it in PS, applies an action, saves it as another pdf file, and finally creates a Mail message, and attaches the file to it (the last part is written in AppleScript).
The problem is that it doesn't work when the path to this file contains non English characters.
This works:
make new attachment with properties {file name:"/Volumes/Macintosh HD/BackUp Tetard/Test.pdf"}
but this doesn't:
make new attachment with properties {file name:"/Volumes/Macintosh HD/BackUp Têtard /Test.pdf"}
I remember vaguely that I read somewhere that AppleScript can work with Unicode — in other words with such characters — starting from some version, don't remember which exactly, but it seems to me — Leopard.
I am on Mac OS X 10.4.11 right now. Will updating solve this problem? Does anybody know any solution to this problem: a scripting addition, some hidden setting, etc.
I made a little test: used a Russian character — ё and it works, but when I use — ê (Dutch) it doesn't. May it have something to do with the Region setting in International panel?
Thanks in advance,
Kasyan

Kasyan, as of Leopard AppleScript treats all text as Unicode pre this you can specify 'as Unicode text'. Try a test with these.
-- Leopard
set x to POSIX path of (path to desktop)
-- Pre Leopard
set x to POSIX path of (path to desktop as Unicode text)
-- Leopard
set x to POSIX path of (choose file without invisibles)
-- Pre Leopard
set x to POSIX path of ((choose file without invisibles) as Unicode text)

Problem with non-ASCII characters on TTY

Although I'm not a native speaker, I want my system language to be English (US), since that's what I'm used to. However I have a lot of files which have German language in their file names.
My /etc/locale.conf has en_US.UTF-8 and de_DE.UTF-8 enabled. My /etc/locale.conf contains only the line
LANG=en_US.UTF-8
The German file names show up fine within Dolphin and Konsole (ls -a). But they look weird on either of the TTYs (the "console" you get to by pressing e.g. ctrl+alt+F1). They have other characters like '>>' or the paragraph symbol where non-ASCII characters should be. Is it possible to fix this?

I don't think the console font is the problem. I use Lat2-Terminus16 because I read the Beginner's Guide on the wiki while installing the system.
My /etc/vconsole.conf:
KEYMAP=de
FONT=Lat2-Terminus16
showconsolefont even shows me the characters missing in the file names; e.g.: Ö, Ä, Ü

Spanish Dictionary and problems with spanish special characters

I need a spanish dictionary, with all spanish words. I know that your priority are france, spanish, germany and Italy. So, the component has problems with spanish special words, this problem was notified before.
Have you ready something? A new version?
Thank you for your time.

For the special character issue, you can check the reference:
http://forums.adobe.com/message/2430501

Problems with non-English characters in iTunes 7.7

Since "upgrading" to iTunes 7.7 every file containing characters not normally found in English (e.g.: å, ß, ç, é, î, ñ, ø, ü, etc.) gets a mane change when iTunes plays the track. For example, a song called "Baião" suddenly becomes "Bai.o" and if the artist or album name contains accented characters, these get scrambled as well. The files themselves also get jettisoned from their folders in the iTunes Library, which causes big problems.

Kasyan, as of Leopard AppleScript treats all text as Unicode pre this you can specify 'as Unicode text'. Try a test with these.
-- Leopard
set x to POSIX path of (path to desktop)
-- Pre Leopard
set x to POSIX path of (path to desktop as Unicode text)
-- Leopard
set x to POSIX path of (choose file without invisibles)
-- Pre Leopard
set x to POSIX path of ((choose file without invisibles) as Unicode text)

Utl_smtp   and problem with french language characters

Hello,
I am using utl_smtp to send email.
Here is part of the proc:
First try:
mail_conn := utl_smtp.open_connection(mailhost, 25);
utl_smtp.helo(mail_conn, mailhost);
utl_smtp.mail(mail_conn, sender);
utl_smtp.rcpt(mail_conn, recipient);
utl_smtp.open_data(mail_conn);
utl_smtp.write_data(mail_conn, 'MIME-Version: 1.0' ||CHR(13)||
CHR(10)||'Content-Type: text/plain; charset=WE8ISO8859P1' ||
CHR(13)||CHR(10)|| 'Content-Transfer-Encoding: 8bit' || CHR(13)||CHR(10) || message);
utl_smtp.close_data(mail_conn);
utl_smtp.quit(mail_conn);
This gives the output:
.... adresse par element X doit etre ....
which is wrong. It should be:
.... adressé par élément X doit être ....
I then made the following modif:
mail_conn := utl_smtp.open_connection(mailhost, 25);
utl_smtp.helo(mail_conn, mailhost);
utl_smtp.mail(mail_conn, sender);
utl_smtp.rcpt(mail_conn, recipient);
utl_smtp.open_data(mail_conn);
/*This is the modif */
utl_smtp.write_data(mail_conn, 'MIME-version: 1.0' || utl_tcp.CRLF);
utl_smtp.write_data(mail_conn, 'Content-Type: text/plain; charset=WE8ISO8859P1'||utl_tcp.CRLF);
utl_smtp.write_data(mail_conn, 'Content-Transfer-Encoding: 8bit' ||utl_tcp.CRLF);
utl_smtp.write_raw_data(mail_conn,utl_raw.cast_to_raw(utl_tcp.CRLF || message));
/* end of modif */
utl_smtp.close_data(mail_conn);
utl_smtp.quit(mail_conn);
This gives the output:
FROM: [email protected]
SUBJECT: Demande pour XYZ
TO: [email protected]
.... adressé par élément X doit être ....
which is the intended result except for the FROM, SUBJECT and To.
Of course, I can make that disappear by tweaking the modif. However, I want to know why the original procedure is not working even though I followed the utl_smtp specs.
Note:
message := '
'FROM:'||V_SENDER||CHR(13)||CHR(10)||
               'SUBJECT:'||Demande pour XYZ ' ||CHR(13)||CHR(10)||
               'TO:'||V_COURRIEL||CHR(13)||CHR(10)||CHR(13)||CHR(10)||V_CORPS_MESSAGE;
Database:
NLS_CHARACTERSET : WE8ISO8859P1
NLS_LANGUAGE : FRENCH
NLS_NCHAR_CHARACTERSET : AL16UTF16
Base : Oracle9i Release 9.0.1.3.0
Thanks

Hello,
Issue was resolved.
==============================================
PROCEDURE Send_Mail (sender IN VARCHAR2,recipient IN VARCHAR2,message IN VARCHAR2, myheader IN varchar2) IS
mailhost VARCHAR2(50) :='mail.mystmpexample.com'; -- get host name;
mail_conn utl_smtp.connection ;
BEGIN
mail_conn := utl_smtp.open_connection(mailhost, 25);
utl_smtp.helo(mail_conn, mailhost);
utl_smtp.mail(mail_conn, sender);
utl_smtp.rcpt(mail_conn, recipient);
utl_smtp.open_data(mail_conn);
utl_smtp.write_data(mail_conn, myheader || CHR(13)||CHR(10));
utl_smtp.write_data(mail_conn, 'MIME-version: 1.0' || CHR(13)||CHR(10));
utl_smtp.write_data(mail_conn, 'Content-Type: text/plain; charset=WE8ISO8859P1'|| CHR(13)||CHR(10));
utl_smtp.write_data(mail_conn, 'Content-Transfer-Encoding: 8bit' || CHR(13)||CHR(10));
utl_smtp.write_data(mail_conn, CHR(13)||CHR(10));
utl_smtp.write_raw_data(mail_conn,utl_raw.cast_to_raw(message));
utl_smtp.close_data(mail_conn);
utl_smtp.quit(mail_conn);
EXCEPTION
WHEN OTHERS THEN
utl_smtp.quit(mail_conn);
RAISE_APPLICATION_ERROR(-20000,'Impossible d''envoyer le courrier du a l''erreur suivante : ' || SQLERRM);
END; -- procedure Send_Mail
==============================================
Please note that the line:
utl_smtp.write_data(mail_conn, CHR(13)||CHR(10));
is vey important since it is going to separate the header from the message itself. This will allow the message to come out alone in the email.
Variable myheader contains the From, To and Subject and each needs to be followed by CHR(13)||CHR(10
Thanks

[SOLVED!] On USB drives, problems with non-English chars and HAL

Hello,
I am having a problem with non-English caracters (áãàçéẽê...) on files stored on my USB drive.
On Windows they're created with the correct name. But on Linux the files have the non-English characteres replaced by '?' and are not accessible.
If I manuallly mount the drives using 'mount -o iocharset=utf8 /dev/sdb1 /media/usbdisk' the characters are OK, so I think I just need to get HAL to pass the correct parameters to mount. However I don't know how to do that, and haven't found any good solution.
I tried to build a custom kernel setting the default charset as UTF-8 and it didn't work.
Any ideas? I'm using x86-64, HAL 0.5.13-3 and my locale is pt-BR.UTF-8.
Thanks!
EDIT: Actually, this is not a HAL problem, but a problem with 'exo'. For the solution, I edited /etc/xdg/xfce4/mount.rc and added iocharset=utf8 to the [vfat] category.
Last edited by Renan Birck (2009-11-28 20:54:23)

I don't use Thunar presently, but I looked in the Thunar Volume Manager doc and I didn't find anything to change the mount options of removable drives. I am not quite sure if it's possible or not. Maybe someone using it can tell for sure.
But if it is not possible to change the mount options, a possible solution is to disable the Thunar Volume Manager plugin and to use something else more configurable to manage the automount function.
Personally I use the halevt package from AUR which uses configuration files in the xml format.
It's not so easy to use but is highly configurable.
But there exists other tools also.
I can help you with halevt if you choose that way...

Playlists containing songs with titles starting with non-alphabetical characters do not get transferred at all

I was really happy about how the desktop manager lets me choose the songs from my itunes library by playlists! this is smart! I'm also happy to see the playbook render asian characters properly (unlike my experience on the bold!)
However, I have a lot of songs which have titles that begin with non-alphabetical characters, ie asian characters. For all playlists which contains such songs, those songs do not get transferred onto the playbook AT ALL. For example, I have one playlist which contains only songs with titles beginning with asian characters - this playlist was transferred but it is shown as containing zero songs! When I browse my song library by artist/album, I can find all those songs that should be in that/those playlists.
Can this be fixed?
thanks.
Solved!
Go to Solution.

as it turns out, it kind of got fixed by itself. what i did (i think, since i have not definitively verified) was i went to browse "all songs" wherein i noticed all thoses songs starting with asian characters seemed to show correctly. then i went back to the playlists in question, and viola!
clearly there is a bug or two in the music player somewhere regarding these title characters. but rim has more urgent things to resolve i guess - like my auto screen lock is still not working!

Filling clob with non ascii characters

Hello,
I have had some problems with clobs and usage of german
umlauts (��). I was'nt able to insert or update
strings containing umlaute in combination with string
binding. After inserting or updating the umlaut
characters were replaced by strange (spanish) '?'
which were upside down.
However, it was working when I did not use string bindung.
I tried varios things, after some time I tracked
the problem down to to oracle.toplink.queryframework.SQLCall.java. In the
prepareStatement(...) you find something
like
ByteArrayInputStream inputStream = new ByteArrayInputStream(((String) parameter).getBytes());
// Binding starts with a 1 not 0.
statement.setAsciiStream(index + 1, inputStream,((String) parameter).getBytes().length);
I replaced the usage of ByteArrayInputStram with CharArrayReader:
// TH changed, 26.11.2003, Umlaut will not work with this.
CharArrayReader reader = new CharArrayReader(((String) parameter).toCharArray());
statement.setCharacterStream(index + 1, reader, ((String) parameter).length() );
and this worked.
Is there any other way achieving this? Did anyone
get clobs with non ascii characters to work?
Regards -- Tobias
(Toplink 9.0.3, Clob was mapped to String, Driver was Oracle OCI)

I don't think the console font is the problem. I use Lat2-Terminus16 because I read the Beginner's Guide on the wiki while installing the system.
My /etc/vconsole.conf:
KEYMAP=de
FONT=Lat2-Terminus16
showconsolefont even shows me the characters missing in the file names; e.g.: Ö, Ä, Ü

Problems with non-ascii keywords

I have some problems with non-ascii keywords that makes the whole keyword feature useless for me. I don't know if I'm doing something wrong or if there something I'm missing completely.
The problem is that when I enter something like "grön" iPhoto sometimes refuses me to type in "grön" on another photo and "eats" the "ö". And if I select the matching keyword from the popup list iPhoto has changed the originally "grön" to "gr¨ön" (if that comes out right on the web). Here are a few screenshots to show what happens
If someone knows what happens I would really appriciate some hints on how to avoid this.
Note that adding/editing keywords works just fine in Aperture.

There is a long standing issue with iPhoto and non-ascii characters. I know of no solution.
iPhoto menu -> Provide iPhoto Feedback and report it as a bug.
Regards
TD

Dreamweaver CS5 will not open. It shows the splash screen and terminates with non admin login

Dreamweaver CS5 will not open. It shows the splash screen and terminates with non admin login but works fine with admin login.
OS - WinXP Sp3
Things I tried.
1) Gave full rights on dreamweaver folder in program files.
2) Disabled welcome screen
3) Updated to Dreamweaver CS5 11.0.4
4) Reinstalled
5) Formated PC
But issue persists, please help.

Have you tried deleting or renaming the Dreamweaver configuration file?
See http://forums.adobe.com/thread/494811
This can solve many problems and create one in that any snippets that are installed are lost, but you can get them back. Instead of deleting the config file, just name it config.old. When your system is working, just copy the snippets from the .old file to the new one.

Problems with Greek accented characters

After the update to AIR 2.0.2 I cannot input into any application greek with accented characters.
Tried TweetDeck and Twhirl and neither work (used to before the update)
Is this a bug or it needs some configuration
I am working on Fedora13 but heard the same problem reported on Ubuntu.
Have not tried on MS Windows or MacOSX

Hi,
I'm using Adobe AIR 2.0.3 on Windows machine. I wrote an app in Aptana Studio (build: 2.0.5.1278522500) with ExtJS library and I found the problem with polish national characters like ż and Ż (all the other national characters like ą, ę, ń are possible to input).
In order to reproduce, here you have the sample code in ExtJS:
http://dev.sencha.com/deploy/dev/examples/form/anchoring.html
As you will see - it is possible to input ż and Ż in text fields.
Now, use the same code to build AIR applicaton and then run the application. It is not possible to input those characters in Air window. Right Alt+z acts like undo operation - it removes last entered text. All the other characters work fine.
Here is the code I used:
<html>
    <head>
        <title>New Adobe AIR Project</title>
        <link rel="stylesheet" type="text/css" href="lib/ext/resources/css/ext-all.css" />
        <link rel="stylesheet" type="text/css" href="lib/ext/air/resources/ext-air.css" />
        <script type="text/javascript" src="lib/air/AIRAliases.js"></script>
        <script type="text/javascript" src="lib/ext/adapter/ext/ext-base.js"></script>
           <script type="text/javascript" src="lib/ext/ext-all.js"></script>
        <script type="text/javascript" src="lib/ext/air/ext-air.js"></script>
        <script type="text/javascript">
        Ext.onReady(function(){
    var form = new Ext.form.FormPanel({
        baseCls: 'x-plain',
        labelWidth: 55,
        defaultType: 'textfield',
        items: [{
            fieldLabel: 'Send To',
            name: 'to',
            anchor:'100%' // anchor width by percentage
            fieldLabel: 'Subject',
            name: 'subject',
            anchor: '100%' // anchor width by percentage
            xtype: 'textarea',
            hideLabel: true,
            name: 'msg',
            anchor: '100% -53' // anchor width by percentage and height by raw adjustment
    var window = new Ext.Window({
        title: 'Resize Me',
        width: 500,
        height:300,
        minWidth: 300,
        minHeight: 200,
        layout: 'fit',
        plain:true,
        bodyStyle:'padding:5px;',
        buttonAlign:'center',
        items: form,
        buttons: [{
            text: 'Send'
            text: 'Cancel'
    window.show();
        </script>
    </head>
    <body>
    </body>
</html>
Is it possible to input those characters or is there a workaround for this (disable undo operation or so) ?
I really appreciate any help.
Kind regards,
Marcin.

Problem with Icelandic special characters on Mac

Hello
I am working on a Flash publication for students, and I want it to run on Mac as well as PC. Everything goes fine, except a problem with three special characters in my language, Icelandic. I am working on a registration and login page where I am using text boxes and text input boxes. Everything looks correct on PC, but on Mac the characters Þ Ð Ý are lost.
I have tried different fonts etc.
Any idea what is wrong?
Jónas Helgason

Hello Jónas,
Did you ever figure this out ?
I have a similar problem except only with two letters (both upper and lower case). These two Icelandic letters can't be entered into a Flex TextInput box in the Flex apps I am creating when they are loaded on a Mac. The letters are known as &Eth, &eth, &Thorn and &thorn in HTML terminology. Typing these characters on the keyboard results in the following: { [ ? /
However I can copy the characters in question from some other app like TextEdit and paste them into a TextInput box in my Flex app and all is well, they show up correctly.
This happens regardless of the Mac browser used and the Flash plugin version used (have tried both 9 and 10) and also happens in the standalone Flash Player application.
Does anyone have any idea how to fix this or is this a bug in Flash Player ? This is really annoying as it makes text input into Flex apps on Icelandic Macs very difficult.
There must be something wrong with the mapping of keyboard key codes into character codes on the Mac that is causing this.
Btw, I just heard from a friend that this problem does not exist in MacOS 10.6. I am running 10.4 and have tested this on 10.5 and it exists on both of those OS versions.
Rgds,
Hordur Thordarson
Lausn hugbunadur
http://lausn.is

Problem with non iPhone users receiving my text sent pictures. Can I make them smaller files?

Problem with non iPhone users receiving my text sent pictures. Can I make them smaller files? I know that is possible for email sent pics.

My bad, It was a Verizon problem. When they upgraded my phone they were supposed to remove all blocks on messaging . Found out they did not do this. All messaging now works. Thanks for listening.

[SOLVED]Gnumeric and problem with non-US characters

Similar Messages

Maybe you are looking for