[Rd] Recent changes to as.complex(NA_real_)
Revisiting this thread from April:
https://stat.ethz.ch/pipermail/r-devel/2023-April/082545.html
where the decision (not yet backported) was made for as.complex(NA_real_)
to give NA_complex_ instead of complex(r=NA_real_, i=0), to be consistent
with help("as.complex") and as.complex(NA) and as.complex(NA_integer_).
Was any consideration given to the alternative? That is, to changing
as.complex(NA) and as.complex(NA_integer_) to give complex(r=NA_real_, i=0),
consistent with as.complex(NA_real_), then amending help("as.complex")
accordingly?
The principle that Im(as.complex()) should
be zero is quite fundamental, in my view, hence the "new" behaviour seems
to really violate the principle of least surprise ...
Another (but maybe weaker) argument is that double->complex coercions happen
more often than logical->complex and integer->complex ones. Changing the
behaviour of the more frequently performed coercion is more likely to affect
code "out there".
Yet another argument is that one expects
identical(as.complex(NA_real_), NA_real_ + (0+0i))
to be TRUE, i.e., that coercing from double to complex is equivalent to
adding a complex zero. The new behaviour makes the above FALSE, since
NA_real_ + (0+0i) gives complex(r=NA_real_, i=0).
Having said that, one might also (but more naively) expect
identical(as.complex(as.double(NA_complex_)), NA_complex_)
to be TRUE. Under my proposal it continues to be FALSE. Well, I'd prefer
if it gave FALSE with a warning "imaginary parts discarded in coercion",
but it seems that as.double(complex(r=a, i=b)) never warns when either of
'a' and 'b' is NA_real_ or NaN, even where "information" {nonzero 'b'} is
clearly lost ...
Whatever decision is made about as.complex(NA_real_), maybe these points
should be weighed before it becomes part of R-release ...
Mikael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proposal: 'dev.capabilities()' can also query Unicode capabilities of current graphics device
Hi
The problem is what "supports UNICODE" means.
Graphics devices have a 'hasTextUTF8' boolean to indicate that ...
/* Some devices can plot UTF-8 text directly without converting
to the native encoding, e.g. windows(), quartz()
If this flag is true, all text *not in the symbol font* is sent
in UTF8 to the textUTF8/strWidthUTF8 entry points.
... and this is TRUE for the pdf() device for example.
It is also TRUE for Cairo devices, but the support is quite different
(as your examples demonstrate).
The Cairo devices do not alter UTF8 text at all, but the pdf() device
attempts to convert to a single-byte representation, which of course
will not always work.
The situation is only made more complex with the recent dev->glyph()
support because that offers another possible route to producing generic
UNICODE characters, including on pdf() devices.
Paul
On 21/09/23 04:12, Trevor Davis wrote:
> However, pdf() *does* support Unicode.
When I run a simple Unicode example like:
```
f <- tempfile(fileext = ".pdf")
pdf(f)
# U+2655 ♥ is found in most (all?) "sans" fonts like Arial, Dejavu Sans,
Arimo, etc.
# However, it is not in the Latin-1 encoding
grid::grid.text("\u2665")
dev.off()
```
I observe the following output:
```
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for <99>
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for <99>
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
```
When I open up the pdf file I just see three dots and not a heart as I
expected even if I open it up with `xpdf`.
In contrast the pdf generated by `cairo_pdf()` has a heart without
generating any warnings.
Avoiding such WARNINGs on certain CRAN check machines when I have a Unicode
graphics example that is worth including in a package's examples (if
protected by an appropriate if statement) is my main use case for such a
new feature. However, a new feature like `dev.capabilities()$unicode`
could certainly return something more sophisticated than a crude `TRUE` and
`FALSE` to distinguish between levels of Unicode support provided by
different graphics devices.
Thanks,
Trevor
On Wed, Sep 20, 2023 at 3:39 AM Martin Maechler
wrote:
> > Trevor Davis
> > on Thu, 31 Aug 2023 13:49:03 -0700 writes:
>
> > Hi,
>
> > It would be nice if `grDevices::dev.capabilities()` could also be
> used to
> > query whether the current graphics device supports Unicode. In such
> a case
> > I'd expect it to return `FALSE` if `pdf()` is the current graphics
> device
> > and something else for the Cairo or Quartz devices.
>
> > Thanks,
> > Trevor
>
> I agree in principle that this would be useful new feature for
> dev.capabilities()
>
> However, pdf() *does* support Unicode.
>
> The problem is that some pdf *viewers*,
> notably `evince` on Fedora Linux, for several years now,
> do *not* show *some* of the UTF-8 glyphs because they do not use
> the correct fonts {which *are* on the machine; good old `xpdf`
> does in that case show the glyphs}.
>
> Martin
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr Paul Murrell
Te Kura Tatauranga | Department of Statistics
Waipapa Taumata Rau | The University of Auckland
Private Bag 92019, Auckland 1142, New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proposal: 'dev.capabilities()' can also query Unicode capabilities of current graphics device
> However, pdf() *does* support Unicode.
When I run a simple Unicode example like:
```
f <- tempfile(fileext = ".pdf")
pdf(f)
# U+2655 ♥ is found in most (all?) "sans" fonts like Arial, Dejavu Sans,
Arimo, etc.
# However, it is not in the Latin-1 encoding
grid::grid.text("\u2665")
dev.off()
```
I observe the following output:
```
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for <99>
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for <99>
Warning in grid.Call.graphics(C_text, as.graphicsAnnot(x$label), x$x, x$y,
:
conversion failure on '♥' in 'mbcsToSbcs': dot substituted for
```
When I open up the pdf file I just see three dots and not a heart as I
expected even if I open it up with `xpdf`.
In contrast the pdf generated by `cairo_pdf()` has a heart without
generating any warnings.
Avoiding such WARNINGs on certain CRAN check machines when I have a Unicode
graphics example that is worth including in a package's examples (if
protected by an appropriate if statement) is my main use case for such a
new feature. However, a new feature like `dev.capabilities()$unicode`
could certainly return something more sophisticated than a crude `TRUE` and
`FALSE` to distinguish between levels of Unicode support provided by
different graphics devices.
Thanks,
Trevor
On Wed, Sep 20, 2023 at 3:39 AM Martin Maechler
wrote:
> > Trevor Davis
> > on Thu, 31 Aug 2023 13:49:03 -0700 writes:
>
> > Hi,
>
> > It would be nice if `grDevices::dev.capabilities()` could also be
> used to
> > query whether the current graphics device supports Unicode. In such
> a case
> > I'd expect it to return `FALSE` if `pdf()` is the current graphics
> device
> > and something else for the Cairo or Quartz devices.
>
> > Thanks,
> > Trevor
>
> I agree in principle that this would be useful new feature for
> dev.capabilities()
>
> However, pdf() *does* support Unicode.
>
> The problem is that some pdf *viewers*,
> notably `evince` on Fedora Linux, for several years now,
> do *not* show *some* of the UTF-8 glyphs because they do not use
> the correct fonts {which *are* on the machine; good old `xpdf`
> does in that case show the glyphs}.
>
> Martin
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proposal: 'dev.capabilities()' can also query Unicode capabilities of current graphics device
> Trevor Davis
> on Thu, 31 Aug 2023 13:49:03 -0700 writes:
> Hi,
> It would be nice if `grDevices::dev.capabilities()` could also be used to
> query whether the current graphics device supports Unicode. In such a
case
> I'd expect it to return `FALSE` if `pdf()` is the current graphics device
> and something else for the Cairo or Quartz devices.
> Thanks,
> Trevor
I agree in principle that this would be useful new feature for
dev.capabilities()
However, pdf() *does* support Unicode.
The problem is that some pdf *viewers*,
notably `evince` on Fedora Linux, for several years now,
do *not* show *some* of the UTF-8 glyphs because they do not use
the correct fonts {which *are* on the machine; good old `xpdf`
does in that case show the glyphs}.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
