Re: AW: filenames on MS Windows
Allin Cottrell <[email protected]>
| Newsgroups | gmane.comp.graphics.gnuplot.devel |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 2 Nov 2020, Bastian Märkisch wrote: > Allin, > > Thank you for this nice contribution. On Windows, we already replace > fopen() (and many other functions), though. In particular, win_fopen() in > winmain.c already handles encodings, including UTF-8. There are also two > functions AnsiText() and UnicodeText() to convert to/from UTF16 according to > gnuplot's encoding. Yes, I'm aware of that and it's a very nice feature. > They use the simple-to-use Windows functions > WideCharToMultiByte() MultiByteToWideChar(), so no need for glib. Ah, OK. > That really poses the question if we should change the default internal > encoding from "ANSI" (whatever that may be depends on the Windows locale) to > UTF-8. I agree with that (and in fact my personal gnuplot.ini includes "set > encoding utf8" since a long time). > > But how do we make this backward compatible since that will inevitably break > load commands in old "ANSI" encoded user scripts? (as does your current > patch btw) Are you sure about that breakage, Bastian? I may be missing something, but here's my thinking: (1) I convert UTF-16 -> UTF-8 only for filenames coming off the Windows command-line in winmain.c, and (2) in my modified loadpath_fopen() I first try fopen() on the filename as-is, converting UTF-8 -> UTF-16 and calling _wfopen() only if fopen() fails and the filename validates as UTF-8. So I don't _think_ my patch is going to touch filenames read via the load command in a gnuplot script. Allin Cottrell _______________________________________________ gnuplot-beta mailing list [email protected] Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta