@Imad: Thanks. I finally pushed the patch to stable in my name with credits to you here:

http://hg.savannah.gnu.org/hgweb/octave/rev/8a07083c8cfc

I changed the replacement character in EPS files to be the question mark as proposed by Markus.

Closinr report as fixed.

Hi @pantxo,

Thank you for preparing these patches, and for the additional fix.
I have sent you an e-mail with my name and e-mail address, but I suggest that you push both fixes in your name since you bothered to prepare the patches.

Thanks.

ies

@ies: I attached a patch for stable that implements your solution (but with a proper replacement character instead of "?"). Can you add your email and name so that I can push it in your name?

(file #47019)

Hi,

The problem occurs in this function found in 'libinterp/corefcn/ft-text-renderer.cc':

  void
  ft_text_renderer::visit (text_element_string& e)
  {
    if (font.is_valid ())
      {
...
        while (n > 0)
          {
            // Retrieve the length and the u32 representation of the current
            // character
            int mblen = octave_u8_strmbtouc_wrapper (&u32_c, c + icurr);
            n -= mblen;
...
            icurr += mblen;
          }

If and when 'octave_u8_strmbtouc_wrapper' returns -1, it results in an infinite loop.

An obvious way to get rid of this infinite loop and at least avoid having Octave hang is to add:

+            if (mblen < 1)
+              {
+                mblen = 1;
+                u32_c = 63;  // replace with '?'
+              }

right after the call to 'octave_u8_strmbtouc_wrapper'. This is similar to what is done in 'libinterp/octave-value/ov-ch-mat.cc', for instance, and results in display of 'Fr?quence', which I believe is an acceptable outcome.

Now to why the problem occurs in the first place.

In the first (working) example:

s = "Fréquence";
text (0.2, 0.5, s)

the character U+00E9 'é' is coded as 195 169 and is correctly processed by 'octave_u8_strmbtouc_wrapper'.

In the second example based on

$ echo é | iconv -f utf8 -t latin1 | hd
00000000  e9 0a                                             |..|
00000002

'octave_u8_strmbtouc_wrapper' is called with a first byte holding 233=0xE9 and deems this not to be a correct UTF8 code value. But I must admit at this point that I am not sure why we ended up calling it like this.

I would suggest to fix the infinite loop problem, and then discuss further the observed behaviour in the second example.

This is clearly a bug that Octave hangs in this case.

You can find attached another example. This new script 'test_iso88591_2.m' (file encoded as ISO 8859-1) is simpler than the previous one and clearly shows the bug on Linux. It contains only two lines:

display('Fréquence');
xlabel('Fréquence');

On Linux, the first one is executed and the string is displayed as 'Fr�quence', which is what is expected.

The second line makes Octave 5.1.0 hang (OpenGL or fltk graphics toolkit).

In Octave 4.4.1, the second line does silently nothing, which is also a bug.

When a string is not encoded as expected, Octave should display it, with garbage characters where the encoding differs, in console or graphics.


(file #46610)

Sometimes I use on Linux some script (m-file) that comes from the Windows world. Such scripts are usually encoded in ISO 8859-1.

If there is in the script some non ASCII character (like 'é', 'à' and other french accents), in a call to functions like xlabel(), ylabel(), title(), etc., then Octave 5.1.0 gets stuck and seems to be lost in an infinite loop.

I attached two scripts to test this issue. Both contain the same code (below, 'Fréquence' is the french word for 'Frequency'):

plot( sin(1 : 1000) );
xlabel('Fréquence');

Note that the script 'test_utf8.m' is encoded in UTF-8 and the script 'test_iso88591.m' is encoded in ISO 8859-1.

In Octave 5.1.0 (system is Ubuntu Linux 18.04 64 bits), test_utf8.m is executed with no error and the word 'Fréquence' is correctly displayed, while test_iso88591.m makes Octave stuck (empty figure window, prompt never returns).

In Octave 4.4.1 (same system), test_iso88591.m runs, but displays the following error message:

warning: ft_text_renderer: failed to decode string `Fr�quence x' with locale `fr_FR.UTF-8'
warning: called from
    _axis_label_ at line 31 column 3
    xlabel at line 51 column 8
    test at line 4 column 1
warning: ft_text_renderer: failed to decode string `Fr�quence x' with locale `fr_FR.UTF-8'
warning: called from
    _axis_label_ at line 31 column 3
    xlabel at line 51 column 8
    test at line 4 column 1

In Windows, both scripts run as expected.