Re: [Rd] Qt device update

From: Deepayan Sarkar <>
Date: Fri, 04 May 2007 12:43:24 -0700

On 5/3/07, Prof Brian Ripley <> 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
> >
> >
> >
> > 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 mailing list Received on Fri 04 May 2007 - 19:59:49 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Fri 04 May 2007 - 22:33:28 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.