Thu 13 Oct 2016 08:14:55 PM UTC, original submission:
When printing plots containing non-ascii chars to latex files under the gnuplot graphics_toolkit, the resulting latex output is correct, but octave reports a series of false error messages, no matter which locale settings you use.
I am providing a patch solving the source of the problem too, which is spread over several files.
It is not a serious issue, but it is disturbing, and potentially missleading: in fact it made me spend a lot of time trying to see what was wrong, until I realised that nothing but the messages were really wrong.
As a sample, I use the same similar as for bug #49338, except for the graphics_toolkit:
When calling octave from the command line to run a script with the above code, octave sends the following to sdterr if we are on a X11 terminal (none of it being present if pure ascii was used):
The same script leads to even more error messages if ran from a pure text terminal:
On my computer I have LC_ALL=es_ES, but I tried all sort of settings without success. In other words, it seems that octave is currently ignoring the locale settings.
After investigation, I found the source of those false error messages, spread over several files. Here follows a short description of what is wrong:
libinterp/corefcn/ft-text-renderer.cc:
it uses
std::setlocale (LC_CTYPE, 0));
but it should be
std::setlocale (LC_CTYPE, ""));
(maybe for some compilers 0 and "" are equivalent, but it doesn't seem to be with mine, gcc 5.3.0).
libinterp/corefcn/interpreter.cc:
Octave is missing to be informed of the current locale before forcing it to
use the "C" locale for numbers (necessary to follow the matlab usage).
In other words, we need to add
setlocale (LC_CTYPE, "");
before
setlocale (LC_NUMERIC, "C");
setlocale (LC_TIME, "C");
scripts/plot/util/__gnuplot_drawnow__.m
scripts/plot/util/print.m
These two files use fscanf(fid, '%c', Inf) to read files containing text; fscanf succeds reading non-ascii chars, but report them to be out of range regardless of locale settings.
Using fread is equally successful, but has the advantage of not reporting out-of-range messages; additionally, it is faster when fscanf is wanted only to read an entire file char by char.
I already corrected print.m via the patch accompanying the description of bug #49338, so I attach two patch files correcting the remaining problems. Recompilation is necessary, as two *.cc source files are slightly modified.
Hope this helps.
|