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

Re: BACKWARDS_COMPATIBILITY and BACKWARDS_COMPATIBLE

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

> How much of the old syntax does Octave still use?  Maybe we could
> continue to allow "set no<whatever>" even after disabling some of
> the more problematic items like bare integers (no keyword) for
> line types and point types.

It doesn't use "unset" at all, or maybe only in some newer scripts with 
pm3d/images.

---
PM

Re: Win32 COM question

[BBands <bb...@ya...>]

--- Hans-Bernhard Bröker <HBB...@t-...> wrote:
> In a word: no.  

I was afraid that was the case.

> pgnuplot is what you get, and I assume it's already used 
> by existing Python packages which provide interfaces to gnuplot.

Correct for gunplot.py. I'd thought to try a new implementation as gnuplot.py
is mostly unmaintained these days.

Happy Holidays to all!

    jab

John Bollinger, CFA, CMT
www.BollingerBands.com

If you advance far enough, you arrive at the beginning.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Win32 COM question

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

BBands wrote:
> Is is possible to use COM with wgnuplot? For example, using Python to produce
> graphs.

In a word: no.  pgnuplot is what you get, and I assume it's already used 
by existing Python packages which provide interfaces to gnuplot.

Win32 COM question

[BBands <bb...@ya...>]

Is is possible to use COM with wgnuplot? For example, using Python to produce
graphs.

     jab

John Bollinger, CFA, CMT
www.BollingerBands.com

If you advance far enough, you arrive at the beginning.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: BACKWARDS_COMPATIBILITY and BACKWARDS_COMPATIBLE

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

On Friday 15 December 2006 01:46 am, Petr Mikulik wrote:
> I've just noticed many error messages from gnuplot running under
> Octave ... that's because "set nopolar", "set notics" etc does no
> longer work even though the backwards compatibility is enabled by
> default...
>
> The bug: there is a mix of both keywords BACKWARDS_COMPATIBILITY and
> BACKWARDS_COMPATIBLE in the source code but it should be the same.
>
> Someone knows why/when/where this change happened?
> I guess it should be enough to fix the constant name in configure.in.

Yes, sorry. My fault.  Although the whole idea was to uncover places
that the old syntax was still being used, and I guess it succeeded
at doing so.  I've fixed the spelling in configure.in

How much of the old syntax does Octave still use?  Maybe we could
continue to allow "set no<whatever>" even after disabling some of
the more problematic items like bare integers (no keyword) for
line types and point types.


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

BACKWARDS_COMPATIBILITY and BACKWARDS_COMPATIBLE

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

I've just noticed many error messages from gnuplot running under Octave 
... that's because "set nopolar", "set notics" etc does no longer work 
even though the backwards compatibility is enabled by default...

The bug: there is a mix of both keywords BACKWARDS_COMPATIBILITY and 
BACKWARDS_COMPATIBLE in the source code but it should be the same.

Someone knows why/when/where this change happened?
I guess it should be enough to fix the constant name in configure.in.

---
PM

Re: encodings -- Re: pm3d for emf ...

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

> > No, we use it -- there are so many Czech encodings :-))
>  "The nice thing about standards is that there are 
>   so many of them to choose from"  :-)
> 
> > If you get a file with cp852 and run it through gnuplot, the
> > postscript terminal will render the correct output.
> 
> That may be true for a script that is entirely self-contained, but
> it is not true in general.  If the script reads data or any other
> information from my local machine, that data will not be in cp852
> and it will be incorrectly described in the output stream.

Then you won't use "set term encoding cp852", but either none or the correct 
one. That's my own experience.

I have never tried to use "plot ... with labels" with 8/16bit labels.

---
PM

TeX [was: can gnuplot do UTF-8 at all?]

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

On 12/13/06, Ethan Merritt wrote:
> 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?

TeX or pdfTeX don't natively support it, but TeX is powerful enough
that macro package can imetate utf-8 to some degree. As Petr wrote,
inputenc package does that for you.

However, XeTeX and the new version of pdfTeX (not officially released
yet; also known as luatex) natively support Unicode and
OpenType/TrueType/AAT fonts installed on the system (read as: you
don't need to hack TeX to get the most fancy fonts any more, finally
good support for arabic, left to right and other obscure scripts). But
that's not something that would make any difference to the way how
gnuplot works. (Existing terminals probably work ok with XeTeX as
well.)

> I gather that there are several recent TeX variants that do
> handle it, though.  XeTeX seems promising, but maybe it's OSX only.

Which OS are you using (which distribution)? Since May it works on
Linux and since Summer on Windows as well. (There are packages for
SuSE and Ubuntu, you can install on other flavours of linux from
source.) But that's too offtopic for the list and probably not
relevant - utf-8 works under LaTeX with the good old pdfTeX as well.

> 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.

You can take a look at http://www.nibua-r.org/ConTeXt/PhD/.
On page 81 (numbered 65) or 85 of the thesis there are some sample
graphs done with gnuplot & ConTeXt.

The only problem with the default distribution is that ConTeXt is
usually old (2002) (Debian has just made a big step forward and their
package is the only one that I know which includes recent/decent
ConTeXt) and tetex is not being maintained any more either, but one
can in theory only replace the old files with the new ones from
www.pragma-ade.com and regenerate formats. (Lyx doesn't support
ConTeXt.)

I would indeed be very grateful if someone could try the context
terminal out once in the future. There's really no hurry since there
will be no 4.4 release for a while, but I would like to get some
feedback from the gnuplot team as well.

Mojca

Re: "set term" between plots

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

On 12/14/06, Ethan Merritt wrote:
> On Wednesday 13 December 2006 03:46 pm, Mojca Miklavec wrote:
> >
> > this is not problematic for "clever users", but it might sometimes
> > lead to unexpected results.
> >
> > Suppose that the user says:
> >
> > set output "something.ps"
> > set term post (or some other terminal)
> > plot sin(x)
> > plot cos(x)
> > set term post color
> > plot erf(x)
> >
> > png & friends simply overwrite the existing image file, but
> > PostScript driver writes out a file that could probably be considered
> > "broken".
>
> I take your point, although in this particular example I am
> not sure what the user intended to happen.  You don't need to
> change the terminal properties in order to specify a colored
> line as opposed to a black line.

That was just a "stupid example".

> Nevertheless, we have discussed the general issue before.
> The outcome at that time was to create a new command,
> "set termoption", that allows you to change some property of
> the current terminal without closing and re-opening it.
>
> So if you want to change the default font, for example,
> you can say
>
>   set termoption font "Newfont,newsize"
>
> That has the double advantage of not closing and re-opening the
> terminal, and being compatible with all terminals rather than
> being specific to the one particular terminal you are currently
> using.  Better for scripting.
>
> That said, not a whole lot of attention has been paid to
> extending the number of terminal properties that can be
> changed using this command.  If you think being able to toggle
> the default line colors between color and mono would be useful,
> feel free to code up a patch that adds those two properties to
> the list of options accepted by 'set termoption'.
>
> In the case of PostScript, you could have it insert the command:
>  /Color true def
> into the output stream
>
> Be aware, however, that this will make it so that individual plots
> within a postscript file containing multiple pages will now be
> sensitive to the order of viewing.  That is, if you call up the
> file in ghostview and step through the plots backwards, or in
> random order, they will inherit the properties of the previous
> plot viewed rather than the previous plot in order of creation.

Some changes might make sense between plots and some do not, but that
highly depends on the terminal used and there must be a good reason to
implement any specific feature such as "enable change of plot size"
since almost all the terminals have to be changed in that case. My
point was not "gnuplot needs a new feature", but rather "gnuplot might
produce broken files" without any warning and that should be fixed.

I tried the pdf terminal now and it ignores anything written before
"set term pdf", so the example

set output "something.pdf"
set term pdf
plot erf(x)
set term pdf enhanced (just as an example)
plot cos(x)
plot sin(x)

would result in two pages with sin and cos, while PostScript and
TeX-based terminals would include all the three plots in a
kind-of-broken format. Wouldn't it be more consistent if the file
would be deleted/opened again for writing after "set term"?
(functionally better alternative would be to implement a new function
inside each terminal to parse & handle additional settings, but I'm
not capable of implementing that for all the terminals)

Or is there some better way to reopen a file inside term->init and
start writing a new file from scratch?

Thanks,
     Mojca

Re: "set term" between plots

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

On Wednesday 13 December 2006 03:46 pm, Mojca Miklavec wrote:
>
> this is not problematic for "clever users", but it might sometimes
> lead to unexpected results.
>
> Suppose that the user says:
>
> set output "something.ps"
> set term post (or some other terminal)
> plot sin(x)
> plot cos(x)
> set term post color
> plot erf(x)
>
> png & friends simply overwrite the existing image file, but
> PostScript driver writes out a file that could probably be considered
> "broken".

I take your point, although in this particular example I am
not sure what the user intended to happen.  You don't need to
change the terminal properties in order to specify a colored
line as opposed to a black line.

Nevertheless, we have discussed the general issue before.
The outcome at that time was to create a new command,
"set termoption", that allows you to change some property of
the current terminal without closing and re-opening it.

So if you want to change the default font, for example, 
you can say

  set termoption font "Newfont,newsize"

That has the double advantage of not closing and re-opening the
terminal, and being compatible with all terminals rather than
being specific to the one particular terminal you are currently
using.  Better for scripting.

That said, not a whole lot of attention has been paid to 
extending the number of terminal properties that can be 
changed using this command.  If you think being able to toggle
the default line colors between color and mono would be useful,
feel free to code up a patch that adds those two properties to
the list of options accepted by 'set termoption'.

In the case of PostScript, you could have it insert the command:
 /Color true def
into the output stream

Be aware, however, that this will make it so that individual plots
within a postscript file containing multiple pages will now be 
sensitive to the order of viewing.  That is, if you call up the
file in ghostview and step through the plots backwards, or in 
random order, they will inherit the properties of the previous
plot viewed rather than the previous plot in order of creation.


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

"set term" between plots

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

Hello,

this is not problematic for "clever users", but it might sometimes
lead to unexpected results.

Suppose that the user says:

set output "something.ps"
set term post (or some other terminal)
plot sin(x)
plot cos(x)
set term post color
plot erf(x)

png & friends simply overwrite the existing image file, but PostScript
driver writes out a file that could probably be considered "broken".

"set term post" finishes the old file and writes the header of a "new
file" to the same document. I would expect gnuplot to either:
- do some changes between the two plots (change color setting in that
case) and then continue plotting with new settings (but that requires
heavy changes in terminal sources): so it would draw all the three
graphs
- start from scratch (overwrite the existing plot): so it would only draw erf(x)

I'm asking because my terminal would currently behave really strange
in such a situation. For the example above
- in one (standalone) mode it would only draw sin(x) and cos(x) and
exit (I can't do anything about it)
- in the other mode it would currently draw erf(x) and cos(x), both in
color; I can and would probably change it to draw erf(x) only, but I
still find that behaviour a bit confusing

Any suggestions?

Thanks,
    Mojca

Re: encodings -- Re: pm3d for emf ...

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

On Wednesday 13 December 2006 02:55 pm, Petr Mikulik wrote:
> No, we use it -- there are so many Czech encodings :-))
 "The nice thing about standards is that there are 
  so many of them to choose from"  :-)

> If you get a file with cp852 and run it through gnuplot, the
> postscript terminal will render the correct output.

That may be true for a script that is entirely self-contained, but
it is not true in general.  If the script reads data or any other
information from my local machine, that data will not be in cp852
and it will be incorrectly described in the output stream.


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

Re: Re: encodings -- Re: pm3d for emf ...

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

On 12/13/06, Petr Mikulik wrote:
> If old files don't have set encoding, then they are not portable anyway.

That's not necessary true. I have dozens of .tex files which look like:

\documentclass{article}
\usepackage[cp1250]{inputenc}
\pagestyle{empty}
\begin{document}
\input graph
\end{document}

Where "graph.tex" has been produced by cp1250-encoded .plt file (and
those files are fully portable and still backward-compatible; the main
problem with "backward compatibility" being the fact that I don't use
LaTeX any more ;).

I agree that encodings have to be improved in gnuplot, but please
don't break the old functionality too much.

For bitmap and PostScript terminals input/output encodings are very
important, but TeX-based ones have their own phylosophy. Trying to be
too clever when modifying their labels might unintentionally break
things.

Mojca

Re: encodings -- Re: pm3d for emf ...

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

> > If I take an older file from my OS/2 times with cp852, and pass it
> > through gnuplot, I expected there will be the same output. Not that
> > it will use UTF8 encoding of my Linux box. Same for files copied from
> > a current Windows box.
> 
> Then I am afraid you are out of luck.  You can only use an encoding
> that you have installed.  How can that possibly be any other way?
> If you send me a cp852 script, and I run it on my non-cp852 machines,
> how are they to magically figure out this mysterious encoding?

No, we use it -- there are so many Czech encodings :-))

If you get a file with cp852 and run it through gnuplot, the postscript 
terminal will render the correct output.

You have many encodings installed. Use e.g. kate or gedit and Menu -> 
Encoding and voila, you can edit file in any encoding.

> I agree with that part.  I'm trying to point out that we are not
> in that situation currently.  As it stands today, the encoding 
> information in the output file header is not guaranteed to match
> the actual file contents.

If someone intentionally breaks it...

> I think what you are asking for is that the gnuplot script itself
> be marked with an encoding.  That may be reasonable, and we could
> add that to the output of "save", but it wouldn't help older
> pre-existing scripts that don't have such a header record.

Only if 8bit chars are used. If old files don't have set encoding, then they 
are not portable anyway.

---
PM

Re: pm3d for emf terminal and point types

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

On Wed, Dec 13, 2006 at 02:11:01PM -0800, Ethan Merritt wrote:
> Huh? Neither λ nor μ is contained in the latin1 character set.

"man latin1" on my linux box shows µ.

> Are you sure your scripts are in latin1?  How do you type them in
> latin1 if your locale is set to UTF-8?  Remember that latin1 is
> isomorphous to Unicode code pages 0 and 1, so I am not sure you
> have tested a real distinction.

I'm sure. I tell my editor to use a specific encoding. In vim it's
'set fileencoding=latin1'. I bet there's a corresponding setting in
emacs.

> > A file encoding has nothing to do with the user's locale. 
> 
> A file's *claimed* encoding can be anything you tell it,
> but that does not guarantee that the contents actually match the
> claimed encoding.  That is what I see as the fatal flaw in gnuplot's
> current "set encoding" command.  It doesn't really change the 
> encoding for any terminal that I know of.  All it does is stick
> a header or other label in the output file that *claims* such-and-such
> an encoding is being used.
> 
> If I, sitting at a gnuplot session on my UTF-8 terminal, 
> type "set encoding cp852" and then type in a bunch of non-ascii
> characters, any output file I produce will be internally inconsistent.
> It will claim at the top that it is cp852, but the actual contents
> will be UTF-8.   That's why I want to deprecate the "set encoding"
> command.  It does not really set the encoding, it just provides
> instructions to some other program, and those instructions may or
> may not be correct. It would be better to enforce consistency
> by specifying the actual current encoding in the output file,
> as taken from the current locale.

that's why I suggested

    set recode "from encoding" "to encoding"

which would internally be implemented by iconv() probably.

-- 
Johannes

Re: encodings -- Re: pm3d for emf ...

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

On Wednesday 13 December 2006 02:29 pm, Petr Mikulik wrote:
>
> If I take an older file from my OS/2 times with cp852, and pass it
> through gnuplot, I expected there will be the same output. Not that
> it will use UTF8 encoding of my Linux box. Same for files copied from
> a current Windows box.

Then I am afraid you are out of luck.  You can only use an encoding
that you have installed.  How can that possibly be any other way?
If you send me a cp852 script, and I run it on my non-cp852 machines,
how are they to magically figure out this mysterious encoding?

> Gnuplot should behave like TeX or HTML files for ages: belive the
> inputenc or codepage written in the file header.

I agree with that part.  I'm trying to point out that we are not
in that situation currently.  As it stands today, the encoding 
information in the output file header is not guaranteed to match
the actual file contents.

I think what you are asking for is that the gnuplot script itself
be marked with an encoding.  That may be reasonable, and we could
add that to the output of "save", but it wouldn't help older
pre-existing scripts that don't have such a header record.


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

encodings -- Re: pm3d for emf ...

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

> If I, sitting at a gnuplot session on my UTF-8 terminal, type "set 
> encoding cp852" and then type in a bunch of non-ascii characters, any 
> output file I produce will be internally inconsistent. It will claim at 
> the top that it is cp852, but the actual contents will be UTF-8.  That's 
> why I want to deprecate the "set encoding" command.  It does not really 
> set the encoding, it just provides instructions to some other program, and 
> those instructions may or may not be correct. It would be better to 
> enforce consistency by specifying the actual current encoding in the 
> output file, as taken from the current locale.


Then don't write this command if it is wrong.

If I take an older file from my OS/2 times with cp852, and pass it through 
gnuplot, I expected there will be the same output. Not that it will use UTF8 
encoding of my Linux box. Same for files copied from a current Windows box.

Gnuplot should behave like TeX or HTML files for ages: belive the inputenc 
or codepage written in the file header.
---
PM

Re: pm3d for emf terminal and point types

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

On Wednesday 13 December 2006 12:48 pm, Dr. Johannes Zellner wrote:
> On Wed, Dec 13, 2006 at 07:19:12PM +0100, Timoth=C3=A9e Lecomte wrote:
> > Dr. Johannes Zellner wrote:
> >
> > 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.

Timoth=C3=A9e is correct. UTF-8 and UTF-16 are alternative schemes to index
exactly the save Unicode tables. So they both encode exactly the same
range of characters.

> I believe that =C2=B5 and =CE=BB (also =CF=83) are implemented both in UT=
=46-8 and
> UTF-16, but only =C2=B5 is implemented in latin1 so it makes sense to
> implement more than latin1 for the emf terminal.

Huh? Neither =CE=BB nor =CE=BC is contained in the latin1 character set.
There's =C3=9F, which looks sort of beta-ish but isn't really. That's as
close as you can get to Greek characters in latin1.

> 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.=20

Are you sure your scripts are in latin1?  How do you type them in
latin1 if your locale is set to UTF-8?  Remember that latin1 is
isomorphous to Unicode code pages 0 and 1, so I am not sure you
have tested a real distinction.

> A file encoding has nothing to do with the user's locale.=20

A file's *claimed* encoding can be anything you tell it,
but that does not guarantee that the contents actually match the
claimed encoding.  That is what I see as the fatal flaw in gnuplot's
current "set encoding" command.  It doesn't really change the=20
encoding for any terminal that I know of.  All it does is stick
a header or other label in the output file that *claims* such-and-such
an encoding is being used.

If I, sitting at a gnuplot session on my UTF-8 terminal,=20
type "set encoding cp852" and then type in a bunch of non-ascii
characters, any output file I produce will be internally inconsistent.
It will claim at the top that it is cp852, but the actual contents
will be UTF-8.   That's why I want to deprecate the "set encoding"
command.  It does not really set the encoding, it just provides
instructions to some other program, and those instructions may or
may not be correct. It would be better to enforce consistency
by specifying the actual current encoding in the output file,
as taken from the current locale.
=20


=2D-=20
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]

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

On Wednesday 13 December 2006 12:56 pm, Dr. Johannes Zellner wrote:
> 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?

Yes, it does.  That's the whole point.  It calculates the length
based on the current locale setting in the program.  This may or
may not match your default locale; the program is free to change
its context to any locale you have available.

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

Re: pm3d for emf terminal and point types

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

Petr Mikulik a =E9crit :
>>> It won't be portable.
>>>  =20
>>>      =20
>> Why ? GNU iconv is available for Unix, Windows and OS/2: it looks quit=
e
>> portable to me.
>>    =20
>
> It's not a problem of the program, but of the contents of script files.=
 Ah,=20
> actually, I mean that command "set encoding" cannot be removed, but the=
=20
> default could change to "set encoding locale".
>  =20

Ok, I'm all for that.

Best regards,

Timoth=E9e
> ---
> PM
>  =20

Re: pm3d for emf terminal and point types

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

> > It won't be portable.
> >   
> Why ? GNU iconv is available for Unix, Windows and OS/2: it looks quite
> portable to me.

It's not a problem of the program, but of the contents of script files. Ah, 
actually, I mean that command "set encoding" cannot be removed, but the 
default could change to "set encoding locale".

---
PM

Re: pm3d for emf terminal and point types

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

Petr Mikulik a =E9crit :
>> Then I would make gnuplot depend on iconv, and each driver could use
>> iconv facility to translate from the locale to its preferred format.
>>    =20
>
> It won't be portable.
>  =20
Why ? GNU iconv is available for Unix, Windows and OS/2: it looks quite=20
portable to me.
> And even neither one particular system! In Windows CZ, console is using=
=20
> codepage 852, while GUI apps are using codepage 1250. One can hardly be=
lieve=20
> such a stupidity... remembering both are broken ISO-8859-2.
>  =20
That's precisely why we need to do some conversion from cp-* to the=20
terminal encoding.

Timoth=E9e

Re: pm3d for emf terminal and point types

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

Dr. Johannes Zellner a =C3=A9crit :
> On Wed, Dec 13, 2006 at 07:19:12PM +0100, Timoth=C3=A9e Lecomte wrote:
>  =20
>> Dr. Johannes Zellner wrote:
>>    =20
>>> ...
>>> 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
>>>      =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.
>>    =20
>
> 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 '=C3=A4=C3=B6=C3=BC =C3=84=C3=96=C3=9C =C3=9F =E2=82=82=C2=
=B2=E2=82=83=C2=B3=E2=82=84=E2=81=B4=E2=82=85=E2=81=B5=E2=82=86=E2=81=B6=E2=
=82=87=E2=81=B7=E2=82=88=E2=81=B8=E2=82=89=E2=81=B9 =C2=BD =C2=BE =C2=BC =
=E2=82=AC'
>
> (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.
>  =20
According to wikipedia: "In computing, UTF-16 (16-bit Unicode=20
Transformation Format) is a variable-length character encoding for=20
Unicode, capable of encoding the entire Unicode repertoire." So, if=20
superscript 1 to 9 are defined in Unicode, they should be available in=20
UTF-16. As usual, there may be a bug or a limitation in some part of the=20
conversion process...

> I believe that =C2=B5 and =CE=BB (also =CF=83) are implemented both in =
UTF-8 and
> UTF-16, but only =C2=B5 is implemented in latin1 so it makes sense to
> implement more than latin1 for the emf terminal.
>  =20
Agreed.
>  =20
>>> This gives me the idea of rather having a terminal independent recode
>>> option like
>>>
>>>     set recode "from encoding" "to encoding"
>>>
>>>  =20
>>>      =20
>> I agree with Ethan: I would rather use the locale mechanism to determi=
ne=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.
>>    =20
>
> 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.
>  =20
Ok, I spoke too early there about the locale thing. But the idea to use=20
iconv remains.

Best regards,

Timoth=C3=A9e

Re: pm3d for emf terminal and point types

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

> Then I would make gnuplot depend on iconv, and each driver could use
> iconv facility to translate from the locale to its preferred format.

It won't be portable.

And even neither one particular system! In Windows CZ, console is using 
codepage 852, while GUI apps are using codepage 1250. One can hardly believe 
such a stupidity... remembering both are broken ISO-8859-2.

---
PM

Re: pm3d for emf terminal and point types

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

> 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!

And for OpenOffice.org also. It does not support any other vectorial 
graphics format I think. (Pitty it is XML based but does not use SVG for 
graphics.)

---
PM