octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #49339] False error reports while producing la


From: anonymous
Subject: [Octave-bug-tracker] [bug #49339] False error reports while producing latex with non-ascii chars under gnuplot
Date: Thu, 13 Oct 2016 20:14:57 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0

URL:
  <http://savannah.gnu.org/bugs/?49339>

                 Summary: False error reports while producing latex with
non-ascii chars under gnuplot
                 Project: GNU Octave
            Submitted by: None
            Submitted on: Thu 13 Oct 2016 08:14:55 PM UTC
                Category: Plotting with gnuplot
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Inaccurate Result
                  Status: None
             Assigned to: None
         Originator Name: R.S.Carmenes
        Originator Email: address@hidden
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.2.0-rc2
        Operating System: GNU/Linux

    _______________________________________________________

Details:

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:


graphics_toolkit gnuplot
plot([-10:10],[-10:10].^2,'o-')
title('Título de la gráfica')
print('-dpdflatexstandalone','-color','test')


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):


warning: ft_text_renderer: failed to decode string `Título de la gráfica'
with locale `C'
warning: called from
    title at line 53 column 3
    bug2 at line 3 column 1
warning: ft_text_renderer: failed to decode string `Título de la gráfica'
with locale `C'
warning: called from
    title at line 53 column 3
    bug2 at line 3 column 1


The same script leads to even more error messages if ran from a pure text
terminal:


warning: ft_text_renderer: failed to decode string `Título de la gráfica'
with locale `C'
warning: called from
    title at line 53 column 3
    bug2 at line 3 column 1
warning: ft_text_renderer: failed to decode string `Título de la gráfica'
with locale `C'
warning: called from
    title at line 53 column 3
    bug2 at line 3 column 1
warning: range error for conversion to character value
warning: called from
    __gnuplot_drawnow__ at line 95 column 16
    print at line 345 column 5
    bug2 at line 4 column 1


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.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Thu 13 Oct 2016 08:14:55 PM UTC  Name: latin1-cc.patch  Size: 1kB   By:
None

<http://savannah.gnu.org/bugs/download.php?file_id=38722>
-------------------------------------------------------
Date: Thu 13 Oct 2016 08:14:55 PM UTC  Name: latin1-gnuplot.patch  Size: 817B 
 By: None

<http://savannah.gnu.org/bugs/download.php?file_id=38723>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?49339>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]