RFC: default background on lattice plots

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: default background on lattice plots

Deepayan Sarkar
Hi,

Many of the complaints about lattice stem from the default settings
(a.k.a. theme) on screen devices, which has a grey background. It's
easy enough to change this, even pseudo-permanently through a startup
script, so this is not a serious problem. However, there's one
situation where this has an unfortunate effect: on Windows, someone
might

1. create a plot (on screen)
2. right click on it and print

which will print with the grey background and all (which is not a good
thing). Unfortunately, this is so easy to do that saying `this is not
the way to do it' is pointless (especially to students). I don't know
of a way to change the settings when this is done (and that's not the
goal of dev.print anyway). The one time I tried something similar on
S-Plus (Linux) it made the background white but retained the other
(light) colors, which is not a good solution either, even if it could
be done.

All this is to say that I'm inclined to change the default settings
for the windows() device before R 2.3.0 is released. The current plan
is to use the PDF defaults, which you can view on-screen using

library(lattice)
show.settings(canonical.theme("pdf"))

No changes are planned for any other device.

Not being a Windows user, I don't really care either way, so I'm open
to suggestions.
If you have any comments or opinions, please let me know (preferably
off-list, unless it's something of general interest).

Deepayan
--
http://www.stat.wisc.edu/~deepayan/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: RFC: default background on lattice plots

Fox, John
Dear Deepayan,

As you say, it's currently very easy to change settings (which is what I do
routinely), but since you asked, I much prefer the settings in
canonical.theme("pdf") and therefore would prefer that the windows() device
use these settings as a default (independent of the printing issue).

Regards, and thanks for the lattice package,

John

--------------------------------
John Fox
Department of Sociology
McMaster University
Hamilton, Ontario
Canada L8S 4M4
905-525-9140x23604
http://socserv.mcmaster.ca/jfox 
--------------------------------

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Deepayan Sarkar
> Sent: Saturday, March 11, 2006 12:56 PM
> To: [hidden email]
> Subject: [R] RFC: default background on lattice plots
>
> Hi,
>
> Many of the complaints about lattice stem from the default
> settings (a.k.a. theme) on screen devices, which has a grey
> background. It's easy enough to change this, even
> pseudo-permanently through a startup script, so this is not a
> serious problem. However, there's one situation where this
> has an unfortunate effect: on Windows, someone might
>
> 1. create a plot (on screen)
> 2. right click on it and print
>
> which will print with the grey background and all (which is
> not a good thing). Unfortunately, this is so easy to do that
> saying `this is not the way to do it' is pointless
> (especially to students). I don't know of a way to change the
> settings when this is done (and that's not the goal of
> dev.print anyway). The one time I tried something similar on
> S-Plus (Linux) it made the background white but retained the other
> (light) colors, which is not a good solution either, even if
> it could be done.
>
> All this is to say that I'm inclined to change the default
> settings for the windows() device before R 2.3.0 is released.
> The current plan is to use the PDF defaults, which you can
> view on-screen using
>
> library(lattice)
> show.settings(canonical.theme("pdf"))
>
> No changes are planned for any other device.
>
> Not being a Windows user, I don't really care either way, so
> I'm open to suggestions.
> If you have any comments or opinions, please let me know
> (preferably off-list, unless it's something of general interest).
>
> Deepayan
> --
> http://www.stat.wisc.edu/~deepayan/
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide!
> http://www.R-project.org/posting-guide.html

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: RFC: default background on lattice plots

Martin Maechler
>>>>> "JohnF" == John Fox <[hidden email]>
>>>>>     on Sat, 11 Mar 2006 13:29:34 -0500 writes:

    JohnF> Dear Deepayan, As you say, it's currently very easy
    JohnF> to change settings (which is what I do routinely),
    JohnF> but since you asked, I much prefer the settings in
    JohnF> canonical.theme("pdf") and therefore would prefer
    JohnF> that the windows() device use these settings as a
    JohnF> default (independent of the printing issue).

    JohnF> Regards, and thanks for the lattice package,

indeed, thanks a lot, Deepayan!

I think it would make much sense to use the *same*  canonical.theme
for all interactive default devices.
This may be important in teaching, packages, user-written
functions which often are all meant to be used interactively; I
think it would be painful if students in my class looked at
quite differently colored pictures depending on if they are
using MacOS X, Linux or Windows.

Hence, if you change the setting for windows(), I think you
should also do so for  x11() and quartz().

Martin Maechler,
ETH Zurich

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: RFC: default background on lattice plots

Prof Brian Ripley
On Mon, 13 Mar 2006, Martin Maechler wrote:

>>>>>> "JohnF" == John Fox <[hidden email]>
>>>>>>     on Sat, 11 Mar 2006 13:29:34 -0500 writes:
>
>    JohnF> Dear Deepayan, As you say, it's currently very easy
>    JohnF> to change settings (which is what I do routinely),
>    JohnF> but since you asked, I much prefer the settings in
>    JohnF> canonical.theme("pdf") and therefore would prefer
>    JohnF> that the windows() device use these settings as a
>    JohnF> default (independent of the printing issue).
>
>    JohnF> Regards, and thanks for the lattice package,
>
> indeed, thanks a lot, Deepayan!
>
> I think it would make much sense to use the *same*  canonical.theme
> for all interactive default devices.
> This may be important in teaching, packages, user-written
> functions which often are all meant to be used interactively; I
> think it would be painful if students in my class looked at
> quite differently colored pictures depending on if they are
> using MacOS X, Linux or Windows.
>
> Hence, if you change the setting for windows(), I think you
> should also do so for  x11() and quartz().

That would be an even stronger argument if those devices all rendered RGB
colours the same, but MacOS is running a different default interpretation,
AFAIK (and many PC displays are still way off sRGB, hence the gamma
argument of some devices but unfortunately not quartz()).  Beyond that,
the visual effect is dependent both on the brilliance setting of the
display and ambient lighting levels, and most people have screens set far
too bright (and work in too harshly lit environments) to achieve optimal
rendition.

I can see two defensible positions.

1) Default themes are chosen for each device with a common 'perceptual
intent' (a technical phrase).  I believe that was the aim of Trellis, but
one not achieved on many displays (I remember a muddy brown background on
an old Sun display Bill Venables had).

2) The same theme is chosen for all devices, and the user is expected to
establish proper viewing conditions.  That would mean using the same
default theme for _all_ devices.

I think 2) has to be the way forward, as nowadays there is no reason to
suppose that postscript() or pdf() output will be printed rather than say
included into a lecture presentation (and if so whether that will be
printed or 'beamed').

(Ross Ihaka did once mention an intent to include colour management into
R, so that R RGB colours were rendered as accurately as possible in sRGB.
That would remove the MacOS anomaly.)

--
Brian D. Ripley,                  [hidden email]
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: RFC: default background on lattice plots

Deepayan Sarkar
On 3/13/06, Prof Brian Ripley <[hidden email]> wrote:

> On Mon, 13 Mar 2006, Martin Maechler wrote:
>
> >>>>>> "JohnF" == John Fox <[hidden email]>
> >>>>>>     on Sat, 11 Mar 2006 13:29:34 -0500 writes:
> >
> >    JohnF> Dear Deepayan, As you say, it's currently very easy
> >    JohnF> to change settings (which is what I do routinely),
> >    JohnF> but since you asked, I much prefer the settings in
> >    JohnF> canonical.theme("pdf") and therefore would prefer
> >    JohnF> that the windows() device use these settings as a
> >    JohnF> default (independent of the printing issue).
> >
> >    JohnF> Regards, and thanks for the lattice package,
> >
> > indeed, thanks a lot, Deepayan!
> >
> > I think it would make much sense to use the *same*  canonical.theme
> > for all interactive default devices.
> > This may be important in teaching, packages, user-written
> > functions which often are all meant to be used interactively; I
> > think it would be painful if students in my class looked at
> > quite differently colored pictures depending on if they are
> > using MacOS X, Linux or Windows.
> >
> > Hence, if you change the setting for windows(), I think you
> > should also do so for  x11() and quartz().
>
> That would be an even stronger argument if those devices all rendered RGB
> colours the same, but MacOS is running a different default interpretation,
> AFAIK (and many PC displays are still way off sRGB, hence the gamma
> argument of some devices but unfortunately not quartz()).  Beyond that,
> the visual effect is dependent both on the brilliance setting of the
> display and ambient lighting levels, and most people have screens set far
> too bright (and work in too harshly lit environments) to achieve optimal
> rendition.
>
> I can see two defensible positions.
>
> 1) Default themes are chosen for each device with a common 'perceptual
> intent' (a technical phrase).  I believe that was the aim of Trellis, but
> one not achieved on many displays (I remember a muddy brown background on
> an old Sun display Bill Venables had).
>
> 2) The same theme is chosen for all devices, and the user is expected to
> establish proper viewing conditions.  That would mean using the same
> default theme for _all_ devices.
>
> I think 2) has to be the way forward, as nowadays there is no reason to
> suppose that postscript() or pdf() output will be printed rather than say
> included into a lecture presentation (and if so whether that will be
> printed or 'beamed').

I completely agree (personally, I would prefer to retain black and
white defaults for postscript, but that's only because most of our
printers are still B&W). The important question is then, what should
this default be?

The current default (the one with a grey background) obviously has
issues, but at least some thought was put into it (see, e.g.
http://cm.bell-labs.com/stat/doc/trellis.tour.col.ps). The other
available themes are

(a) the current PDF default, which is essentially the screen defaults
with background changed to white, followed by some of the lighter
symbol colors made darker according to my whims at the time.

(b) col.whitebg(), which was meant to be a proof of concept, and
should not be considered seriously.

There has been no systematic study of how these settings affect
perception. I know of some work on the optimal choice of colors (e.g.
http://www.ci.tuwien.ac.at/Conferences/DSC-2003/Proceedings/Ihaka.pdf),
but they mostly apply to fill colors, not symbol/line colors.
Personally, I'm happy enough with the PDF defaults (except maybe the
third superpose.symbol color), but I'm sure they can be improved.

-Deepayan

> (Ross Ihaka did once mention an intent to include colour management into
> R, so that R RGB colours were rendered as accurately as possible in sRGB.
> That would remove the MacOS anomaly.)
>
> --
> Brian D. Ripley,                  [hidden email]
> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html