[R-SIG-Mac] Dashed line not evenly separated

[Simon Urbanek]

FWIW I have checked the PDF, and it defines just one long path, so the rendering in Preview on macOS 11+ is simply wrong. It is rather curious that it is wrong in a way that is consistent with artificially breaking a path into subpaths internally - as if Apple was trying to do the same optimization that we did before and we do now know that it backfires ...

Cheers,
Simon


> On 25/02/2022, at 1:42 PM, Simon Urbanek <simon.urbanek using r-project.org> wrote:
> 
> John,
> 
> thanks, yes, interesting, the exact same PDF file looks just fine in macOS 10.15, but turns into solid line in macOS 11, so the problem has been introduced in PDF rendering between those macOS versions. I did not check the file so don't know whose rendering is correct.
> 
> As for the Quartz device (Jialin's original question), we are splitting lines with many points into subpaths which means the dashing gets re-started at the beginning of each subpath. The current threshold is 100:
> https://github.com/wch/r-source/blob/e38463ce746882af90a4a5dc7e6c588d61669585/src/library/grDevices/src/devQuartz.c#L1146
> 
> The theory was that no one in their right mind would create a line that has 100 points so close to each other that they wouldn't even span a dash. I guess that assumption was wrong ;). If I recall paths with too many points caused a problem long time ago, but it may no longer be the case so removing the threshold altogether is another option. I have done that in r81808 so you can try tonight's R-devel which should no longer exhibit that behavior, but see if that causes any performance issues.
> 
> Cheers,
> Simon
> 
> 
> 
>> On 25/02/2022, at 4:40 AM, John Fox <jfox using mcmaster.ca> wrote:
>> 
>> Hi Duncan,
>> 
>> Your message prompted me to investigate a bit further, and I discovered that the pdf looks right when I open it in Adobe Reader or Google Chrome but not in the (default) macOS Preview or Safari. That suggests to me that the problem may be in macOS.
>> 
>> Just in case it's relevant, my session info:
>> 
>>> sessionInfo()
>> R version 4.1.2 (2021-11-01)
>> Platform: aarch64-apple-darwin20 (64-bit)
>> Running under: macOS Monterey 12.1
>> 
>> Matrix products: default
>> BLAS: /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/lib/libRblas.0.dylib
>> LAPACK: /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/lib/libRlapack.dylib
>> 
>> locale:
>> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>> 
>> attached base packages:
>> [1] stats     graphics  grDevices utils     datasets  methods   base
>> 
>> loaded via a namespace (and not attached):
>> [1] compiler_4.1.2
>> 
>> 
>> Best,
>> John
>> 
>> 
>> On 2022-02-24 6:10 a.m., Duncan Murdoch wrote:
>>> On 23/02/2022 8:30 p.m., John Fox wrote:
>>>> Dear Ken,
>>>> 
>>>> Yes, but I believe that it *should* work even in a small window. For
>>>> example, the following produces a proper broken line on Windows but not
>>>> on macOS:
>>>> 
>>>>    pdf(width=3, height=3)
>>>>    plot(log10(1:1e4), lty = 2, type="l")
>>>>    dev.off()
>>>> 
>>> That one looks fine on my Mac in the PDF output, but not on screen using the default quartz() device.
>>> R version 4.1.0 Patched (2021-07-09 r80614)
>>> Platform: x86_64-apple-darwin17.0 (64-bit)
>>> Running under: macOS Catalina 10.15.7
>>> Duncan Murdoch
>> -- 
>> John Fox, Professor Emeritus
>> McMaster University
>> Hamilton, Ontario, Canada
>> web: https://socialsciences.mcmaster.ca/jfox/
>> 
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac using r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> 
> 
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac using r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>