Gnuplot svg output is broken

Bug #314023 reported by TentacleGuy
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnuplot (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: gnuplot

Gnuplot doesn't support UTF-8 in kubuntu intrepid.

But if I try to set terminal to svg it writes the following XML-Header:
<?xml version="1.0" encoding="utf-8" standalone="no"?>

But that's incorrect, the titles are in ISO-8859-1! (or other encoding, but _not_ in UTF-8)

Revision history for this message
TentacleGuy (neuhaus-dodekatex) wrote :

Are you sleeping?

Revision history for this message
Dominique Pellé (dominique-pelle) wrote :

I tried this...

$ cat test-case.gnuplot
set terminal svg
plot sin(x) title 'utf-8 test ĉĝĥĵŝŭ (Esperanto diacritics)'

$ gnuplot test-case.gnuplot > test.svg

$ head -1 foo.svg
<?xml version="1.0" encoding="utf-8" standalone="no"?>

... and looking at test.svg with inkscape for example, I can see proper accentuated characters (good)

However, I can't see the sin(x) function!? (which is a bug in the svg terminal of gnuplot it seems)

I also tried with the "png" terminal instead of "svg" and then utf-8 does not work. I see garbage.
I need to to set latin1 title to see them properly.

In gnuplot, when doing "help encoding", I see:
gnuplot> help encoding
 The `set encoding` command selects a character encoding.
 Syntax:
       set encoding {<value>}
       show encoding

 Valid values are
    default - tells a terminal to use its default encoding
    iso_8859_1 - the most common Western European font used by many
                  Unix workstations and by MS-Windows. This encoding is
                  known in the PostScript world as 'ISO-Latin1'.
    iso_8859_2 - used in Central and Eastern Europe
    iso_8859_15 - a variant of iso_8859_1 that includes the Euro symbol
    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
    cp1250 - codepage for MS Windows, Central and Eastern Europe

 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.
Press return for more:
 The PostScript, X11 and wxt terminals support all encodings. OS/2 Presentation
 Manager switches automatically to codepage 912 for `iso_8859_2`.

Hmmm, it seems that gnuplot is not yet aware of Unicode, or at least it's not described in "help encoding".
Trying "set encoding utf-8" gives an error:

gnuplot> set encoding utf-8
                      ^
         expecting one of 'default', 'iso_8859_1', 'iso_8859_2', 'iso_8859_15', 'cp437', 'cp850', 'cp852', 'koi8r' or 'koi8u'

Shouldn't gnuplot look at the current locale anyway to decide what default encoding to use?

Revision history for this message
Dominique Pellé (dominique-pelle) wrote :

I read in the gnuplot FAQ (http://www.gnuplot.info/faq/faq.html):

=================================================
4.11 How do I include accented characters

To obtain accented characters like ü or n in your labels you should use 8bit character codes together with the appropriate encoding option. See the following example:

gnuplot> set encoding iso_8859_1
gnuplot> set title "M\374nchner Bierverbrauch \374ber die Jahre"
gnuplot> plot "bier.dat" u 1:2

Consequently, you can type labels in Czech, French, Hungarian, Russian... by means of an appropriate set encoding. However, you cannot mix two encodings in one file (e.g. accents for west and east latin encodings).

A more general solution is to use UTF-8 encoded fonts, and type the UTF-8 characters directly into gnuplot. This works for many terminal types but not, unfortunately, PostScript. Update: The CVS version of gnuplot contains more complete support for UTF-8, including PostScript.
=================================================

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.