Menu
▾
▴
gnuplot-beta
|
From: Dr. J. Z. <joh...@ze...> - 2006-12-13 20:56:21
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-12-13 22:01:52
|
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 |
|
From: <tim...@en...> - 2006-12-13 21:46:18
|
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 |
|
From: Petr M. <mi...@ph...> - 2006-12-13 21:50:55
|
> > 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 |
|
From: <tim...@en...> - 2006-12-13 21:53:17
|
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 |
|
From: Petr M. <mi...@ph...> - 2006-12-13 22:29:07
|
> 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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-12-13 22:45:49
|
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 |
|
From: Petr M. <mi...@ph...> - 2006-12-13 22:55:26
|
> > 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 |
|
From: Mojca M. <moj...@gm...> - 2006-12-13 23:16:34
|
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
|
|
From: Ethan M. <merritt@u.washington.edu> - 2006-12-13 23:33:19
|
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 |
|
From: Petr M. <mi...@ph...> - 2006-12-14 08:30:10
|
> > 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 |
