Menu
▾
▴
gnuplot-beta
|
From: Juergen W. <wie...@fr...> - 2005-07-05 09:27:40
|
Hi, A colleague just asked me how to use Umlauts with gnuplot on his box. As he uses SuSE 9.3, the default encoding is UTF-8. That isn't supported by "set encoding" yet. So I had to refer to latin1, ps_guide.ps and all the funny "\340" octal codes. That's of course far from being convenient. A more convenient workaround would be to switch the encoding within emacs for gnuplot files, but... So my question: Is it possible to add UTF to "set encoding"? At least for the postscript terminal? What does the postscript standard say about UTF? Juergen |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-07-05 15:48:43
|
On Tuesday 05 July 2005 02:27 am, Juergen Wieferink wrote: > A colleague just asked me how to use Umlauts with gnuplot on his > box. As he uses SuSE 9.3, the default encoding is UTF-8. That > isn't supported by "set encoding" yet. My machines all use UTF-8. It works fine. As I understand it (but I welcome correction if I'm misinterpreting), the "encoding" in "set encoding" is relevant only to the characters represented in the low byte. The whole point of UTF-8 is that it extends this one-byte set by adding additional bytes. So UTF-8 coexists in parallel with "set encoding". > So my question: Is it possible to add UTF to "set encoding"? At > least for the postscript terminal? There is no need to. It "just works". I can post some examples if you like, but really there is nothing special about it other than making sure that the requested font is in fact a UTF-8 font. UTF-8 (and other multibyte fonts) is also supported by the png/gif/jpeg terminal and more recently by x11. Hmmm. Maybe I really should add some examples to the demo pages on the web site. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Robert H. <en...@no...> - 2005-07-05 16:27:01
|
On Tue, 2005-07-05 at 08:48 -0700, Ethan A Merritt wrote:
> My machines all use UTF-8. It works fine.
Are you sure about this? I see two problems.
1) Inputting multibyte characters gives problems using backspace and/or
cursor keys to edit the command.
2) Actual output shows incorrect characters.
e.g.:
set xlabel "=E1=E2=E3=E4" font "Verdana"
show xlabel
xlabel is "\316\261\316\262\316\263\316\264", offset at
((character units) 0, 0, 0), using font "verdana"
plot sin(x)
This has an xlabel that contains eight glyphs (and not 4), and does not
contain the correct symbols.
(note I'm trying to set the xlabel to contain greek characters in this
example)
--=20
Robert Hart <en...@no...>
University of Nottingham
This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-05 17:16:29
|
On Tuesday 05 July 2005 09:26 am, Robert Hart wrote: > On Tue, 2005-07-05 at 08:48 -0700, Ethan A Merritt wrote: >=20 > > My machines all use UTF-8. It works fine. >=20 > Are you sure about this?=20 Well, it works for me. > I see two problems.=20 > 1) Inputting multibyte characters gives problems using backspace and/or > cursor keys to edit the command. I use SCIM for multibyte input. This interface is independent of the program being used. Yes, there are some operations that may not work the way you expect, but this has nothing in particular to do with gnuplot. You just have to learn the conventions of the input layer. > 2) Actual output shows incorrect characters. >=20 > e.g.: >=20 > set xlabel "=E1=E2=E3=E4" font "Verdana" > show xlabel Are you sure that you have a UTF-8 version of Verdana? Is your LC_CTYPE set to a UTF-8 language type appropriate for these letters? Which x11 terminal type are you using for input? The terminal you are running from needs to support multibyte x11 fonts in order for it to display properly. For me it works in nxterm, but not in many of the other xterm clones. But just because the terminal is too stupid to display it properly doesn't mean it is incorrectly stored in the program. > (note I'm trying to set the xlabel to contain greek characters in this > example) I cannot comment on this specifically. I have not tried using Greek in UTF-8, nor do I have any Greek fonts installed. (Note that the Adobe and MS Symbol fonts are *not* UTF-8 fonts). But I have successfully used Japanese UTF-8 fonts, following the guidelines of Shigeharu Takeno http://takeno.iee.niit.ac.jp/~shige/unix/gnuplot/gnuplot.html When I next get some time, I'll post some examples. However... I was wrong to imply that UTF-8 works equally well for all output terminals. Harald is correct in pointing out that UTF-8 output in PostScript is far more problematic than in x11 or via libgd. Harald Harders <h.h...@tu...> wrote > >> So my question: Is it possible to add UTF to "set encoding"? At >> least for the postscript terminal? What does the postscript >> standard say about UTF? > > Postscript can only handle 255 characters per font encoding. Thus, it does > not work with UTF-8. It may be possible to add a second and third encoding > that contains the encoding vectors for UTF-8 fonts. Thus, 255 characters > will be put into one font. E.g., /Times-Roman, /Times-Roman-1, > /Times-Roman-2. But this is just theoretical, not yet implemented in > gnuplot. It's a mess. PostScript 2015 (don't ask me why it seems to have appeared 10 years early :-) implements a two-layer font decoding mechanism. One layer is Adobe's own "CID-keyed font" 16-bit encoding, one is the native unicode or other multibyte font. The viewing device must arrange for=20 translation from one encoding to the other, or else the translation table and conversion routine must be included in the file itself. A general discussion, particularly with regard to ghostscript is here =20 http://www.cs.wisc.edu/~ghost/doc/gnu/7.05/CJK.htm =2D-=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Harald H. <h.h...@tu...> - 2005-07-05 16:18:59
|
J=FCrgen, > A colleague just asked me how to use Umlauts with gnuplot on his > box. As he uses SuSE 9.3, the default encoding is UTF-8. That > isn't supported by "set encoding" yet. So I had to refer to latin1, > ps_guide.ps and all the funny "\340" octal codes. That's of course > far from being convenient. A more convenient workaround would be to > switch the encoding within emacs for gnuplot files, but... If I remember correctly, the low byte of UTF-8 is identical with either latin1 or latin9. Thus, using =BBset encoding iso_8859_1=AB should also wor= k with UTF-8 (and in fact it worked for me today at work) as long as you don't use characters above \377. > So my question: Is it possible to add UTF to "set encoding"? At > least for the postscript terminal? What does the postscript > standard say about UTF? Postscript can only handle 255 characters per font encoding. Thus, it does not work with UTF-8. It may be possible to add a second and third encoding that contains the encoding vectors for UTF-8 fonts. Thus, 255 characters will be put into one font. E.g., /Times-Roman, /Times-Roman-1, /Times-Roman-2. But this is just theoretical, not yet implemented in gnuplot. Best regards Harald --=20 Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Juergen W. <wie...@fr...> - 2005-07-05 19:01:41
|
Harald Harders wrote: > If I remember correctly, the low byte of UTF-8 is identical with either > latin1 or latin9. Thus, using =BBset encoding iso_8859_1=AB should also w= ork > with UTF-8 (and in fact it worked for me today at work) as long as you > don't use characters above \377. But aren't the umlauts "=E4=F6=FC" multibyte characters in UTF-8? This is at least what hexdump says to sample files. And I can say empirically that it doesn't work to just use UTF-8 scripts containing umlauts with gnuplot -- at least with SuSE9.3. > > So my question: Is it possible to add UTF to "set encoding"? At > > least for the postscript terminal? What does the postscript > > standard say about UTF? > > Postscript can only handle 255 characters per font encoding. Thus, it does > not work with UTF-8. It may be possible to add a second and third encoding > that contains the encoding vectors for UTF-8 fonts. Thus, 255 characters > will be put into one font. E.g., /Times-Roman, /Times-Roman-1, > /Times-Roman-2. But this is just theoretical, not yet implemented in > gnuplot. Oh dear. I have spent so much time on all this font/encoding stuff. And I still feel like a complete beginner. But thank all of you for your explanations. Juergen |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-05 19:37:34
Attachments:
test.png
|
On Tuesday 05 July 2005 12:03 pm, Juergen Wieferink wrote:
> Harald Harders wrote:
> > If I remember correctly, the low byte of UTF-8 is identical with either
> > latin1 or latin9. Thus, using =BBset encoding iso_8859_1=AB should also=
work
> > with UTF-8 (and in fact it worked for me today at work) as long as you
> > don't use characters above \377.
>=20
> But aren't the umlauts "=E4=F6=FC" multibyte characters in UTF-8? =20
As I understand it, a single character glyph may have more than one legal
representation in UTF-8. So =E4 =F6 =FC each have a one-byte representation
(\344 \366 \374 if the encoding is iso8559-1 or iso8559-15) and also have
a multibyte unicode representation (C3A4 C3B6 C3BC).
> This is=20
> at least what hexdump says to sample files. And I can say
> empirically that it doesn't work to just use UTF-8 scripts
> containing umlauts with gnuplot -- at least with SuSE9.3.
gnuplot> show locale
LC_CTYPE is en_US.UTF-8
LC_NUMERIC is C
LC_TIME is C
gnuplot> set xlabel "=E4=F6=FC"
gnuplot> set term png
Terminal type set to 'png'
Options are 'nocrop font verdana 12 size 640,480 '
gnuplot> set output 'test.png'
gnuplot> plot sin(x)
(output image attached)
=2D-=20
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Juergen W. <wie...@fr...> - 2005-07-05 20:33:25
Attachments:
test.png
|
Am Dienstag, 5. Juli 2005 21:37 schrieb Ethan Merritt:
> As I understand it, a single character glyph may have more than one legal
> representation in UTF-8. So =C3=A4 =C3=B6 =C3=BC each have a one-byte re=
presentation
> (\344 \366 \374 if the encoding is iso8559-1 or iso8559-15) and also have
> a multibyte unicode representation (C3A4 C3B6 C3BC).
You are probably right. But that doesn't help me as SuSE9.3 seems
to choose the latter ones.
> gnuplot> show locale
>
> LC_CTYPE is en_US.UTF-8
> LC_NUMERIC is C
> LC_TIME is C
>
> gnuplot> set xlabel "=C3=A4=C3=B6=C3=BC"
> gnuplot> set term png
> Terminal type set to 'png'
> Options are 'nocrop font verdana 12 size 640,480 '
> gnuplot> set output 'test.png'
> gnuplot> plot sin(x)
>
> (output image attached)
gnuplot> show locale
LC_CTYPE is de_DE.UTF-8
LC_NUMERIC is C
LC_TIME is C
gnuplot> set xlabel "=C3=A4=C3=B6=C3=BC"
gnuplot> set term png
Terminal type set to 'png'
Options are 'nocrop medium size 640,480 '
gnuplot> set output 'test.png'
gnuplot> plot sin(x)
But it may also be a missing font in gdlib.
Juergen
|
|
From: Robert H. <en...@no...> - 2005-07-06 14:37:08
|
On Tue, 2005-07-05 at 12:37 -0700, Ethan Merritt wrote: > As I understand it, a single character glyph may have more than one legal > representation in UTF-8. So =E4 =F6 =FC each have a one-byte representat= ion > (\344 \366 \374 if the encoding is iso8559-1 or iso8559-15) and also have > a multibyte unicode representation (C3A4 C3B6 C3BC). I think you are confused. In UTF-8 only characters 0-127 are encoded in one byte. There is no equivalence between UTF-8 and iso8559-* except for the basic ASCII part. i.e. any characters with accents, or in foreign scripts are always multibyte in UTF-8. see, http://en.wikipedia.org/en/utf-8/ Interestingly gnuplot fails to detect my locale. I have LANG=3Den_GB.UTF-8, but gnuplot falls back to C. I will investigate further when I have the time. Rob --=20 Robert Hart <en...@no...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
