[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA: Unicode support
Hi all,
At last, I got the unicode support working... :-)
The bug which I was going crazy with has to do with the following code
in o_text_load_font:
case('\n'):
temp_string = g_strdup_printf("%s%cnewline.sym",
w_current->font_directory, PATH_SEPARATER_CHAR);
case('!'):
temp_string = g_strdup_printf("%s%cexcl.sym",
w_current->font_directory, PATH_SEPARATER_CHAR);
break;
When converting the code to a hash table, I was matching the '\n'
character with newline.sym, which was incorrect.
The case of the '\n' character has no "break" instruction, so the '\n'
matches the excl.sym... and there's a memory leak, since temp_string is
allocated and filled with the path of newline.sym, and then allocated
again and filled with the path of excl.sym .
So now I wonder... what's doing newline.sym in the font directory?
The patch now has the following behaviour:
- If working with GTK 2, all strings are converted to utf-8 when loading
a schematic. This is done by trial and error:
- It tries to convert first from UTF-8 to UTF-8 (to see if the string
is already in UTF-8).
- If the latter isn't succesfull, then tries to convert from
ISO-8859-15 to UTF-8.
- More codes can be added easily. Is someone using another code set?
- If all codes failed, then use the string as is.
- If working with GTK 1.2, loads the schematic as usual, without any
conversion.
This way, a gschem compiled with GTK2 can open previous schematics
without errors, converting them to UTF-8. When saving the schematic,
gschem will save it in UTF-8, so a previous version of gschem, or a
gschem compiled with GTK 1.2 will not be able to handle that schematic
properly (and the user will have to convert it using iconv if needed).
With this change, I can open both the ext_chars.sch in gschem/tests
directory and an UTF-8 extra_chars schematic converted using iconv
without problems.
So finally, gschem+GTK2 can handle UTF-8, but gschem+GTK1.2 can't.
Anyone has any suggestion? Do you like this behaviour?
Regards,
Carlos
--
Carlos Nieves Ónega <cnieves@iespana.es>