On 5/3/07, Prof Brian Ripley <[EMAIL PROTECTED]> 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
