From ripley at stats.ox.ac.uk  Fri May  4 07:50:25 2007
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Fri, 4 May 2007 06:50:25 +0100 (BST)
Subject: [Rd] Qt device update
In-Reply-To: <eb555e660705031752p5a96153fifaabd0d5fdf0bdeb@mail.gmail.com>
References: <eb555e660705031752p5a96153fifaabd0d5fdf0bdeb@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0705040627180.19693@gannet.stats.ox.ac.uk>

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.)

> 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).

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).

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595



[Rd] Qt device update
Prof Brian Ripley