Re: [Rd] is.vector could handle AsIs class better

[Jan Gorecki]

Thank you Gabriel,
Agree, although I think that could be relaxed in this single case and
AsIs class could be ignored.
Best,
Jan

On Sun, Mar 29, 2020 at 7:09 PM Gabriel Becker  wrote:
>
> Jan,
>
> I believe it's because it has "a non-NULL attribute other than names" as per 
> the documentation. In this case its class of "AsIs".
>
> Best,
> ~G
>
> On Sun, Mar 29, 2020 at 6:29 AM Jan Gorecki  wrote:
>>
>> Dear R-devel,
>>
>> AsIs class seems to be well handled by `typeof` and `mode` function.
>> Those two functions are being referred when explaining `is.vector`
>> behaviour in manual. Yet `is.vector` does not seem to be handling AsIs
>> class the same way.
>>
>> is.vector(1L)
>> #[1] TRUE
>> is.vector(I(1L))
>> #[1] FALSE
>>
>> Is there any reason behind this behaviour?
>> Could we have it supported so AsIs class is ignored when `is.vector`
>> is doing its job?
>>
>> Best Regards,
>> Jan Gorecki
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

[Iñaki Ucar]

On Mon, 30 Mar 2020 at 04:24, Paul Murrell  wrote:
>
> Hi
>
> I have created an R branch that contains a potential fix ...
>
> https://svn.r-project.org/R/branches/R-symfam/
>
> This allows, for example, ...
>
> cairo_pdf(symbolfamily="OpenSymbol")
>
> ... to specify that the OpenSymbol family should be used as the "symbol"
> font (e.g., for "plotmath") in R.

Will this be a default on Linux? Or are you planning any mechanism
(env variable, option...) to make it the default? Because, otherwise,
as pango is updated across distributions, R graphics will be "broken"
by default unless the user explicitly calls the graphics device in
that way to set that option, which I would say is uncommon.

Iñaki

> This is just a separate branch for now because, while I have tested it
> under Unbuntu 18.04 and Fedora 31, I cannot even build R for Windows
> (right now) or Mac (ever) and I do not want to drop a bomb on R-devel at
> this stage of the release process for R 4.0.0.
>
> The attached file contains at least an outline of steps required to do a
> minimal test if anyone wants to try the fix on Linux.
>
> cc'ing Simon and Jeroen in case they are able to help with checking that
> this builds and works on Mac and/or Windows.
>
> NOTEs:
> - 'symbolfamily' can only be specified when a graphics device is opened,
> and it is then fixed for that device.
> - on Windows, for cairo-based devices, the "symbol" font is still
> hard-coded as "Standard Symbols L"
>
>
> Paul
>
> On 30/03/20 8:15 am, Paul Murrell wrote:
> > Hi
> >
> > Thanks for your input on this Iñaki and Nicolas.
> >
> > I am starting testing an R fix for this problem today.
> >
> > As suggested, the plan is to allow the R user to specify a font family
> > other than "symbol" for plotmath output (or, more generally, in R
> > parlance, for 'font=5' or 'fontface=5') on a Cairo-based graphics device.
> >
> > Paul
> >
> >
> > On 27/03/20 11:30 pm, Iñaki Ucar wrote:
> >> On Wed, 25 Mar 2020 at 12:25, Nicolas Mailhot
> >>  wrote:
> >>>
> >>> 
> >>>
> >>> R brought this all on itself by hardcoding a Windows-only “Symbol” font
> >>> family name in its default conf. Linux systems are UTF-8 by default for
> >>> ~20 years now, they don’t need the forcing of magic font families to
> >>> handle symbols not present in the 8-bit legacy Windows encodings.
> >>>
> >>> The actual effect of this conf is not the selection of font files with
> >>> special and unusual symbols. It is to priorize fonts that match the
> >>> "Symbol" magic name. And those fonts are few and crumbling on Linux
> >>> systems, because no one has needed to bother with them since Linux
> >>> switched to UTF-8 last millenium.
> >>>
> >>> Just stop using “Symbol” in R and things will work a lot better.
> >>> Alternatively, prepare to maintain the “Symbol” aliasing stack in
> >>> fontconfig (and fight with wine for it), because *no* *one* *else*
> >>> *cares* about this legacy Windows-specific stuff.
> >>
> >> So, in the light of Nicolas' input (thanks!), I think that font
> >> selection should be fixed upstream in R. I'd be happy to put all this
> >> together in R's bugzilla, but I don't have an account. Could someone
> >> please invite me?
> >>
> >> Iñaki
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
>
> --
> Dr Paul Murrell
> Department of Statistics
> The University of Auckland
> Private Bag 92019
> Auckland
> New Zealand
> 64 9 3737599 x85392
> p...@stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/



-- 
Iñaki Úcar

On Mon, 30 Mar 2020 at 04:24, Paul Murrell  wrote:
>
> Hi
>
> I have created an R branch that contains a potential fix ...
>
> https://svn.r-project.org/R/branches/R-symfam/
>
> This allows, for example, ...
>
> cairo_pdf(symbolfamily="OpenSymbol")
>
> ... to specify that the OpenSymbol family should be used as the "symbol"
> font (e.g., for "plotmath") in R.
>
> This is just a separate branch for now because, while I have tested it
> under Unbuntu 18.04 and Fedora 31, I cannot even build R for Windows
> (right now) or Mac (ever) and I do not want to drop a bomb on R-devel at
> this stage of the release process for R 4.0.0.
>
> The attached file contains at least an outline of steps required to do a
> minimal test if anyone wants to try the fix on Linux.
>
> cc'ing Simon and Jeroen in case they are able to help with checking that
> this builds and works on Mac and/or Windows.
>
> NOTEs:
> - 'symbolfamily' can only be specified when a graphics device is opened,
> and it is then fixed for that device.
> - on Windows, for cairo-based devices, the "symbol" font is still
> hard-coded as "Standard Symbols L"
>
> Paul
>
> On 30/03/20 8:15 am, Paul Murrell wrote:
> > Hi
> >
> > Thanks for your input on this Iñaki and Nicolas.
> >
> > I am starting testing an R fix for this problem today.
> >
> > As suggested, the plan is to allow the R user to specify a font family
> > other than "symbol" fo

Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

[Nicolas Mailhot via R-devel]

Le lundi 30 mars 2020 à 15:24 +1300, Paul Murrell a écrit :
> Hi
> 
> I have created an R branch that contains a potential fix ...
> 
> https://svn.r-project.org/R/branches/R-symfam/
> 
> This allows, for example, ...
> 
> cairo_pdf(symbolfamily="OpenSymbol")
> 
> ... to specify that the OpenSymbol family should be used as the
> "symbol" font (e.g., for "plotmath") in R.

Thanks for looking at it!

But, really, there is no such thing as a Symbol font on Linux anymore.
Symbol is pre-unicode thinking. Most modern general-purpose unicode
fonts will include every codepoint Symbol ever shipped, and fontconfig
will fallback gracefully when that’s not the case (unless your
fontconfig integration is broken).

Just use the sans-serif or monospace fontconfig defaults. You don’t
need Symbol, or OpenSymbol, or any special font setup.

Symbol’s codepoint coverage is laughable by 2020’s UTF-8 standards.

Symbol << Normal Unicode font (DejaVu*) << Special math fonts (STIX2)

I you do advanced math stuff, you may need a special math font like
STIX, but that’s lights years more advanced than Symbol, and a general
purpose font like DejaVu has been shipping a MATH block for several
years now

Regards,

-- 
Nicolas Mailhot

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] status of Java & rJava?

[Spencer Graves]

  Tomas Kalibera kindly suggested I might have both 32- and 64-bit 
Java installed, and it might be accessing the 32-bit.  He further 
suggested:



   R CMD check Ecfun_0.2-4.tar.gz --no-multiarch


  That worked.  Thanks, Thomas.


  Spencer

On 2020-03-29 08:03, Spencer Graves wrote:
I spoke too soon in saying that everything worked with OpenJDK: "R CMD 
check Ecfun_0.2-4.tar.gz" using "https://github.com/sbgraves237/Ecfun"; 
worked fine on my Mac but failed with "error: DLL 'rJava' not found: 
maybe not installed for this architecture?" under Windows 10.  
"00install.out" and "Sys.getenv('PATH')" follow.  "library(rJava)" 
seemed to work, and "help(pac='rJava') displays 0.9-12.  Suggestions?  
Thanks, Spencer Graves



* installing *source* package 'Ecfun' ...
** using staged installation
** R
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
*** arch - i386
Error: package or namespace load failed for 'Ecfun':
 .onLoad failed in loadNamespace() for 'rJava', details:
  call: library.dynam("rJava", pkgname, libname)
  error: DLL 'rJava' not found: maybe not installed for this 
architecture?

Error: loading failed
Execution halted
*** arch - x64
ERROR: loading failed for 'i386'
* removing 'C:/Users/spenc/Documents/R/Ecfun/Ecfun.Rcheck/Ecfun'

##

> Sys.getenv('PATH')
[1] "C:\\Program Files\\R\\R-3.6.3\\bin\\x64;C:\\Program 
Files\\AdoptOpenJDK\\jdk-11.0.6.10-hotspot\\bin;C:\\Program 
Files\\Java\\jre1.8.0_241;C:\\Rtools\\bin;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\;C:\\WINDOWS\\System32\\OpenSSH\\;C:\\Program 
Files\\Microsoft VS Code\\bin;C:\\Program Files\\Git\\cmd;C:\\Program 
Files\\TortoiseSVN\\bin;c:\\programFiles\\ffmpeg\\ffmpeg-4.1\\;C:\\Program 
Files\\Pandoc\\;C:\\Program Files\\MiKTeX 
2.9\\miktex\\bin\\x64\\;C:\\Users\\spenc\\AppData\\Local\\Microsoft\\WindowsApps;C:\\Users\\spenc\\AppData\\Local\\GitHubDesktop\\bin;C:\\FFmpeg\\bin;C:\\RBuildTools\\3.5\\bin;C:\\Program 
Files\\R\\R-3.6.3\\bin;C:\\Users\\spenc\\AppData\\Local\\Microsoft\\WindowsApps;C:\\RBuildTools\\3.5\\;" 





On 2020-03-28 23:07, Prof Brian Ripley wrote:

On 29/03/2020 04:07, Simon Urbanek wrote:

Spencer,

you could argue that Java is dead since Oracle effectively killed it 
by removing all public downloads, but if you manage to get hold of a 
Java installation then it works just fine with R. To my best 
knowledge there has never been an issue if you installed rJava from 
source. macOS Catalina has made binary distributions impossible due 
to additional restrictions on run-time, but even that has been how 
solved with the release of rJava 0.9-12, so please make sure you use 
the latest rJava. In most cases that I have seen issues were caused 
by incorrect configuration (setting JAVA_HOME incorrectly [do NOT 
set it unless you know what you're doing!], not installing Java for 
the same architecture as R etc.). If you have any issues feel free 
to report them. rJava 0.9-12 has quite a few changes that try to 
detect user errors better and report them so I strongly suggest 
users to upgrade.


There is OpenJDK, and https://adoptopenjdk.net provides binaries for 
macOS, including the preferred Java 11 LTS.  I just re-checked that, 
and after


env 
JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home 
R CMD javareconf


I was able to install from source and check rJava 0.9-12 in 4.0.0 
alpha.  For the CRAN binary of 3.6.3 I had to make sure I was using 
clang 7: 'clang' defaults to that in the Apple CLT which does not 
support -fopenmp -- but the binary package just worked.


[All on Catalina.]


Thanks.  That worked on Catalina.  When installing OpenJDK on Windows 
10, The default for "Set JAVA_HOME" was 'X';  I changed that to 
install.  It didn't work at first, but did after I rebooted.



Thanks again to both Simon Urbanek and Prof. Ripley.  Spencer Graves

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] is.vector could handle AsIs class better

[William Dunlap via R-devel]

The use of the term 'vector' in R comes from S, where it was used, starting
in the latter part of the 1970s, to refer to the most primitive
(irreducible) parts of an object.  It has little to do with the
mathematical or physical concept of a vector and, in my opinion, should not
be used much by ordinary users.  In hindsight, it may have been better to
use some Joycean neologism instead of the word vector so people would not
have any notions of what it should do.

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Mon, Mar 30, 2020 at 2:26 AM Jan Gorecki  wrote:

> Thank you Gabriel,
> Agree, although I think that could be relaxed in this single case and
> AsIs class could be ignored.
> Best,
> Jan
>
> On Sun, Mar 29, 2020 at 7:09 PM Gabriel Becker 
> wrote:
> >
> > Jan,
> >
> > I believe it's because it has "a non-NULL attribute other than names" as
> per the documentation. In this case its class of "AsIs".
> >
> > Best,
> > ~G
> >
> > On Sun, Mar 29, 2020 at 6:29 AM Jan Gorecki 
> wrote:
> >>
> >> Dear R-devel,
> >>
> >> AsIs class seems to be well handled by `typeof` and `mode` function.
> >> Those two functions are being referred when explaining `is.vector`
> >> behaviour in manual. Yet `is.vector` does not seem to be handling AsIs
> >> class the same way.
> >>
> >> is.vector(1L)
> >> #[1] TRUE
> >> is.vector(I(1L))
> >> #[1] FALSE
> >>
> >> Is there any reason behind this behaviour?
> >> Could we have it supported so AsIs class is ignored when `is.vector`
> >> is doing its job?
> >>
> >> Best Regards,
> >> Jan Gorecki
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

[Paul Murrell]

Thanks Gabriel.  Sounds like both you and Brian can build the branch on 
Mac.  Just need to check that Windows builds before I commit to r-devel.


Paul

On 30/03/20 7:43 pm, Gabriel Becker wrote:
I do my devel/patch work on Mac so I can take a shot at testing your 
branch in the next couple days.


~G

On Sun, Mar 29, 2020 at 7:24 PM Paul Murrell > wrote:


Hi

I have created an R branch that contains a potential fix ...

https://svn.r-project.org/R/branches/R-symfam/

This allows, for example, ...

cairo_pdf(symbolfamily="OpenSymbol")

... to specify that the OpenSymbol family should be used as the
"symbol"
font (e.g., for "plotmath") in R.

This is just a separate branch for now because, while I have tested it
under Unbuntu 18.04 and Fedora 31, I cannot even build R for Windows
(right now) or Mac (ever) and I do not want to drop a bomb on
R-devel at
this stage of the release process for R 4.0.0.

The attached file contains at least an outline of steps required to
do a
minimal test if anyone wants to try the fix on Linux.

cc'ing Simon and Jeroen in case they are able to help with checking
that
this builds and works on Mac and/or Windows.

NOTEs:
- 'symbolfamily' can only be specified when a graphics device is
opened,
and it is then fixed for that device.
- on Windows, for cairo-based devices, the "symbol" font is still
hard-coded as "Standard Symbols L"

Paul

On 30/03/20 8:15 am, Paul Murrell wrote:
 > Hi
 >
 > Thanks for your input on this Iñaki and Nicolas.
 >
 > I am starting testing an R fix for this problem today.
 >
 > As suggested, the plan is to allow the R user to specify a font
family
 > other than "symbol" for plotmath output (or, more generally, in R
 > parlance, for 'font=5' or 'fontface=5') on a Cairo-based graphics
device.
 >
 > Paul
 >
 >
 > On 27/03/20 11:30 pm, Iñaki Ucar wrote:
 >> On Wed, 25 Mar 2020 at 12:25, Nicolas Mailhot
 >> mailto:nicolas.mail...@laposte.net>> wrote:
 >>>
 >>> 
 >>>
 >>> R brought this all on itself by hardcoding a Windows-only
“Symbol” font
 >>> family name in its default conf. Linux systems are UTF-8 by
default for
 >>> ~20 years now, they don’t need the forcing of magic font
families to
 >>> handle symbols not present in the 8-bit legacy Windows encodings.
 >>>
 >>> The actual effect of this conf is not the selection of font
files with
 >>> special and unusual symbols. It is to priorize fonts that match the
 >>> "Symbol" magic name. And those fonts are few and crumbling on Linux
 >>> systems, because no one has needed to bother with them since Linux
 >>> switched to UTF-8 last millenium.
 >>>
 >>> Just stop using “Symbol” in R and things will work a lot better.
 >>> Alternatively, prepare to maintain the “Symbol” aliasing stack in
 >>> fontconfig (and fight with wine for it), because *no* *one* *else*
 >>> *cares* about this legacy Windows-specific stuff.
 >>
 >> So, in the light of Nicolas' input (thanks!), I think that font
 >> selection should be fixed upstream in R. I'd be happy to put all
this
 >> together in R's bugzilla, but I don't have an account. Could someone
 >> please invite me?
 >>
 >> Iñaki
 >>
 >> __
 >> R-devel@r-project.org  mailing list
 >> https://stat.ethz.ch/mailman/listinfo/r-devel
 >>

-- 
Dr Paul Murrell

Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz 
http://www.stat.auckland.ac.nz/~paul/
__
R-devel@r-project.org  mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

[Paul Murrell]

Hi

On 30/03/20 10:43 pm, Iñaki Ucar wrote:

On Mon, 30 Mar 2020 at 04:24, Paul Murrell  wrote:


Hi

I have created an R branch that contains a potential fix ...

https://svn.r-project.org/R/branches/R-symfam/

This allows, for example, ...

cairo_pdf(symbolfamily="OpenSymbol")

... to specify that the OpenSymbol family should be used as the "symbol"
font (e.g., for "plotmath") in R.


Will this be a default on Linux? Or are you planning any mechanism
(env variable, option...) to make it the default? Because, otherwise,
as pango is updated across distributions, R graphics will be "broken"
by default unless the user explicitly calls the graphics device in
that way to set that option, which I would say is uncommon.


Good question.  Currently, for x11() (and png() etc) the default is 
taken from X11.options().  So it is possible to set this default for a 
session, or even for an installation via one of the ?Startup mechanisms 
(e.g., an R_HOME/etc/Rprofile.site file).


For svg(), cairo_pdf(), and cairo_ps(), the default is hard-coded in the 
function arguments, but I *think* they are used less as default graphics 
devices.


Another option would be to try to detect Fedora and set the default 
X11.options() differently there.  Two problems:  I am not sure there is 
a reliable R code chunk for detecting Fedora (sessionInfo()$running?) 
let alone Fedora >= 30;   what to set the default to?  (just has to be a 
font with a good Unicode coverage that is pretty much guaranteed to be 
in a default Fedora install).


Paul


Iñaki


This is just a separate branch for now because, while I have tested it
under Unbuntu 18.04 and Fedora 31, I cannot even build R for Windows
(right now) or Mac (ever) and I do not want to drop a bomb on R-devel at
this stage of the release process for R 4.0.0.

The attached file contains at least an outline of steps required to do a
minimal test if anyone wants to try the fix on Linux.

cc'ing Simon and Jeroen in case they are able to help with checking that
this builds and works on Mac and/or Windows.

NOTEs:
- 'symbolfamily' can only be specified when a graphics device is opened,
and it is then fixed for that device.
- on Windows, for cairo-based devices, the "symbol" font is still
hard-coded as "Standard Symbols L"


Paul

On 30/03/20 8:15 am, Paul Murrell wrote:

Hi

Thanks for your input on this Iñaki and Nicolas.

I am starting testing an R fix for this problem today.

As suggested, the plan is to allow the R user to specify a font family
other than "symbol" for plotmath output (or, more generally, in R
parlance, for 'font=5' or 'fontface=5') on a Cairo-based graphics device.

Paul


On 27/03/20 11:30 pm, Iñaki Ucar wrote:

On Wed, 25 Mar 2020 at 12:25, Nicolas Mailhot
 wrote:




R brought this all on itself by hardcoding a Windows-only “Symbol” font
family name in its default conf. Linux systems are UTF-8 by default for
~20 years now, they don’t need the forcing of magic font families to
handle symbols not present in the 8-bit legacy Windows encodings.

The actual effect of this conf is not the selection of font files with
special and unusual symbols. It is to priorize fonts that match the
"Symbol" magic name. And those fonts are few and crumbling on Linux
systems, because no one has needed to bother with them since Linux
switched to UTF-8 last millenium.

Just stop using “Symbol” in R and things will work a lot better.
Alternatively, prepare to maintain the “Symbol” aliasing stack in
fontconfig (and fight with wine for it), because *no* *one* *else*
*cares* about this legacy Windows-specific stuff.


So, in the light of Nicolas' input (thanks!), I think that font
selection should be fixed upstream in R. I'd be happy to put all this
together in R's bugzilla, but I don't have an account. Could someone
please invite me?

Iñaki

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/






--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

[Iñaki Ucar]

On Mon, 30 Mar 2020 at 22:41, Paul Murrell  wrote:
>
> Hi
>
> On 30/03/20 10:43 pm, Iñaki Ucar wrote:
> > On Mon, 30 Mar 2020 at 04:24, Paul Murrell  wrote:
> >>
> >> Hi
> >>
> >> I have created an R branch that contains a potential fix ...
> >>
> >> https://svn.r-project.org/R/branches/R-symfam/
> >>
> >> This allows, for example, ...
> >>
> >> cairo_pdf(symbolfamily="OpenSymbol")
> >>
> >> ... to specify that the OpenSymbol family should be used as the "symbol"
> >> font (e.g., for "plotmath") in R.
> >
> > Will this be a default on Linux? Or are you planning any mechanism
> > (env variable, option...) to make it the default? Because, otherwise,
> > as pango is updated across distributions, R graphics will be "broken"
> > by default unless the user explicitly calls the graphics device in
> > that way to set that option, which I would say is uncommon.
>
> Good question.  Currently, for x11() (and png() etc) the default is
> taken from X11.options().  So it is possible to set this default for a
> session, or even for an installation via one of the ?Startup mechanisms
> (e.g., an R_HOME/etc/Rprofile.site file).
>
> For svg(), cairo_pdf(), and cairo_ps(), the default is hard-coded in the
> function arguments, but I *think* they are used less as default graphics
> devices.
>
> Another option would be to try to detect Fedora and set the default
> X11.options() differently there.  Two problems:  I am not sure there is
> a reliable R code chunk for detecting Fedora (sessionInfo()$running?)
> let alone Fedora >= 30;   what to set the default to?  (just has to be a
> font with a good Unicode coverage that is pretty much guaranteed to be
> in a default Fedora install).

As per Nicolas' comment (I failed to include him in CC in my last
email, and he's not in this list, sorry for that) any font installed
by default would have good symbol coverage, so there's really no need
to set a different font for symbols. According again to Nicolas (he's
one of the font experts in Fedora), the "sans-serif" or "monospace"
fontconfig defaults would work out of the box, and if a symbol is not
available, fontconfig should fallback gracefully to another font.

So maybe instead of a new "symbolfamily" argument, maybe it's better
to just use the "family" for all characters, including symbols, on
Linux, and fontconfig should take care of everything (if I understood
correctly your explanation, Nicolas; please correct me if I'm wrong).

-- 
Iñaki Úcar

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

[Paul Murrell]

Hi

On 30/03/20 11:12 pm, Nicolas Mailhot wrote:

Le lundi 30 mars 2020 à 15:24 +1300, Paul Murrell a écrit :

Hi

I have created an R branch that contains a potential fix ...

https://svn.r-project.org/R/branches/R-symfam/

This allows, for example, ...

cairo_pdf(symbolfamily="OpenSymbol")

... to specify that the OpenSymbol family should be used as the
"symbol" font (e.g., for "plotmath") in R.


Thanks for looking at it!

But, really, there is no such thing as a Symbol font on Linux anymore.
Symbol is pre-unicode thinking. Most modern general-purpose unicode
fonts will include every codepoint Symbol ever shipped, and fontconfig
will fallback gracefully when that’s not the case (unless your
fontconfig integration is broken).


Yep, the "symbol" font is an (outdated) R "plotmath" concept, but one 
that would take a fair bit of surgery to remove.  R plotmath converts 
certain R expressions (in certain contexts) to code points in the Adobe 
Symbol Encoding (ASM), but for cairo-based devices, those are converted 
to UTF8 code points.



Just use the sans-serif or monospace fontconfig defaults. You don’t
need Symbol, or OpenSymbol, or any special font setup.


Agreed.  I got reasonable coverage from DejaVu Sans and FreeSerif. 
There are still a number of ASM code points that are not covered though, 
for example, ...


F8EBE6  # LEFT PAREN TOP# parenlefttp (CUS)
F8ECE7  # LEFT PAREN EXTENDER   # parenleftex (CUS)
F8EDE8  # LEFT PAREN BOTTOM # parenleftbt (CUS)

Even OpenSymbol is missing a few (though perhaps not very common ones) ...

F8E560  # RADICAL EXTENDER  # radicalex (CUS)
F8E6BD  # VERTICAL ARROW EXTENDER   # arrowvertex (CUS)
F8E7BE  # HORIZONTAL ARROW EXTENDER # arrowhorizex (CUS)
F6DAD2  # REGISTERED SIGN SERIF # registerserif (CUS)
F6D9D3  # COPYRIGHT SIGN SERIF  # copyrightserif (CUS)
F6DBD4  # TRADE MARK SIGN SERIF # trademarkserif (CUS)
F8E8E2  # REGISTERED SIGN SANS SERIF# registersans (CUS)
F8E9E3  # COPYRIGHT SIGN SANS SERIF # copyrightsans (CUS)
F8EAE4  # TRADE MARK SIGN SANS SERIF# trademarksans (CUS)


Symbol’s codepoint coverage is laughable by 2020’s UTF-8 standards.


Right, but there are still code points that are apparently not common in 
fonts with a very broad Unicode coverage.


I did find a TrueType font that I could add a Unicode cmap to that gave 
complete coverage pretty much all by itself, but it is not distributable.



Symbol << Normal Unicode font (DejaVu*) << Special math fonts (STIX2)

I you do advanced math stuff, you may need a special math font like
STIX, but that’s lights years more advanced than Symbol, and a general
purpose font like DejaVu has been shipping a MATH block for several
years now


Sure.  One way to look at the new 'symbolfamily' argument is that it 
allows us to tell R that the "symbol" font is just a normal font (for 
cairo-based graphics devices).


Paul
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

[Nicolas Mailhot via R-devel]

Le mardi 31 mars 2020 à 10:14 +1300, Paul Murrell a écrit :
> Hi
> 
> On 30/03/20 11:12 pm, Nicolas Mailhot wrote:
> > Le lundi 30 mars 2020 à 15:24 +1300, Paul Murrell a écrit :
> > > Hi
> > > 
> > > I have created an R branch that contains a potential fix ...
> > > 
> > > https://svn.r-project.org/R/branches/R-symfam/
> > > 
> > > This allows, for example, ...
> > > 
> > > cairo_pdf(symbolfamily="OpenSymbol")
> > > 
> > > ... to specify that the OpenSymbol family should be used as the
> > > "symbol" font (e.g., for "plotmath") in R.
> > 
> > Thanks for looking at it!
> > 
> > But, really, there is no such thing as a Symbol font on Linux
> > anymore.
> > Symbol is pre-unicode thinking. Most modern general-purpose unicode
> > fonts will include every codepoint Symbol ever shipped, and
> > fontconfig
> > will fallback gracefully when that’s not the case (unless your
> > fontconfig integration is broken).
> 
> Yep, the "symbol" font is an (outdated) R "plotmath" concept, but
> one 
> that would take a fair bit of surgery to remove.  R plotmath
> converts 
> certain R expressions (in certain contexts) to code points in the
> Adobe 
> Symbol Encoding (ASM), but for cairo-based devices, those are
> converted 
> to UTF8 code points.
> 
> > Just use the sans-serif or monospace fontconfig defaults. You don’t
> > need Symbol, or OpenSymbol, or any special font setup.
> 
> Agreed.  I got reasonable coverage from DejaVu Sans and FreeSerif. 
> There are still a number of ASM code points that are not covered
> though, 
> for example, ...
> 
> F8EB  E6  # LEFT PAREN TOP# parenlefttp (CUS)
> F8EC  E7  # LEFT PAREN EXTENDER   # parenleftex (CUS)
> F8ED  E8  # LEFT PAREN BOTTOM # parenleftbt (CUS)
> 
> Even OpenSymbol is missing a few (though perhaps not very common
> ones) ...

All the F8* codepoints are in the private use area. That means you
can’t rely on them existing in standard unicode fonts

You need to use correct Unicode values for things to work:
Ux239… for parenthesis, brackets

https://www.unicode.org/charts/PDF/U2300.pdf

> F8E6BD  # VERTICAL ARROW EXTENDER   # arrowvertex (CUS)
> F8E7BE  # HORIZONTAL ARROW EXTENDER # arrowhorizex (CUS)

and 23AF/23D0 for arrow extensions (though arrow font support seems
messy, probably because it sees little use; it’s a pity R comes so late
to the party, those are just lines, it would have been trivial to get
them into DejaVu before the project gone dormant). GFS NeoHellenic
(Math block) seems complete but it’s not a common font family.

> F6DAD2  # REGISTERED SIGN SERIF # registerserif (CUS)
> F6D9D3  # COPYRIGHT SIGN SERIF  # copyrightserif (CUS)
> F6DBD4  # TRADE MARK SIGN SERIF # trademarkserif (CUS)
> F8E8E2  # REGISTERED SIGN SANS SERIF# registersans (CUS)
> F8E9E3  # COPYRIGHT SIGN SANS SERIF # copyrightsans (CUS)
> F8EAE4  # TRADE MARK SIGN SANS SERIF# trademarksans (CUS)

Those are useless nowadays, just use normal
registered/copyright/trademark codepoints, and a font in the wished
style (serif sans serif, whatever looks nice to you)

Regards

-- 
Nicolas Mailhot

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

[Paul Murrell]

On 31/03/20 10:12 am, Iñaki Ucar wrote:

On Mon, 30 Mar 2020 at 22:41, Paul Murrell  wrote:


Hi

On 30/03/20 10:43 pm, Iñaki Ucar wrote:

On Mon, 30 Mar 2020 at 04:24, Paul Murrell  wrote:


Hi

I have created an R branch that contains a potential fix ...

https://svn.r-project.org/R/branches/R-symfam/

This allows, for example, ...

cairo_pdf(symbolfamily="OpenSymbol")

... to specify that the OpenSymbol family should be used as the "symbol"
font (e.g., for "plotmath") in R.


Will this be a default on Linux? Or are you planning any mechanism
(env variable, option...) to make it the default? Because, otherwise,
as pango is updated across distributions, R graphics will be "broken"
by default unless the user explicitly calls the graphics device in
that way to set that option, which I would say is uncommon.


Good question.  Currently, for x11() (and png() etc) the default is
taken from X11.options().  So it is possible to set this default for a
session, or even for an installation via one of the ?Startup mechanisms
(e.g., an R_HOME/etc/Rprofile.site file).

For svg(), cairo_pdf(), and cairo_ps(), the default is hard-coded in the
function arguments, but I *think* they are used less as default graphics
devices.

Another option would be to try to detect Fedora and set the default
X11.options() differently there.  Two problems:  I am not sure there is
a reliable R code chunk for detecting Fedora (sessionInfo()$running?)
let alone Fedora >= 30;   what to set the default to?  (just has to be a
font with a good Unicode coverage that is pretty much guaranteed to be
in a default Fedora install).


As per Nicolas' comment (I failed to include him in CC in my last
email, and he's not in this list, sorry for that) any font installed
by default would have good symbol coverage, so there's really no need
to set a different font for symbols. According again to Nicolas (he's
one of the font experts in Fedora), the "sans-serif" or "monospace"
fontconfig defaults would work out of the box, and if a symbol is not
available, fontconfig should fallback gracefully to another font.

So maybe instead of a new "symbolfamily" argument, maybe it's better
to just use the "family" for all characters, including symbols, on
Linux, and fontconfig should take care of everything (if I understood
correctly your explanation, Nicolas; please correct me if I'm wrong).


I think R will retain the idea of a separate symbol font in at least the 
short term because of backward compatibility and cross-platform support 
and support for a range of graphics devices.  So this fix is just for 
cairo-based devices on Linux at most (probably only Fedora).


So this becomes just a decision about user interface and default settings.

I did consider the option of allowing the existing "family" parameter to 
be length-two (with the second one being an optional symbol font 
specification), but because of the overlaps of X11/cairo and different 
cairo-based device interfaces, this became awkward.  Hence the separate 
"symbolfamily" interface.  And in any case, this still means a separate 
"symbol" font specification (for the reasons above).


Regarding changing to a default symbolfamily=family on Linux generally 
(rather than just on Fedora), I have at least one counter-example (my 
Ubuntu 18.04) that shows that this would degrade output significantly. 
For one, the symbols are a LOT uglier, plus there are some incorrect 
glyphs.  So I think we have to stay with treating Fedora as a special 
case for now.


Thanks for your point about just using symbolfamily=family as the Fedora 
default.  That seems reasonable (and definitely better than it just 
being completely broken!).


That does still leave the problem of how to set the default value for 
"symbolfamily" JUST on Fedora.   I am not convinced we can use R code to 
detect Fedora >= 30 reliably (but happy to learn otherwise).  Is it a 
possibility for the Fedora distribution to include a .Rprofile.site file 
that sets the X11.options() ?


Paul
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [FORGED] Re: Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

[Paul Murrell]

On 31/03/20 11:50 am, Nicolas Mailhot wrote:

Le mardi 31 mars 2020 à 10:14 +1300, Paul Murrell a écrit :

Hi

On 30/03/20 11:12 pm, Nicolas Mailhot wrote:

Le lundi 30 mars 2020 à 15:24 +1300, Paul Murrell a écrit :

Hi

I have created an R branch that contains a potential fix ...

https://svn.r-project.org/R/branches/R-symfam/

This allows, for example, ...

cairo_pdf(symbolfamily="OpenSymbol")

... to specify that the OpenSymbol family should be used as the
"symbol" font (e.g., for "plotmath") in R.


Thanks for looking at it!

But, really, there is no such thing as a Symbol font on Linux
anymore.
Symbol is pre-unicode thinking. Most modern general-purpose unicode
fonts will include every codepoint Symbol ever shipped, and
fontconfig
will fallback gracefully when that’s not the case (unless your
fontconfig integration is broken).


Yep, the "symbol" font is an (outdated) R "plotmath" concept, but
one
that would take a fair bit of surgery to remove.  R plotmath
converts
certain R expressions (in certain contexts) to code points in the
Adobe
Symbol Encoding (ASM), but for cairo-based devices, those are
converted
to UTF8 code points.


Just use the sans-serif or monospace fontconfig defaults. You don’t
need Symbol, or OpenSymbol, or any special font setup.


Agreed.  I got reasonable coverage from DejaVu Sans and FreeSerif.
There are still a number of ASM code points that are not covered
though,
for example, ...

F8EBE6  # LEFT PAREN TOP# parenlefttp (CUS)
F8ECE7  # LEFT PAREN EXTENDER   # parenleftex (CUS)
F8EDE8  # LEFT PAREN BOTTOM # parenleftbt (CUS)

Even OpenSymbol is missing a few (though perhaps not very common
ones) ...


All the F8* codepoints are in the private use area. That means you
can’t rely on them existing in standard unicode fonts

You need to use correct Unicode values for things to work:
Ux239… for parenthesis, brackets

https://www.unicode.org/charts/PDF/U2300.pdf


F8E6BD  # VERTICAL ARROW EXTENDER   # arrowvertex (CUS)
F8E7BE  # HORIZONTAL ARROW EXTENDER # arrowhorizex (CUS)


and 23AF/23D0 for arrow extensions (though arrow font support seems
messy, probably because it sees little use; it’s a pity R comes so late
to the party, those are just lines, it would have been trivial to get
them into DejaVu before the project gone dormant). GFS NeoHellenic
(Math block) seems complete but it’s not a common font family.


F6DAD2  # REGISTERED SIGN SERIF # registerserif (CUS)
F6D9D3  # COPYRIGHT SIGN SERIF  # copyrightserif (CUS)
F6DBD4  # TRADE MARK SIGN SERIF # trademarkserif (CUS)
F8E8E2  # REGISTERED SIGN SANS SERIF# registersans (CUS)
F8E9E3  # COPYRIGHT SIGN SANS SERIF # copyrightsans (CUS)
F8EAE4  # TRADE MARK SIGN SANS SERIF# trademarksans (CUS)


Those are useless nowadays, just use normal
registered/copyright/trademark codepoints, and a font in the wished
style (serif sans serif, whatever looks nice to you)

Regards


Thanks, that's useful.  For my own memory, this is the parenthesis block 
that might be useful ...


U+239b Sm LEFT PARENTHESIS UPPER HOOK ⎛
U+239c Sm LEFT PARENTHESIS EXTENSION ⎜
U+239d Sm LEFT PARENTHESIS LOWER HOOK ⎝
U+239e Sm RIGHT PARENTHESIS UPPER HOOK ⎞
U+239f Sm RIGHT PARENTHESIS EXTENSION ⎟
U+23a0 Sm RIGHT PARENTHESIS LOWER HOOK ⎠
U+23a1 Sm LEFT SQUARE BRACKET UPPER CORNER ⎡
U+23a2 Sm LEFT SQUARE BRACKET EXTENSION ⎢
U+23a3 Sm LEFT SQUARE BRACKET LOWER CORNER ⎣
U+23a4 Sm RIGHT SQUARE BRACKET UPPER CORNER ⎤
U+23a5 Sm RIGHT SQUARE BRACKET EXTENSION ⎥
U+23a6 Sm RIGHT SQUARE BRACKET LOWER CORNER ⎦
U+23a7 Sm LEFT CURLY BRACKET UPPER HOOK ⎧

However, the situation is still not completely straightforward.  The 
style of the symbols is also an issue and the DejaVu symbols are not as 
elegant as, say, the OpenSymbol symbols.  What makes things tricky is 
that, AFAICS, DejaVu has (TTX Unicode cmap output) ...




... while OpenSymbol has ...



... but neither has the other.  So we could not simply switch to 
standard Unicode code points because, while that would work with the 
"ugly" DejaVu glyphs, that would mean that we could not access the 
"pretty" OpenSymbol glyphs.


Paul
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel