OK, just keep in mind we should probably make the gnuplot toolkit behave the same as the core behaves.  Hopefully it is as easy as placing

"set encoding locale"

right after gnuplot is launched (and prior to the setting of the terminal type).

Any progress on this issue?  Perhaps "progress" isn't the right word, as it seems that this one isn't difficult to address, but more a question of what should be done.

One question is whether this is a gnuplot toolkit bug or a ft_text_renderer:: bug or not a bug and just a simple warning that can be ignored.

From the ft_text_renderer:: perspective, this warning does seem like the thing it should do.  If I understand correctly, the figure property is set to interpret the text as C and there is some non-C type characters in the string so it should be a warning.  It is simply the case that gnuplot is being generous here and interpreting in a non-C way.

Should gnuplot/gnuplot-toolkit be programmed so it too improperly decodes the utf-8 in this condition?  The warning would make sense then.  I'm not quite sure what the gnuplot TK is doing right now, but if you want to see the encodings, type:

sebald@moorglade ~ $ gnuplot

        G N U P L O T
        Version 5.1 patchlevel 0    last modified 2017-04-03

        Copyright (C) 1986-1993, 1998, 2004, 2007-2017
        Thomas Williams, Colin Kelley and many others

        gnuplot home:     http://www.gnuplot.info
        mailing list:     gnuplot-beta@lists.sourceforge.net
        faq, bugs, etc:   type "help FAQ"
        immediate help:   type "help"  (plot window: hit 'h')

Terminal type set to 'qt'
gnuplot> help utf
 The `set encoding` command selects a character encoding.

 Syntax:
       set encoding {<value>}
       set encoding locale
       show encoding

 Valid values are
    default     - tells a terminal to use its default encoding
    iso_8859_1  - the most common Western European encoding used by many
                  Unix workstations and by MS-Windows. This encoding is
                  known in the PostScript world as 'ISO-Latin1'.
    iso_8859_15 - a variant of iso_8859_1 that includes the Euro symbol
    iso_8859_2  - used in Central and Eastern Europe
    iso_8859_9  - used in Turkey (also known as Latin5)
    koi8r       - popular Unix cyrillic encoding
    koi8u       - Ukrainian Unix cyrillic encoding
    cp437       - codepage for MS-DOS
    cp850       - codepage for OS/2, Western Europe
    cp852       - codepage for OS/2, Central and Eastern Europe
    cp950       - MS version of Big5 (emf terminal only)
    cp1250      - codepage for MS Windows, Central and Eastern Europe
    cp1251      - codepage for 8-bit Russian, Serbian, Bulgarian, Macedonian
    cp1252      - codepage for MS Windows, Western Europe
    cp1254      - codepage for MS Windows, Turkish (superset of Latin5)
    sjis        - shift-JIS Japanese encoding
    utf8        - variable-length (multibyte) representation of Unicode
                  entry point for each character

 The command `set encoding locale` is different from the other options.
 It attempts to determine the current locale from the runtime environment.
 On most systems this is controlled by the environmental variables
 LC_ALL, LC_CTYPE, or LANG.  This mechanism is necessary, for example, to
 pass multibyte character encodings such as UTF-8 or EUC_JP to the wxt
 and cairopdf terminals.  This command does not affect the locale-specific
 representation of dates or numbers.
 See also `set locale` and `set decimalsign`.

 Generally you must set the encoding before setting the terminal type.
 Note that encoding is not supported by all terminal drivers and that
 the device must be able to produce the desired non-standard characters.

If we were to place "set encoding locale" in the gnuplot scripts or "set encoding XX" based on some Octave figure property, whould that then put the warning and gnuplot behavior in sync?

I am running octave processing script files on a server without interactive prompt or display. The script files are supposed produce graphics. The same conditions can be reproduced on any computer by running with

export DISPLAY=
export GNUTERM=png
octave --no-window-system --no-gui -qf test.m

with test.m being

plot([1 2 3],[3 4 2])
xlabel("\\alpha Äh")
print("image.png", "-dpngcairo")

one can see on the resulting image file that the LaTeX encoded alpha and the utf-8 encoded umlaut character are properly rendered, but nevertheless Octave prints out a warning from ft_text_renderer function referring to locale C even if the locale is set to en_US.UTF-8 for example.

I do not agree on the original posters suggestion on changing the setlocale (LC_CTYPE, 0) at libinterp/corefcn/ft-text-renderer.cc because that is effectively a "getlocale" as it should. Still, somewhere during initialization process octave should do setlocale (LC_CTYPE, ""). In libinterp/corefcn/interpreter.cc as the op suggests? Another option is to use main.cc where we have a if-else structure processing different conditions with or without gui.

I actually do not get any of these warning messages when I try to reproduce this, I only get the single warning

warning: range error for conversion to character value
warning: called from
    __gnuplot_drawnow__ at line 95 column 16

when I set GNUTERM=dumb. This is addressed by the fscanf vs fread suggestion you made, which seems like a good change.

I only get the other warning messages you've shown if I explicitly set LC_CTYPE=C in my environment before running Octave.

Are you sure your LC_CTYPE facet is not set to C? Are you running octave-cli or octave (either with --no-gui or with the GUI)? This may have a bearing on whether the locale is being initialized correctly or not.

What version of gnuplot are you using?