#178 xfig can break utf8 file on a non-uft8 locale

[Vladislav Zavjalov]

Way to reproduce: make a file with utf8 symbol which can not be converted to the local 7-bit locale in a text object or comment of any object . Open and close Edit dialog for the object. Xfig fails to convert the symbol to the current locale and back, as a result the file is broken.

I do not think it is an important issue (if one works in a 7-bit locale, this kind of thing is not a surprise). But I wonder, could it be reasonable to set LC_CTYPE=C.utf8 for libXt and get rid of all conversions in the edit dialog? Will it produce any problems with fonts in a wrong locale?

I attached a patch which I made for myself (with just a setlocale(LC_CTYPE, "C.utf8"); after XtAppCreateShell, and without conversions in e_edit.c), but it produces some warnings, not sure that it's a good way to fix the problem
Warning: Missing charsets in String to FontSet conversion Warning: Cannot convert string "-*-times-medium-r-normal--16-*-*-*-*-*-*-*,-*-*-medium-r-normal--16-*-*-*-*-*-*-*,*--16-*" to type FontSet Warning: Non-character code(s) in source. Warning: Non-character code(s) in source.

[tkl]

Not yet looked deeper into it, but I believe the same effect can be reached, or the issue avoided, by starting xfig with the -nointernational option.

[tkl]

I though I have to live with whatever locale the user chooses, and convert internally to utf-8. In fact, your patch seems to work, simply putting setlocale(LC_CTYPE, "C.UTF-8"); at line 810 in main.c, after XtAppCreateShell(). (The conversion routines disabled in 0001-set-C.utf8.patch in that case anyhow fall back to strdup()). Thus, X11 or the input method has to do all the conversion, the developer can happily live and be surrounded everywhere by utf-8? No conversion needed? It was quite an effort to write all that conversion code, but if it is not necessary, I would gladly take it out.

A small compatibility question arises, whether C.UTF-8 is everywhere available. I would think, yes, else one could fall back to non-international (basically, latin1) xfig.

[Vladislav Zavjalov]

I've found this answer:
https://unix.stackexchange.com/questions/597962/how-widespread-is-the-c-utf-8-locale

[tkl]

Funny, the answer you found on stackoverflow specifically refers to archlinux, which is the main system I am working on. The answer is from 2020, in the meantime archlinux has C.UTF-8. For MacOS there is a different technique that could be used, see another answer at stackechange. The latter answer also points to a useful discussion for python.

Since a conversion code is in place, a suitable way could be to test for C.UTF-8 and UTF-8 and, on failure, falling back to the current environment and using conversion.