Qt device update
On 5/3/07, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
On Thu, 3 May 2007, Deepayan Sarkar wrote:
Hi, a few days back I had asked for help on a Qt device package. Thanks to hints from Duncan TL and Thomas Friedrichsmeier, I now have something more or less functional. For those interested, It can be downloaded from http://dsarkar.fhcrc.org/R/R-Qt.html I have a couple of related questions. First, dev.interactive(), used in example() and many demo()-s to decide if the current device is interactive, is currently implemented as:
dev.interactive
function (orNone = FALSE)
{
iDevs <- c("X11", "GTK", "gnome", "quartz", "windows", "JavaGD")
interactive() && (.Device %in% iDevs || (orNone && .Device ==
"null device" && getOption("device") %in% iDevs))
}
This makes it impossible for new devices to be treated as interactive.
Perhaps it would be better to change this to something like
iDevs <- c("X11", "GTK", "gnome", "quartz", "windows", "JavaGD",
getOption("interactive.devices"))
so that packages can set an option to be included in this list.
That would work differently from any existing option, adding to the list. But it would make sense for package grDevices to have a function to request being added to the list. (If the device is already running we could use grDevices:::dev.displaylist() to ask if this looked like a screen device.)
I will be happy with anything that works. Given Simon's comments, it looks like this might be non-trivial, so a short term solution could be to add a ask= argument to demo() (like example() already has) and remove the explicit overrides in the standard demos.
Second, can someone explain the details of what happens when a symbol font is requested (with font=5 or with plotmath stuff)? demo(plotmath) seems to work on a machine with LANG=en_US (I don't know what encoding this means, probably latin1),
If a Linux machine, yes, it is shorthand for en_US.iso88591. It could also mean ASCII and according to the standards (XPG?) probably should.
but some symbols don't work on my desktop which has en_US.UTF-8. Presumably, this means I have to interpret the encoding differently, but what exactly is the rule? Is it enough to treat it as latin1? Some devices have a lot of code dealing with encodings, and I want to make sure I understand the issues before I go off on a wild goose chase.
The symbol font is regarded as being in Adobe Symbol encoding, which is an 8-bit encoding. So you have to be careful to handle font 5 without re-encoding, but that's not hard at device level (the graphics engine has handled the re-encoding needed).
Ah, that's the piece I was missing. I was reencoding everything using QString::fromLocal8bit(). If I skip that when fontface=5, things work better. I do need it for other fontfaces to get multibyte encodings working properly.
If some symbols work and some do not, this is almost certainly a font selection issue. If X11 is involved (and AFAIK the Qt implementations on Linux run on X11), you do need to ensure that getting a font in the desired encoding is given top priority (which can be hard to achieve in X11).
That may be a problem in general, but the only problem I see on (both) my Linux machines after the above fix is that %prop% shows up as mu (but Windows is fine). I'm not really sure what font is being used, I'll try to track it down. -Deepayan