[Rd] Macintosh Transperancy (PR#11511)

Simon Urbanek simon.urbanek at r-project.org
Mon May 26 19:02:18 CEST 2008 

Bradley,

this is getting off topic. Please check the result of graphics devices  
in R (X11, Quartz,...) and you'll find you that Quartz is consistent  
with all others. Also see Brian's response.

Although I can see what you want, it's not possible with the current  
graphics model and it's a wish, not a bug. Also it has nothing to do  
with Quartz whatsoever.

Cheers,
Simon

PS: I agree that you may want to file a bug report on Preview, but  
then I guess Apple knows about it and but they may be reluctant to  
change it, because it would affect all graphics in OS X, not just PDF.  
(see 7.5.1 and 7.6.3 in the PDF 1.6 specs)


On May 25, 2008, at 7:56 PM, Bradley Vance wrote:

> Simon,
>
> On May 24, 2008, at 10:28 PM, Simon Urbanek wrote:
>
>> Bradley,
>>
>> On May 24, 2008, at 9:07 PM, Bradley Vance wrote:
>>
>>> 	The bug is that the point that's being plotted is a single point,  
>>> not a combination of two points, one that's just the outline, and  
>>> one that's just the fill.  It also doesn't look like we'd expect  
>>> when you're debugging a plot.  For example, let's say I create a  
>>> plot, and notice that I can't see some of the points (due to other  
>>> points being drawn on top of them).  So I decide to make them  
>>> transparent, so you can see where points over-lay each other, and  
>>> the relative size/colors/etc of the over-layed points.  Now,  
>>> rather than just changing the opacity of the points/colors I see,  
>>> I'm adding in another color to each point where outline and  
>>> background meet, making the plot more confusing than it needs to  
>>> be...
>>> 	In looking at the documentation for bg in points (plot says to  
>>> look at points for bg) it says
>>> bgbackground (fill) color for the open plot symbols given by  
>>> pch=21:25.
>>> and the way it is now, the color is not a fill (ie - inside the  
>>> lines) - it's super-imposed over part of the line.
>>
>> I think you're still missing the point - it is the fill. I suspect  
>> you're misunderstanding the effect of using semi-transparent  
>> strokes. Moreover I get *exactly* the same result using X11 (both  
>> Mac *and* Linux) as well as other devices (PDF etc.). If you see  
>> anything else then *that* is a bug.
>>
>> A point is represented by a shape (path) which is filled and then  
>> drawn (line stroke). As I was trying to explain earlier the effect  
>> is that half of the line is in the filled area. Imagine a rectangle  
>> (0,0)-(1,1). When you fill it, you're filling strictly the area  
>> between 0 and 1 (in both x and y). However, when you strike let's  
>> say the line (0,0)-(1,0) with the width 0.25, you are filling the  
>> area (0,-0.25)-(1,+0.25) which means that half the line is outside  
>> (y<0) the filled are and another half is inside (y>=0). Given the  
>> alpha-blending mechanics [target=alpha*color + (1-alpha)*old] it  
>> implies that if the fill color is different from the background  
>> color and the line is not opaque, you get different color outside  
>> and inside the rectangle. You can verify that this is true for all  
>> devices that support alpha blending. This is how it works and is  
>> supposed to be, that's not a bug.
> While I agree that it should look that way if you draw it as you  
> describe, I don't think you're describing the drawing process the  
> way people expect.  I don't think FILL means that you draw the shape/ 
> fill first, then draw the perimeter (which is what you describe).  I  
> think it means that you draw the perimeter first, and then fill-in  
> everything that's inside the perimeter.  From my experience, that's  
> the way all the drawing programs I've used work.
> 	If a user were to draw the point themselves, they would draw the  
> perimeter, then use a fill tool to fill what's inside the  
> perimeter.  They would NOT draw a filled-shape, and then draw the  
> empty-shape.
> 	I also think that the users shouldn't need to be familiar with the  
> complexities of drawing each point with different strokes.  Perhaps  
> the best way to do this would be to have a separate alpha-parameter  
> for the point itself.  This would hide the complexities of drawing  
> the point, and allow the users to use regular colors (without alpha- 
> extensions) for their points.  I think that most times users want  
> transparency, they want the point that was drawn without  
> transparency to have transparency, and not to have to think about  
> the transparency of individual strokes/etc...
>>
>>> 	Also, there's the fact that it does something different on  
>>> different systems.  When I do the same thing at work on a Linux  
>>> box (we don't have R.2.7 yet, we use mostly R2.4 but I've tried it  
>>> on R2.6,
>>
>> Well, 2.6 didn't have alpha support in X11 AFAIR, so I have no idea  
>> what you are trying to compare there ...
> Look at the next line - I used the Linux version to print out to  
> PDF...   You are correct that X11 didn't/doesn't have alpha support,  
> but a PDF device has had alpha-support for quite a while.
>>
>>> and we don't have Quartz, but I did output to PDF), it looks like  
>>> a single point whose colors were made transparent, and not a point  
>>> made of two overlapping transparent parts.
> In further debug today, I actually found out that what you see  
> depends on the PDF-viewer you use.  Since I used acroread at work/ 
> linux, and preview at home/mac, I assumed the files they created  
> were different.  Actually, it looks like they are the same, but what  
> they look like is different.  I verified this by downloading Adobe  
> Reader for my mac (latest version), and comparing it to what is  
> shown in Preview.   I then took snap-shots of the entire windows to  
> a PNG, so that you can see how they draw them differently.  This may  
> actually need to ticket to go to Apple.  But as you can see from  
> these snapshots, I think that how Adobe (PDF-spec-creator) shows the  
> plot is correct (First is Adobe Reader, 2nd is Preview).  On my work- 
> Linux box, acroread shows the same as Adobe Reader on my mac.  My  
> guess is that Adobe uses FILL to mean fill-inside-the-perimeter- 
> shape, the way I described above, and Preview uses it to mean fill- 
> inside-the-shape-then-draw-the-perimeter that you're advocating.   
> Myself, I think that adobe is correct...
>
> <Rplot_AdobeReader.png><Rplot_Preview.png>
>
>
> 	Here's 3-points at the top, zoomed in (Adobe first, Preview 2nd).   
> Personally, I find that the first looks much cleaner / less noisy  
> than the second.  Maybe it's just because that's what I expect...
> <Rplot_AdobeReader_zoom.png><Rplot_Preview_zoom.png>
>
>>>
>>> 	As I implied in my original ticket, I'd like to be able to choose  
>>> whether to have it look the way it does now on the mac, and the  
>>> way it does on Linux.  This might actually be something that needs  
>>> to be addressed further by the core team, as that opacity is  
>>> planning to be added for X11() for the next revision (and  
>>> hopefully, will work into PNG and other device types that can  
>>> support it)...
>>> 	Perhaps the best way to implement the options/choices/etc is to  
>>> add a separate alpha/opacity/whatever options that would control  
>>> the opacity of each object it plots.  Thus, if you define an  
>>> opacity to either col or bg, it would work the way it does on the  
>>> Mac (ie - the colors are opaque and can thus you can see the other  
>>> point-color through the top one).  However, if you have a point- 
>>> opacity defined, the entire point will get the opacity, the way it  
>>> is currently done on Linux.
>>> 	Or, you can just say that in order to get it look the way that it  
>>> currently does on the mac, you need to plot each point twice, once  
>>> with no bg, and once with no line...
>>>
>>> 	Also, I don't think this is a critical bug.  It's just something  
>>> I noticed that behaves differently on what I have at work (Linux)  
>>> and what I have at home (mac).  I'm impressed with R, and am  
>>> thinking of getting more involved in the r-project community, so  
>>> figured I'd start with something I noticed was different across  
>>> platforms...
>>>
>>
>> Again, I think you are missing something - it behaves consistently  
>> on Linux and Mac in the latest release and it's not a bug.
> Again, I think it is a bug, though the root of the bug may actually  
> be in Apple's QUARTZ code.  One major reason I think it's a bug is  
> that for the way R currently draws it, there is NO-WAY for R to  
> create the plot that Adobe Reader shows in Quartz.  However, if R  
> draws it the way I think is right, then R can create both plots, as  
> the way it currently draws it can be emulated by plotting each point  
> twice (once for fill-only, and once for perimeter-only)...
> 	In short the bug is this...  I cannot make 2-color-points  
> (perimeter/fill), and make a point that looks exactly like it, but  
> is transparent...
>
>>
>>
>> Cheers,
>> Simon
>>
>>
>>
>>> On May 24, 2008, at 6:17 PM, Simon Urbanek wrote:
>>>
>>>> Brad,
>>>>
>>>> can you, please, let us know what is the "bug" here? If you paint  
>>>> semi-transparent line over the same filled shape (same vertices),  
>>>> clearly half of the line will be inside and and half outside of  
>>>> the shape, so each part will have a different color - that is the  
>>>> whole point of semi-transparency. Therefore I fail to see any bug  
>>>> or unexpected behavior here.
>>>>
>>>> Cheers,
>>>> Simon
>>>>
>>>>
>>>> On May 24, 2008, at 10:55 AM, brdvance at gmail.com wrote:
>>>>
>>>>> Full_Name: Brad Vance
>>>>> Version: 2.7.0
>>>>> OS: 10.5.2
>>>>> Submission from: (NULL) (71.123.195.202)
>>>>>
>>>>>
>>>>> Problem : When drawing transperant points with lines thick- 
>>>>> lines(lwd>1) + fill
>>>>> (pch=21-25), it looks like the line is transperantly overlayed  
>>>>> over the fill,
>>>>> making it look like 2-lines surround the fill (each a different  
>>>>> color).  I
>>>>> actually think that this is a nice OPTIONAL way to draw the  
>>>>> points (even as
>>>>> default), but since I could not discover how to turn it off, I  
>>>>> decided to issue
>>>>> the ticket.  In this option can see on the default-quartz device  
>>>>> as well as
>>>>> PDF-device.
>>>>>
>>>>> Solution : Have the entire point-object designed/drawn as if  
>>>>> there is
>>>>> no-transparency, then make the composite object transparent.    
>>>>> Optionally figure
>>>>> out an option to determine whether to apply transperancy as a  
>>>>> group (to the
>>>>> entire object) or separately (as it is now).
>>>>>
>>>>> Code :
>>>>>> df <- data.frame(X=rnorm(50),Y=rnorm(50))
>>>>>> plot 
>>>>>> (X 
>>>>>> ~ 
>>>>>> Y 
>>>>>> ,data 
>>>>>> = 
>>>>>> df 
>>>>>> ,pch 
>>>>>> =c(21,22,23,24,25),cex=5,col="#00FF0055",bg="#FF000055",lwd=6)
>>>>>
>>>>> Thanks,
>>>>> -Brad Vance
>>>>>
>>>>> ______________________________________________
>>>>> R-devel at r-project.org mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>
>>>>>
>>>>
>>>
>>
>

More information about the R-devel mailing list