[Rd] Qt device update

[Deepayan Sarkar]

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