gnuplot-beta — Developers and beta testers of new gnuplot code

Re: can gnuplot do UTF-8 at all? [was: pm3d for emf terminal and point types]

[Dr. J. Z. <joh...@ze...>]

On Wed, Dec 13, 2006 at 11:21:48AM -0800, Ethan Merritt wrote:
> So yes, you have a very good point there.  
> It should probably use wcslen() instead.

this will proably not do the job, as wcslen doesn't know anyhting about
the encoding of the input string, does it?

-- 
Johannes

Re: pm3d for emf terminal and point types

[Dr. J. Z. <joh...@ze...>]

On Wed, Dec 13, 2006 at 08:24:17AM -0800, Ethan A Merritt wrote:
> Anyhow, the document you pointed to is not a spec for emf. It is 
> desciption of several generation of Windows' API.  The limitation to 
> UTF-16 is a Windows problem as I understand it, not anything in
> particular to do with the "real" EMF.

I believe the main use of emf files is for windows isn't it? -- so the
emf output should be windows compatible IMHO, even if UTF-16 is a
windows limitation. Actually I generate emf files with gnuplot on Linux
for using them in windows applications!

-- 
Johannes

Re: pm3d for emf terminal and point types

[Dr. J. Z. <joh...@ze...>]

On Wed, Dec 13, 2006 at 07:19:12PM +0100, Timothée Lecomte wrote:
> Dr. Johannes Zellner wrote:
> > ...
> > well, I had a quick look at unicode for emf. Apparently emf can only do
> > UTF-16 (little endian). Implementing this is really easy when using
> > iconv to convert to UTF-16LE. The drawbacks are:
> >
> > 1. will loose some characters, e.g. when converting UTF-8 to UTF-16.
> >   
> 
> UTF-8 and UTF-16 are just two differents encoding schemes for Unicode, 
> i.e. the same range of characters.
> iconv can convert from UTF-8 to UTF-16 without losing anything.

no. That's not true as far as I know. There are for example 3-byte UTF-8
characters like sub/superscript 1 - 9 and I belive only subscript (or
superscript?) 2 and 3 are available in UTF-16. Can you read this:

    set title 'äöü ÄÖÜ ß ₂²₃³₄⁴₅⁵₆⁶₇⁷₈⁸₉⁹ ½ ¾ ¼ €'

(The mail should be utf-8 encoded). Try to convert it to UTF-16 and
you'll loose some of the characters. At least this is what I observed
when using iconv.

I believe that µ and λ (also σ) are implemented both in UTF-8 and
UTF-16, but only µ is implemented in latin1 so it makes sense to
implement more than latin1 for the emf terminal.

> > This gives me the idea of rather having a terminal independent recode
> > option like
> >
> >     set recode "from encoding" "to encoding"
> >
> >   
> I agree with Ethan: I would rather use the locale mechanism to determine 
> the input encoding, deprecate the 'set encoding' command.
> Then I would make gnuplot depend on iconv, and each driver could use 
> iconv facility to translate from the locale to its preferred format.

I completely disagree. As pointed out in another email, gnuplot input
scripts should be portable and not rely on some locale setting. I use
for example latin1 for gnuplot input scripts as this produces the
correct output in postscript but on the other hand my locale is set to
UTF-8. A file encoding has nothing to do with the user's locale.

-- 
Johannes

Re: can gnuplot do UTF-8 at all? [was: pm3d for emf terminal and point types]

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 13 December 2006 11:49 am, you wrote:
> > Except for the problem that TeX itself doesn't know about Unicode,
> > right?
>
> In LaTeX, without any problem:
> \usepackage[utf8]{inputenc}

Great! Learn something every day.
Apparently my word-processor (LyX) doesn't know about this,
but I can try editing the TeX template by hand.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: can gnuplot do UTF-8 at all? [was: pm3d for emf terminal and point types]

[Petr M. <mi...@ph...>]

> Except for the problem that TeX itself doesn't know about Unicode,
> right?

In LaTeX, without any problem:
\usepackage[utf8]{inputenc}

---
PM

Re: can gnuplot do UTF-8 at all? [was: pm3d for emf terminal and point types]

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 13 December 2006 04:23 am, Mojca Miklavec wrote:
>
> TeX-based pseudo-terminals support Unicode "without any problem".

Except for the problem that TeX itself doesn't know about Unicode,
right?  I gather that there are several recent TeX variants that do
handle it, though.  XeTeX seems promising, but maybe it's OSX only.
You mention ConTeXt also, which I still haven't found the time to
investigate, but at least it comes by default as part of the texmf
rpm I'm using.

> But one more question, which might be independent from the terminal
> in use. How does gnuplot calculate the label width when utf-8
> encoding is used?

This is done by the routine estimate_strlen() in term.c,
which basically just calls strlen().

So yes, you have a very good point there.  
It should probably use wcslen() instead.

But then we will have to wrap it with tests for locale support.
I wonder whether  #ifdef HAVE_LOCALE is sufficient to guarantee that
wcslen() is available, or whether the configuration script would
have to test for it specifically.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: pm3d for emf terminal and point types

[Mojca M. <moj...@gm...>]

On 12/13/06, Timoth=E9e Lecomte wrote:
> Dr. Johannes Zellner wrote:
> > This gives me the idea of rather having a terminal independent recode
> > option like
> >
> >     set recode "from encoding" "to encoding"
> >
> >
> I agree with Ethan: I would rather use the locale mechanism to determine
> the input encoding, deprecate the 'set encoding' command.
> Then I would make gnuplot depend on iconv, and each driver could use
> iconv facility to translate from the locale to its preferred format.

Just a small note: I have dozens of utf-8 encoded plt files, which I
compile on windows with locale settings declaring "cp1250" encoding
(and outputing to .tex files, where encoding has to be left untouched,
ie left in utf-8 or whatever encoding it's written in the .plt file).
If you're going to implement the conversion, I'll be happy about it,
but please make sure that it won't artificially spoil such cases and
try to do some unneeded conversion.

I think that reading from console and reading from a file has to be
treated differently. When reading from console respecting locale is
OK, but when reading from a file nothing should be assumed about the
encoding, otherwise it'll produce completely different results on
different computers. I want my .plt code to remain portable accross
different computers.

Allowing the user to specify input and output encoding still makes
sense in some cases.

Thanks,
    Mojca

Re: pm3d for emf terminal and point types

[<tim...@en...>]

Dr. Johannes Zellner wrote:
> ...
> well, I had a quick look at unicode for emf. Apparently emf can only do
> UTF-16 (little endian). Implementing this is really easy when using
> iconv to convert to UTF-16LE. The drawbacks are:
>
> 1. will loose some characters, e.g. when converting UTF-8 to UTF-16.
>  =20

UTF-8 and UTF-16 are just two differents encoding schemes for Unicode,=20
i.e. the same range of characters.
iconv can convert from UTF-8 to UTF-16 without losing anything.

> This gives me the idea of rather having a terminal independent recode
> option like
>
>     set recode "from encoding" "to encoding"
>
>  =20
I agree with Ethan: I would rather use the locale mechanism to determine=20
the input encoding, deprecate the 'set encoding' command.
Then I would make gnuplot depend on iconv, and each driver could use=20
iconv facility to translate from the locale to its preferred format.

Best regards,

Timoth=E9e

Re: pm3d for emf terminal and point types

[Ethan A M. <merritt@u.washington.edu>]

On Wednesday 13 December 2006 06:14, Dr. Johannes Zellner wrote:
> This gives me the idea of rather having a terminal independent recode
> option like
> 
>     set recode "from encoding" "to encoding"
> 
> which recodes all strings before passing them to the terminal driver.
> This would make it possible to have an encoding in the gnuplot input
> file which is different from what is expected by the terminal driver.
> In the emf case, the sequence of commands could then look like this:
> 
> a) for writing a 16 bit UTF-16LE emf file (input file is UTF-8 encoded):
> 
>     set recode "UTF-8" "UTF-16LE"
>     set term emf unicode # turn on 16 bit UTF-16 for emf
> 
> b) for writing a 8 bit latin1 emf file (input file is UTF-8 encoded):
> 
>     set recode "UTF-8" "LATIN1"
>     set term emf nounicode # turn OFF unicode --> write 1-byte iso-latin1
> 
> c) and using the same UTF-8 input file for postscript:
> 
>     set recode "UTF-8" "LATIN1"
>     set term post # which doesn't handle UTF-8
> 
> Any comments?

WAYYY too much trouble.  The whole point of locale support is so that
individual applications do not have to re-invent and re-implement [badly]
the same basic tasks of multi-language support.  We should rather be
looking for way to deprecate the existing encoding-related code and rely
on external mechanisms for internationalization.

Anyhow, the document you pointed to is not a spec for emf. It is 
desciption of several generation of Windows' API.  The limitation to 
UTF-16 is a Windows problem as I understand it, not anything in
particular to do with the "real" EMF.

I've done a little bit more Google-hunting for emf information.
I still haven't found a proper spec, but I have found enough info
to discourage me from ever being able to implement enhanced text mode.
The thing is, my main motivation for spiffing up emf was so that it
could be recommended to MSWord users, seeing as MSW is so unreliable
at importing eps files.  But apparently MSWord support for emf is also
rather poor.  The few text layout programs I have tracked down that
can put out emf come with warnings that the layout will be wrong 
when viewed in MSWord.  So I am reluctantly giving up on the idea.

Perhaps Vista will finally offer some truly standards-compliant
vector graphics support.  But I'm not holding my breath.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: pm3d for emf terminal and point types

[Dr. J. Z. <joh...@ze...>]

On Sat, Dec 09, 2006 at 09:37:51PM +0100, Johannes Zellner wrote:
> On Thu, Dec 07, 2006 at 09:26:17AM -0800, Ethan Merritt wrote:
> > On Thursday 07 December 2006 03:42 am, Dr. Johannes Zellner wrote:
> > >
> > > - I just implemented pm3d for emf which was really easy, as
> > > everything was already prepared.
> > > - I implemented for the emf terminal the point types as suggested in
> > >   term/README.
> > >
> > > is it ok to commit these changes to CVS?
> > 
> > Sound good to me.
> > 
> > Do you understand emf well enough to add enhanced text mode
> > support as well?  I have never found decent emf documentation,
> > and so have not been able to figure out how to trigger some
> > of the necessary operations.
> > 
> > Another item on my emf wishlist is allowing UTF-8 character sets.
> > If I understand the comments in the code correctly, it used to
> > allow this but someone decided to revert it to handle single byte
> > encodings only.  It's not clear to me whether this was intended
> > to fix a known problem, or was done for some other reason.
> 
> I don't understand emf at all ;-)
> But I was smart enough to understand the existing code in emf.trm.
> 
> UTF-8 would be nice IMHO as well as some sort of enhanced text.
> I found
> 
>     http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnargdi/html/msdn_enhmeta.asp
> 
> a 13 year old techical article from microsoft. Maybe the file emfwr.cxx
> from openoffice could also serve as documentation of the format. I will
> very likely not have the time to do any coding myself.

well, I had a quick look at unicode for emf. Apparently emf can only do
UTF-16 (little endian). Implementing this is really easy when using
iconv to convert to UTF-16LE. The drawbacks are:

1. will loose some characters, e.g. when converting UTF-8 to UTF-16.

2. would it work on windows? The manual page for iconv says that it
conforms to POSIX.1-2001.

3. needs some option to tell the emf driver which conversion should took
place, e.g. something like

    set term emf unicode recodefrom "UTF-8"

which switches on UTF-16LE emf output and and should recode strings from
UTF-8 to UTF-16LE.

This gives me the idea of rather having a terminal independent recode
option like

    set recode "from encoding" "to encoding"

which recodes all strings before passing them to the terminal driver.
This would make it possible to have an encoding in the gnuplot input
file which is different from what is expected by the terminal driver.
In the emf case, the sequence of commands could then look like this:

a) for writing a 16 bit UTF-16LE emf file (input file is UTF-8 encoded):

    set recode "UTF-8" "UTF-16LE"
    set term emf unicode # turn on 16 bit UTF-16 for emf

b) for writing a 8 bit latin1 emf file (input file is UTF-8 encoded):

    set recode "UTF-8" "LATIN1"
    set term emf nounicode # turn OFF unicode --> write 1-byte iso-latin1

c) and using the same UTF-8 input file for postscript:

    set recode "UTF-8" "LATIN1"
    set term post # which doesn't handle UTF-8

Any comments?

-- 
Johannes

Re: can gnuplot do UTF-8 at all? [was: pm3d for emf terminal and point types]

[Mojca M. <moj...@gm...>]

On 12/10/06, Ethan A Merritt wrote:
> On Sunday 10 December 2006 04:56, Dr. Johannes Zellner wrote:
> > On Thu, Dec 07, 2006 at 09:26:17AM -0800, Ethan Merritt wrote:
> > > Another item on my emf wishlist is allowing UTF-8 character sets.
> >
> > btw.: Can any terminals do UTF-8 at all?
>
> - svg and wxt use UTF-8 by default
> - libgd (used for png/jpeg/gif) uses UTF-8 by default if it is present
>   in the current font.
>         set term png font "arialuni"
> - x11 uses UTF-8 so long as you put it in multi-byte mode and specify
>   a suitable font:
>         set term x11 font "mbfont:sazanami mincho,vera,20"
> - The PostScript language itself is, so far as I know, not capable
>   of handling multi-byte encodings. So we're out of luck there.
>   However, I think Harald Harders has a patch for post.trm that
>   reencodes the single code page corresponding to the UTF-8 values
>   for latin1 characters. That would at least get you the umlauts
>   and accents.
>
> I am not sure about other terminal types such as pdf, win and aquaterm.

TeX-based pseudo-terminals support Unicode "without any problem".

I just tried the behaviour on windows (I never really bothered since I
only use it for viewing functions, for the final result I always use
ConTeXt, where unicode works "out-of-the-box"). Results:

a) when typing non-latin characters directly into "console window",
they are displayed wrong in the terminal window, but work OK on the
plot. However, these seem to be cp1250-encoded strings.

b) I created a utf-8 encoded file. On the plot the characters are
displayed as two characters, but to be honest: gnuplot doesn't know
that the file is utf-8 encoded and interprets it as cp1250 encoded. I
have no idea how to tell gnuplot that I would like to use utf-8
encoded files.

Does anyone still develop the windows terminal? It seems to me as if
the development would have been pretty dead there.


But one more question, which might be independent from the terminal in
use. How does gnuplot calculate the label width when utf-8 encoding is
used? (For TeX-based terminals this is not that relevant since label
size is usually calculated wrongly anyway because of the used control
sequences.)

Thanks,
    Mojca

Re: can gnuplot do UTF-8 at all? [was: pm3d for emf terminal and point types]

[Ethan M. <merritt@u.washington.edu>]

On Sunday 10 December 2006 11:17 pm, Dr. Johannes Zellner wrote:
>
> 1. set term x11 font
> "mbfont:-efont-fixed-medium-r-normal-*-*-160-*-*-c-*-iso10646-1"
> doesn't display all unicode characters correctly, but the specified
> font is a perfectly valid unicode font. I left 'encoding' untouched.

I don't have that font, so I can't experiment directly.
But based on similar full names for other fonts, I think you must
change that -c- to -*-
As you show below, the easiest thing to let everything default
but the face name.

> 2. set term x11 font "mbfont:efont,14"
> works and displays all (unicode) characters correctly. But it makes
> plotting REALLY slow.  Try to rotate some 3d splot interactively,
> e.g. 'splot x*y w l' with the above font option and compare it when
> having a font spec like "9x15".

Yes, it is slow.  Exactly how slow probably depends on exactly which
version of the X libaries you are using.  On my newer machines it is
not so bad; I'm not sure how much of that is newer software and how
much is faster hardware.

> Any comments on these?

This mechanism uses the generic X11 libraries, which as you
discovered are not very efficient at handling multi-byte characters.
I really don't know why.

Several projects have implemented much cleaner handling of
multi-byte characters on top of X11.  The most relevant of these
is pango.  Pango on top of X works much more smoothly than the
native X support, although it is still a bit slow.
The use of pango is half of what makes the new wxt terminal so
nice, and why I have switched over to wxt from x11 for daily use.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: can gnuplot do UTF-8 at all? [was: pm3d for emf terminal and point types]

[Dr. J. Z. <joh...@ze...>]

On Sun, Dec 10, 2006 at 09:10:08AM -0800, Ethan A Merritt wrote:
> - x11 uses UTF-8 so long as you put it in multi-byte mode and specify
>   a suitable font:
> 	set term x11 font "mbfont:sazanami mincho,vera,20"

ok. seems like I missed some development here ;-)
But:

1. set term x11 font "mbfont:-efont-fixed-medium-r-normal-*-*-160-*-*-c-*-iso10646-1"
doesn't display all unicode characters correctly, but the specified font
is a perfectly valid unicode font. I left 'encoding' untouched.

2. set term x11 font "mbfont:efont,14" 
works and displays all (unicode) characters correctly. But it makes
plotting REALLY slow.  Try to rotate some 3d splot interactively, e.g.
'splot x*y w l' with the above font option and compare it when having a
font spec like "9x15".

To summarize: option 1 is fast but doesn't work, option 2 works but is
really slow.

Any comments on these?

-- 
Johannes

Re: splot question

[Daniel J S. <dan...@ie...>]

Attached is what I get from the data and commands.  Is this more of what you are looking for?

Dan


Justin Hart wrote:
> I'm having the worst trouble with splot.  It's happened before, but I
> mistook what was happening for a problem with the program generating
> the data.
> 
> The plots generated have inappropriate waves in them.  The data
> generating this plot should all be strictly positive on all axes.
> 
> Can anybody help me?
> 
> Here is all of the pertainent data.
> 
> <img src="http://i55.photobucket.com/albums/g139/nitsujtpu/cvdv.png"/>
> 
> But, this is the data that formed it!
> 
> 1	25	63.6
> 1	50	140.6
> 1	75	236.6
> 1	100	354.8
> 2	25	89.6
> 2	50	143.2
> 2	75	263.8
> 2	100	321
> 3	25	96.8
> 3	50	153.4
> 3	75	276.2
> 3	100	1092.8
> 3.2	25	75.6
> 3.2	50	255
> 3.2	75	610.6
> 3.2	100	1071.4
> 4	25	131.2
> 4	50	4998.6
> 4	75	514
> 4	100	1354.33333333333
> 4.2	25	113.4
> 4.2	50	15614.8
> 4.2	75	8657
> 4.2	100	1851.5
> 4.4	25	269.5
> 4.4	50	4274.66666666667
> 4.4	75	1552
> 4.4	100	1350
> 
> Here is my script.
> 
> set title "Decisions across the phase transition"
> set xlabel "Clauses / Variables"
> set ylabel "Variables"
> set zlabel "Decisions"
> set term gif
> set output "cvdv.gif"
> set parametric
> set dgrid3d 100,100,1
> set data style lines
> set hidden3d
> splot "pt_v_data_avg_sat.txt"
> replot
> 
> The waviness can't be there.
> 


-- 

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/

splot question

[Justin H. <jus...@gm...>]

I'm having the worst trouble with splot.  It's happened before, but I
mistook what was happening for a problem with the program generating
the data.

The plots generated have inappropriate waves in them.  The data
generating this plot should all be strictly positive on all axes.

Can anybody help me?

Here is all of the pertainent data.

<img src="http://i55.photobucket.com/albums/g139/nitsujtpu/cvdv.png"/>

But, this is the data that formed it!

1	25	63.6
1	50	140.6
1	75	236.6
1	100	354.8
2	25	89.6
2	50	143.2
2	75	263.8
2	100	321
3	25	96.8
3	50	153.4
3	75	276.2
3	100	1092.8
3.2	25	75.6
3.2	50	255
3.2	75	610.6
3.2	100	1071.4
4	25	131.2
4	50	4998.6
4	75	514
4	100	1354.33333333333
4.2	25	113.4
4.2	50	15614.8
4.2	75	8657
4.2	100	1851.5
4.4	25	269.5
4.4	50	4274.66666666667
4.4	75	1552
4.4	100	1350

Here is my script.

set title "Decisions across the phase transition"
set xlabel "Clauses / Variables"
set ylabel "Variables"
set zlabel "Decisions"
set term gif
set output "cvdv.gif"
set parametric
set dgrid3d 100,100,1
set data style lines
set hidden3d
splot "pt_v_data_avg_sat.txt"
replot

The waviness can't be there.

-- 
Justin W. Hart

Re: can gnuplot do UTF-8 at all?

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 10 December 2006 09:53, Petr Mikulik wrote:
> 
> There is a file "ps2utf8.ps" at
>         http://djvu.cvs.sourceforge.net/djvu/gsdjvu/

That particular file contains two translation tables. 
One is for the UTF-8 encodings of Adobe's standard set of glyphs.
That gets you something like 1000 characters, I think 
(the table is ~300 lines with about 3-4 mappings per line).
That's nice, but it is only a small part of the total
Unicode/UTF-8 character space.

The second table is a mapping from TeX to Adobe, which is also
interesting but has nothing directly to do with UTF-8.

> It looks as it could use utf8 strings in postscripts, but maybe it requires
> djvu-enabled ghostscript? Or is it something different?

I only know what I could glean from their web site, but it looks to me that
djvu doesn't know anything about encodings or characters.  It is a
compression scheme for scanned images. I think (but here I'm speculating
wildly) it benefits from repeated high contrast regions in the scanned image.
If you scan text, typically there are many copies of the same character glyph.
The compression scheme doesn't care what the character is, just that it
appears more than once.  But I could be totally misunderstanding.

> There are also "u2ps" and "enscript" program that can handle UTF-8 files, 
> how do they do it?

I have used enscript on my machines to print from Japanese UTF-8 documents.
It sort of works, but not reliably.  Every version upgrade to any piece
breaks the whole process.  I have one 'magic' set of compatible versions
that does OK, but it I have not been able to reproduce this success with
more recent versions.
In particular I have not been able to make it work at all with 
ghostscript 8.x   If someone could help me with that, I'd be gratefull!

Anyhow, my limited understanding is that it requires you to identify one
or more existing single-byte encoded fonts that contain the characters
needed by your document. Then it creates a document-specific translation
table that is applied character-by-character to map your original 
character encodings with some equivalent in that specific non-UTF8 font.

This is similar to the approach used by the translation table in the
URL you referenced, except of course that the portion of the Unicode
character space is entirely different.

It is also similar to what Harald Harders did for UTF-8 encoding of the
isolatin1 character set (patchset #1252232).  The problem is, this doesn't
generalize easily to arbitrary Unicode code points.  Even aside from the
issue of supported non-isolatin character languages, we would need to 
handle the Unicode pages for various math and technical symbols. 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: can gnuplot do UTF-8 at all?

[Petr M. <mi...@ph...>]

> btw.: Can any terminals do UTF-8 at all?

There is a file "ps2utf8.ps" at
        http://djvu.cvs.sourceforge.net/djvu/gsdjvu/
It looks as it could use utf8 strings in postscripts, but maybe it requires
djvu-enabled ghostscript? Or is it something different?

There are also "u2ps" and "enscript" program that can handle UTF-8 files, 
how do they do it?

---
PM

Re: can gnuplot do UTF-8 at all? [was: pm3d for emf terminal and point types]

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 10 December 2006 04:56, Dr. Johannes Zellner wrote:
> On Thu, Dec 07, 2006 at 09:26:17AM -0800, Ethan Merritt wrote:
> > Another item on my emf wishlist is allowing UTF-8 character sets.
> 
> btw.: Can any terminals do UTF-8 at all?

- svg and wxt use UTF-8 by default
- libgd (used for png/jpeg/gif) uses UTF-8 by default if it is present
  in the current font.
	set term png font "arialuni"
- x11 uses UTF-8 so long as you put it in multi-byte mode and specify
  a suitable font:
	set term x11 font "mbfont:sazanami mincho,vera,20"
- The PostScript language itself is, so far as I know, not capable
  of handling multi-byte encodings. So we're out of luck there.
  However, I think Harald Harders has a patch for post.trm that 
  reencodes the single code page corresponding to the UTF-8 values
  for latin1 characters. That would at least get you the umlauts
  and accents.

I am not sure about other terminal types such as pdf, win and aquaterm.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: can gnuplot do UTF-8 at all? [was: pm3d for emf terminal and point types]

[<tim...@en...>]

Dr. Johannes Zellner wrote:
> On Thu, Dec 07, 2006 at 09:26:17AM -0800, Ethan Merritt wrote:
>  =20
>> Another item on my emf wishlist is allowing UTF-8 character sets.
>>    =20
>
> btw.: Can any terminals do UTF-8 at all? -- I took the habit of writing
> my gnuplot input files with latin1 encoding as I want to get special
> characters (as german Umlauts) displayed correctly in postscript.
> I couldn't get UTF-8 working in neither postscript nor X11. My locale i=
s
> set to UTF-8.
>
> Any ideas?
>  =20
The wxWidgets (wxt) terminal can do it. Its default behaviour is to take=20
the encoding from your locale. So when your locale is UTF-8 (mine is=20
fr_FR.UTF-8 for example), the utf-8 characters that you give on input=20
will be drawn properly.

Best regards,

Timoth=E9e

can gnuplot do UTF-8 at all? [was: pm3d for emf terminal and point types]

[Dr. J. Z. <joh...@ze...>]

On Thu, Dec 07, 2006 at 09:26:17AM -0800, Ethan Merritt wrote:
> Another item on my emf wishlist is allowing UTF-8 character sets.

btw.: Can any terminals do UTF-8 at all? -- I took the habit of writing
my gnuplot input files with latin1 encoding as I want to get special
characters (as german Umlauts) displayed correctly in postscript.
I couldn't get UTF-8 working in neither postscript nor X11. My locale is
set to UTF-8.

Any ideas?

-- 
Johannes

Re: ***[Possible UCE]*** Re: direction field in gnuplot

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Bröker wrote:

> can all be done easily using gnuplot.  These direction fields are, 
> indeed, just a subclass of vector fields (limited by all vectors being 
> unit-length).  gnuplot won't do numerical integration because gnuplot is 
> a plotting program, not a number crunching engine.

There are some examples of DIY integration using gnuplot function features somewhere in the demos as well.  They were recently updated for better accuracy.  Not the most generic, perhaps, but it's possible.

Dan

Re: 4.2rc2: "set style fill transparent" does not work

[Ethan A M. <merritt@u.washington.edu>]

On Friday 08 December 2006 13:32, Wagner Meira Jr wrote:
> Hi all,
> 
> I just downloaded and compiled 4.2rc2. It is running OK.
> 
> I understood that it supports transparent 2D figures as the
> transparent.2.gnu demo shows. 

Er, no.
Transparent fill is one of the next generation features introduced
to the cvs source tree after we froze the code base for the release
of 4.2

> Am I missing something?

You must have found the demo on the demo page for the cvs version
	http://gnuplot.sourceforge.net/demo_4.3/
rather than on the demo page for the 4.2 release
	http://gnuplot.sourceforge.net/demo_4.2/

The 4.2 and cvs (4.3) versions have not yet diverged very far, but
development goes on and new features will continue to be added.
So far the cvs tree has gained:
	transparent fill
	iteration within a plot command
	the "with rgbimage" plot style work in 2D and 3D for all terminals
		that support RGB, even if they don't support "with image" 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: 4.2rc2: "set style fill transparent" does not work

[Wagner M. Jr. <me...@dc...>]

Hans-Bernhard Br=F6ker escreveu:
> Wagner Meira Jr wrote:
>
>> I understood that it supports transparent 2D figures as the
>> transparent.2.gnu demo shows.=20
>
> It supports this on some terminal drivers.
Great!
>
>> Am I missing something?
>
> You missed telling us which terminal driver you tried it on.
>
>
I need to generate eps files. A typical figure is that one where
there are overlaping normal filled curves with transparency:

http://gnuplot.sourceforge.net/demo_4.1/transparent.2.gnu

Thanks,

Wagner

Re: direction field in gnuplot

[<HBB...@t-...>]

Leo wrote:

> Jaime E. Villate replied on the issue of direction field and gnuplot
> in maxima here:
> http://thread.gmane.org/gmane.comp.mathematics.maxima.general/13159/focus=13255

With all due respect, I'm not sure it's worth arguing with somebody who 
judges a web-page showing three plots only by the contents of the first. 
  Yes, there's is a plot of equipotential lines in the vectors.dem.  No, 
that doesn't disprove gnuplot's ability to do direction fields.

The actual direction fields to be seen in the referenced URL:

> http://maxima.sourceforge.net/docs/manual/en/maxima_63.html#SEC228.

can all be done easily using gnuplot.  These direction fields are, 
indeed, just a subclass of vector fields (limited by all vectors being 
unit-length).  gnuplot won't do numerical integration because gnuplot is 
a plotting program, not a number crunching engine.  But if maxima cared 
doing the integration and handing out the resulting curve as another 
data set, it's not at all hard to generate that plot using gnuplot. 
With maxima in the background and the more recent additions to mouse 
interaction in gnuplot, I expect someone could even imitate that "draw a 
field line by picking a point on it" gimmick.

Re: 4.2rc2: "set style fill transparent" does not work

[<HBB...@t-...>]

Wagner Meira Jr wrote:

> I understood that it supports transparent 2D figures as the
> transparent.2.gnu demo shows. 

It supports this on some terminal drivers.

> Am I missing something?

You missed telling us which terminal driver you tried it on.