| | <<<Back 1 day (to 2017/12/31) | 20180101 |
| Robin_Watts | albel727: Ok, so *this* one passes our tests: http://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=commitdiff;h=193e3b87bc711d30be0c2c41f6b3e61f49c92b22 | 14:27.55 |
| | Does that solve it for you? | 14:27.59 |
| albel727 | Robin_Watts: it does. both my minimal example and my original code with which I found the problem work ok with it. | 15:47.08 |
| Robin_Watts | albel727: Thanks. | 15:47.18 |
| albel727 | thank you too. | 15:47.24 |
| Robin_Watts | I'll wave it at some colleagues for their opinions tomorrow (when they start back), and get it committed. | 15:47.54 |
| albel727 | alternatively, maybe you should consider deprecating the UTF16LE setting altogether, since it doesn't look like it could be used by anyone, and utf-8 should be enough for everyone (c) | 15:50.46 |
| Robin_Watts | albel727: yeah, but I fear this points to the fact that local encodings haven't worked properly in all cases either. | 15:54.16 |
| | Even we deprecated utf16le, we'd need to put this fix in. | 15:54.44 |
| albel727 | well, I think all local encodings are 8-bit ascii-compatible, so at the very least switch parsing shouldn't have had any problems. and I don't immediately see how it would fail with local-encoded filenames either. | 15:57.30 |
| | (don't quote me on that though.) so yeah, I guess running it through with other people would be wise. I just thought this might have been a good point to cut on the unused UTF-16 stuff that you would otherwise have to backcompat forever. | 16:03.33 |
| Robin_Watts | The idea is we can add new encodings just by adding some hooks inside that map from JRandomEncoding to utf-8. | 16:04.53 |
| albel727 | "batteries included" might be nice in some ways, but I'm not sure a postscript library should dub as iconv. it's just more code to maintain and support while not offering anything that specialized conversion tools don't already provide. | 16:13.17 |
| | now if it was about adding some encodings that aren't as of yet losslessly mappable into utf-8 (e.g. some of the rarer chinese characters that aren't yet in unicode, or the abovementioned windows's WTF-16), then it might have been worth it. | 16:13.48 |
| Robin_Watts | Just to be clear... this is purely for argument handling. It doesn't affect the range of chars that can be displayed by the interpreter. | 16:36.05 |
| | gs has to run on all sorts of different platforms, so there is no telling what different encodings we may run up against in future. | 16:36.35 |
| | So the approach of always using utf-8 internally, and converting from "whatever" encoding to that is our way of coping. | 16:37.08 |
| | You can argue that some encodings may be unnecessary, but they serve a purpose as test cases at least. | 16:38.14 |
| | This being a case in point :) | 16:38.21 |
| albel727 | well, on windows you have any and all local encodings conveniently converted by a single api call for you into UTF-16. on posix oses you can iconv into UTF-8. any new os-es will without doubt use UTF-8. your frontend executables can and already do handle conversion to utf-8 themselves, without making it a library option. | 16:44.42 |
| | UTF-16 so far has only served as a case in point of not using UTF-16 :) | 16:44.52 |
| | s/without making it/without needing to make any conversion/ | 16:46.35 |
| | so the only case you aren't already prepared to handle is WTF-16 for filenames, because everything else can be converted into utf-8 beforehand. | 16:49.17 |
| | Forward 1 day (to 2018/01/02)>>> | |
Log of #ghostscript at irc.freenode.net.