[R-SIG-Mac] filled.contours and quartz() problem

[Joerg van den Hoff]

On Oct 30 2009 (Fri, 11:38), Simon Urbanek wrote:
>
> On Oct 30, 2009, at 11:05 , Joerg van den Hoff wrote:
>
>> has someone tried `filled.contours' with a `quartz' device?
>>
>> for me, contrary to using `X11' the display is corrupted by
>> visible rendering of all contour lines (looks as if `contour'
>> output is overlayed on the image with a thin line width in a
>> whitish color) as well as the pixel boundaries .
>>
>> the same happens, when I first draw to `X11' and then
>> `dev.print' to a pdf-file: with `gv' under X everything looks fine,
>> using `PreView' under Aqua looks like the `quartz' ouput.
>>
>> I know that Apple's pdf rendering engine used to be buggy (don't know
>> if this is still true) but I'm not sure that this is the reason.
>>
>> it seems that somehow gaps of one screen-pixel are introduced between
>> the constant-color patches.
>>
>> is this known? can something be done about this?
>>
>
> FAQ 12.10

thanks, I had'nt noticed that (quick googling before pestering the
mailing list did'nt show this :-))

but this was not quite/exclusively my problem: 12.10 addresses only `image' behaviour and
states that this is taken care of in quartz. for image, I can confirm
that this is true.  but not for `filled.contours': here `quartz' excatly
shows what I have described previously. 

but by using quartz(antialias=F) the problem indeed goes away.

so, indeed your answer solved my problem (thanks again). two last
remarks: should FAQ 12.10 not be augmented in order to state that use of
`filled.contour' with quartz requires to use quartz(antialias=F)?
it would be even better, I believe, to add an updated FAQ 12.10 to the
manpage of quartz (and maybe `pdf'), which after all is a more obvious place to look for a
solution than the FAQ (which e.g. escaped my attention altogether...)


joerg

>
>
>> regards,
>> joerg
>>
>>
>> ps: partly the problems occur with `image', too: here the quartz  
>> display
>> of looks ok, but viewing the same image after dev.print(pdf) shows the
>> image pixels separated by (I presume one) screen-pixel gaps. viewing
>> the pdf-output with `xpdf' on a linux machine showed similar  
>> behaviour.
>>
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac at stat.math.ethz.ch
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>
>>
>