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

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

[Octave-bug-tracker] [bug #55974] Octave hangs on plotting text object w


From: ImadES
Subject: [Octave-bug-tracker] [bug #55974] Octave hangs on plotting text object with invalid UTF-8 byte sequence
Date: Mon, 3 Jun 2019 04:40:46 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0

Follow-up Comment #4, bug #55974 (project octave):

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.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?55974>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

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