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