Philippe Grosjean raised the question of transparency in the context of writing Windows metafiles, but it has come up before for bitmapped graphics. I've taken a look in the sources, and what we do now is inconsistent. The postscript/xfig/pdf devices do not paint the background iff it is "white". All the screen devices always paint the background, as do the bitmap devices and all the Windows devices (including writing to metafile and to the printer). I think this is unsatisfactory, and inconsistent with the way colour is handled for filled objects (rectangles and circles). Not painting a white background is also undocumented! For 1.3.1 I think we should document this, and alter win.metafile and win.printer to make a white background mean transparent. (I've tested that, and it works.) However, for the future (1.4.x), I think we should handle "white" and "transparent" differently, and have bg default to "transparent" for all devices. A quick look shows that this is would be easy, as only 24 bits of the rcolor type are used. So would there be an objections to using a bit (or a single value) of the upper byte to denote "transparent"? (Actually, Peter D has 0xffffffff in use as invalid, but that's more bits than are needed.) For consistency "transparent" should be an alternative to NA in the fill routines, which means that the obvious rcolor value is (unsigned) NA_INTEGER. One question then is what bg="transparent" would mean for a screen device. I think it should mean "white", but the difference would emerge if the device was copied. An alternative for the windows() device (which can have a canvas larger than the device region) would be the canvas colour (default grey50). In that case one might want a default of "white". Clearly some thought would be needed to get the png devices to handle transparency, but it should be doable. Brian -- Brian D. Ripley, ripley@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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On Thu, 9 Aug 2001, Prof Brian Ripley wrote:> However, for the future (1.4.x), I think we should handle "white" and > "transparent" differently, and have bg default to "transparent" for > all devices. A quick look shows that this is would be easy, as only > 24 bits of the rcolor type are used. So would there be an objections > to using a bit (or a single value) of the upper byte to denote > "transparent"? (Actually, Peter D has 0xffffffff in use as invalid, > but that's more bits than are needed.) For consistency "transparent" > should be an alternative to NA in the fill routines, which means that > the obvious rcolor value is (unsigned) NA_INTEGER.Definitely transparency would be very useful, and I think a bit in the upper byte is a good place to store it.> One question then is what bg="transparent" would mean for a screen > device. I think it should mean "white", but the difference would > emerge if the device was copied. An alternative for the windows() > device (which can have a canvas larger than the device region) would > be the canvas colour (default grey50). In that case one might want a > default of "white".If "transparent" is to be the default then I think it should show up as white on screen (at least by default) It would be nice if a canvas color were available for other screen devices, to allow easier previewing of transparent graphics against different background colors. It's obviously not that important, since you can always plot the graph against a filled background of that color, but it would be convenient if it isn't too hard. That is, the default color would be set by some sort of options(canvas.color) that would default to eg "grey50" or "white". -thomas Thomas Lumley Asst. Professor, Biostatistics tlumley@u.washington.edu University of Washington, Seattle -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Rather than a yes/no tranparency indicator, should we consider using entire "unused byte" as an alpha-channel? (meaning that we specify transparency as a value in [0,255]). Many graphics/paint programs (e.g. gimp) do this sort of thing. Transparency would need to be device dependent, but a simple yes/no transparency could be obtained by thresholding the alpha value. This would entail a change to way indices into colour palettes are handled, but Peter D has pointed out that this is currently broken anyway. The rendering extension to the X server includes support for transparency and this might be a place to look for how screen devices should behave. Ross -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
IMHO that would be a Good Idea. It would also make people less inclined to use color references to mean things other than color. Byron Ellis (bellis@hsph.harvard.edu) "Oook" - The Librarian On Sat, 11 Aug 2001, Ross Ihaka wrote:> Rather than a yes/no tranparency indicator, should we consider using > entire "unused byte" as an alpha-channel? (meaning that we specify > transparency as a value in [0,255]). Many graphics/paint programs (e.g. > gimp) do this sort of thing. Transparency would need to be device > dependent, but a simple yes/no transparency could be obtained by > thresholding the alpha value. This would entail a change to way indices > into colour palettes are handled, but Peter D has pointed out that this > is currently broken anyway. > > The rendering extension to the X server includes support for > transparency and this might be a place to look for how screen devices > should behave. > > Ross > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html > Send "info", "help", or "[un]subscribe" > (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ >-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._