Re: [Gretl-devel] Copy as RTF does not work well under OSX
On Mon, 21 Apr 2014, Shintaro Nakagawa wrote:
Dear Allin
Thank you for your revision. I tried the latest snapshot.
The "Couldn't open pbcopy" problem is solved.
Glad to hear that.
However, when I copied a model table as RTF, the table was pasted as
a
source of RTF.
With Yen symbols substituted for backslashes, or no?
This phenomenon did not occur when I set CFUserTextEncoding as 0:0.
By the way, I complied the following program on my Japanese environment
and executed it on Terminal. It worked fine.
#include <stdio.h>
#include <stdlib.h>
#include <err.h>
#define BUF 256
int main (int argc, char *argv[])
{
FILE *fp;
char *cmdline = "/usr/bin/pbcopy";
if ( (fp=popen(cmdline,"w")) ==NULL) {
err(EXIT_FAILURE, "%s", cmdline);
}
(void) fputs("{\\rtf \\b Hello! from C}", fp);
(void) pclose(fp);
exit (EXIT_SUCCESS);
}
I set the encoding of the above program as UTF8.
How did you do that?
After executing the above program on Terminal, I can paste
"Hello! from
C" in bold font into Word.
OK, but it seems to me that what gretl does is essentially the same as
what your test program does: open a pipe to pbcopy and emit RTF that is
nothing but ASCII bytes.
I'm not aware of any Apple API to set what the file ~/.CFUserTextEncoding
sets, although there is an environment variable __CF_USER_TEXT_ENCODING
that might do something (but might also screw up the user's setting, I
suppose).
Moreover, even if we could set this Apple-specific variable to UTF-8, that
would be fragile. UTF-8 (other than its ASCII subset) is not acceptable in
RTF. So if anyone were to produce a Japanese translation of the gretl
output strings, our writing of RTF would presumably break.
Allin