I have some problems producing postscript plots using rkward (versions 0.3.6 and 0.4.5). Relatively simple plots like
postscript()
plot(1:10,1:10,type="l")
dev.off()
which gives just a diagonal line fail. A file "Rplot.ps" is saved, but invoking a ghostscript interpreter gives an error like
ERROR: /undefined in 595,00
Operand stack:
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval--
Dictionary stack:
--dict:1121/1686(ro)(G)-- --dict:0/20(G)-- --dict:99/200(L)--
Current allocation mode is local
Current file position is 2313
ESP Ghostscript 815.02: Unrecoverable error, exit code 1
I get the same for other plots. If I save the code to a file and load it directly into R (2.3.1) I get a perfect postscript file.
This behaviour seems to be basically the same for every output-device using ghostscript (e.g. pdf or bitmap) while functions like png() are working perfectly.
Since I need to print the plots, pixel-oriented formats like png and jpeg are not really usefull.
Do I make something wrong? Or is this functionality just not implemented yet?
I use rkward with KDE 3.5.6 under Kubuntu Edgy.
Regards,
Matthias
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> If I save the code to a file and load it directly into R (2.3.1) I get a perfect postscript file.
This is strange. RKWard does not do anything special to this at all. So you *should* get the same result as in plain R.
We're currently running into some issue related to character encoding, here and there, so my first guess is, it may have something to do with that. ?postscript mentions some pretty complicated details on encodings. While I'd rather expect just some ill-printed characters, maybe encoding problems can also cause an invalid postscript file to be generated.
Could you check this:
Run
> Sys.getlocale ()
in both RKWard and plain R. Is there any difference? If so, can you reproduce the problem by setting the same locale in plain R (using e.g.
# LC_ALL=your.locale R
)? Can you produce a valid .ps file when starting RKWard with
# KDE_LANG=C rkward
? Does setting the "encoding" parameter to postscript change anything?
If this is the reason, I still do not have a good idea on how to fix this, but figuring out, how this happens would be a start...
Regards
Thomas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not really sure if this is a difference or the same as many of the variables in plain R are also set to de_DE.ISO-8859-1.
Also starting R as well as RKWard with the given environment variables set as mentioned won't change the output of Sys.getlocale().
Setting encoding="ISOLatin1" which I think is ISO-8859-1 still results in a corrupted postscript file.
I also recognized that RKWard is unable to understand decimal numbers like 0.5. RKWard gives:
> 0.5
[1] 0
> 1/2
[1] 0,5
> 0,5
Syntax error
While R does not have any problems with 0.5. May this also be a problem with the encoding as KDE is configured to use the "," to seperate the decimal places?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I am not really sure if this is a difference or the same as many of the variables in plain R are also set to de_DE.ISO-8859-1.
It is a difference, indeed. LC_NUMERIC must always be set to "C", or R (and RKWard) will not function properly (see below). I.e. the output or Sys.getlocale () inside RKWard should look like the one you get inside R.
> Also starting R as well as RKWard with the given environment variables set as mentioned won't change the output of Sys.getlocale().
Could you try these two additional ways of starting RKWard?
# LC_ALL=C rkward
# LC_NUMERIC=C rkward
Do the problems go away in this case? What is the output of Sys.getlocale () when starting rkward like this?
> I also recognized that RKWard is unable to understand decimal numbers like 0.5.
Normally R (and hence RKWard) will explicitely set it to "C" on startup. Apparently this setting then got overwritten by some means, probably by the SCIM plugin. To get around this, we set the environment variable LC_NUMERIC in the launch script for RKWard, which fixed the problem.
Are you sure you are starting RKWard using the launch script (usually, this should be the case with any recent version of RKWard, and if you do not do anything special)? Are you sure, you are really using a post 0.3.5 version of RKWard, and not some earlier version which might still be installed on your system (check Help->About RKWard)?
If the answer to both questions is "yes", then probably SCIM now uses a yet more hideous method to force a bad LC_NUMERIC setting, and we need to find another workaround. In both cases, please write back, so we can be sure to take care of this issue.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Update: I started playing some with SCIM, and can now reproduce this problem under the condition that LC_ALL is set in the enviroment. I have added a workaround for that case, to be part of the next release (expected tomorrow).
To verify that I'm guessing correctly, could you verify the following two things:
1) You have "scim" installed, and when starting rkward in a console, you see a line
ScimInputContextPlugin()
somewhere near the top of the output?
2) You have LC_ALL defined in your environment, i.e.
# env | grep "LC_ALL"
shows some setting?
If both is the case, the problem should be fixed. If not, it's something else, so please write back.
Thanks again, for reporting!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I have some problems producing postscript plots using rkward (versions 0.3.6 and 0.4.5). Relatively simple plots like
postscript()
plot(1:10,1:10,type="l")
dev.off()
which gives just a diagonal line fail. A file "Rplot.ps" is saved, but invoking a ghostscript interpreter gives an error like
ERROR: /undefined in 595,00
Operand stack:
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval--
Dictionary stack:
--dict:1121/1686(ro)(G)-- --dict:0/20(G)-- --dict:99/200(L)--
Current allocation mode is local
Current file position is 2313
ESP Ghostscript 815.02: Unrecoverable error, exit code 1
I get the same for other plots. If I save the code to a file and load it directly into R (2.3.1) I get a perfect postscript file.
This behaviour seems to be basically the same for every output-device using ghostscript (e.g. pdf or bitmap) while functions like png() are working perfectly.
Since I need to print the plots, pixel-oriented formats like png and jpeg are not really usefull.
Do I make something wrong? Or is this functionality just not implemented yet?
I use rkward with KDE 3.5.6 under Kubuntu Edgy.
Regards,
Matthias
> If I save the code to a file and load it directly into R (2.3.1) I get a perfect postscript file.
This is strange. RKWard does not do anything special to this at all. So you *should* get the same result as in plain R.
We're currently running into some issue related to character encoding, here and there, so my first guess is, it may have something to do with that. ?postscript mentions some pretty complicated details on encodings. While I'd rather expect just some ill-printed characters, maybe encoding problems can also cause an invalid postscript file to be generated.
Could you check this:
Run
> Sys.getlocale ()
in both RKWard and plain R. Is there any difference? If so, can you reproduce the problem by setting the same locale in plain R (using e.g.
# LC_ALL=your.locale R
)? Can you produce a valid .ps file when starting RKWard with
# KDE_LANG=C rkward
? Does setting the "encoding" parameter to postscript change anything?
If this is the reason, I still do not have a good idea on how to fix this, but figuring out, how this happens would be a start...
Regards
Thomas
The Results for Sys.getlocale() are:
RKWard:
[1] "de_DE.ISO-8859-1"
plain R:
[1] "LC_CTYPE=de_DE.ISO-8859-1;LC_NUMERIC=C;LC_TIME=de_DE.ISO-8859-1;LC_COLLATE=de_DE.ISO-8859-1;
LC_MONETARY=de_DE.ISO-8859-1;LC_MESSAGES=de_DE.ISO-8859-1;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;
LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C"
I am not really sure if this is a difference or the same as many of the variables in plain R are also set to de_DE.ISO-8859-1.
Also starting R as well as RKWard with the given environment variables set as mentioned won't change the output of Sys.getlocale().
Setting encoding="ISOLatin1" which I think is ISO-8859-1 still results in a corrupted postscript file.
I also recognized that RKWard is unable to understand decimal numbers like 0.5. RKWard gives:
> 0.5
[1] 0
> 1/2
[1] 0,5
> 0,5
Syntax error
While R does not have any problems with 0.5. May this also be a problem with the encoding as KDE is configured to use the "," to seperate the decimal places?
> I am not really sure if this is a difference or the same as many of the variables in plain R are also set to de_DE.ISO-8859-1.
It is a difference, indeed. LC_NUMERIC must always be set to "C", or R (and RKWard) will not function properly (see below). I.e. the output or Sys.getlocale () inside RKWard should look like the one you get inside R.
> Also starting R as well as RKWard with the given environment variables set as mentioned won't change the output of Sys.getlocale().
Could you try these two additional ways of starting RKWard?
# LC_ALL=C rkward
# LC_NUMERIC=C rkward
Do the problems go away in this case? What is the output of Sys.getlocale () when starting rkward like this?
> I also recognized that RKWard is unable to understand decimal numbers like 0.5.
We encountered (and fixed) that problem a while back (before 0.3.5): https://sourceforge.net/mailarchive/forum.php?thread_id=10067620&forum_id=12970 and https://sourceforge.net/mailarchive/forum.php?thread_id=10082507&forum_id=12970 . The problem is a bad setting for LC_NUMERIC, which should be set to "C".
Normally R (and hence RKWard) will explicitely set it to "C" on startup. Apparently this setting then got overwritten by some means, probably by the SCIM plugin. To get around this, we set the environment variable LC_NUMERIC in the launch script for RKWard, which fixed the problem.
Are you sure you are starting RKWard using the launch script (usually, this should be the case with any recent version of RKWard, and if you do not do anything special)? Are you sure, you are really using a post 0.3.5 version of RKWard, and not some earlier version which might still be installed on your system (check Help->About RKWard)?
If the answer to both questions is "yes", then probably SCIM now uses a yet more hideous method to force a bad LC_NUMERIC setting, and we need to find another workaround. In both cases, please write back, so we can be sure to take care of this issue.
Thanks!
I am doing some things on locale and R (and RKWard). Could you give us the result of Sys.getlocale() on RKWard? When I do it on my system I take
Sys.getlocale()
[1] "LC_CTYPE=el_GR.ISO-8859-7;LC_NUMERIC=C;LC_TIME=el_GR.ISO-8859-7;LC_COLLATE=el_GR.ISO-8859-7;LC_MONETARY=el_GR.ISO-8859-7;LC_MESSAGES=el_GR.ISO-8859-7;LC_PAPER=el_GR.ISO-8859-7;LC_NAME=el_GR.ISO-8859-7;LC_ADDRESS=el_GR.ISO-8859-7;LC_TELEPHONE=el_GR.ISO-8859-7;LC_MEASUREMENT=el_GR.ISO-8859-7;LC_IDENTIFICATION=el_GR.ISO-8859-7"
just as in R. Do you only take this?
RKWard:
[1] "de_DE.ISO-8859-1"
Can you give us the result of the command
locale -a
(You have to do it in a terminal, not in R or RKWard.)
Also please give the version of RKWard and Kubuntu that you are using.
Could you try again with the 0.4.6 version, released a few minutes ago? I believe both problems should be fixed in 0.4.6.
Regards
Thomas
You were right. Both problems are solved in 0.4.6.
Thank you for your good work!
Regards
Matthias
Update: I started playing some with SCIM, and can now reproduce this problem under the condition that LC_ALL is set in the enviroment. I have added a workaround for that case, to be part of the next release (expected tomorrow).
To verify that I'm guessing correctly, could you verify the following two things:
1) You have "scim" installed, and when starting rkward in a console, you see a line
ScimInputContextPlugin()
somewhere near the top of the output?
2) You have LC_ALL defined in your environment, i.e.
# env | grep "LC_ALL"
shows some setting?
If both is the case, the problem should be fixed. If not, it's something else, so please write back.
Thanks again, for reporting!