Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Martin Maechler
>>>>> Paul Murrell
>>>>>     on Tue, 31 Mar 2020 09:41:30 +1300 writes:

    > Hi
    > On 30/03/20 10:43 pm, Iñaki Ucar wrote:
    >> On Mon, 30 Mar 2020 at 04:24, Paul Murrell <[hidden email]> 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;  

Yes,  sessionInfo()$running  is sufficient for both  *and*
there's a faster way in latest R versions, as I had the same
need and found sessionInfo() should be modularized here, and so
we have the  'osVersion'  variable since  R 3.6.0

----------------------------------------
> osVersion
[1] "Fedora 30 (Thirty)"
> find("osVersion")
[1] "package:utils"
>
----------------------------------------

{it is put into utils at package load time}

    > 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
    >>>>> <[hidden email]> wrote:
    >>>>>>
>>>>> <snip>
    >>>>>>
>>>>> 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
    >>>>>
    >>>>> ______________________________________________
    >>>>> [hidden email] 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
    >>> [hidden email]
    >>> 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
    > [hidden email]
    > http://www.stat.auckland.ac.nz/~paul/

    > ______________________________________________
    > [hidden email] mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

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

Paul Murrell-2


On 1/04/20 8:24 am, Martin Maechler wrote:

>>>>>> Paul Murrell
>>>>>>      on Tue, 31 Mar 2020 09:41:30 +1300 writes:
>
>      > Hi
>      > On 30/03/20 10:43 pm, Iñaki Ucar wrote:
>      >> On Mon, 30 Mar 2020 at 04:24, Paul Murrell <[hidden email]> 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;
>
> Yes,  sessionInfo()$running  is sufficient for both  *and*
> there's a faster way in latest R versions, as I had the same
> need and found sessionInfo() should be modularized here, and so
> we have the  'osVersion'  variable since  R 3.6.0
>
> ----------------------------------------
>> osVersion
> [1] "Fedora 30 (Thirty)"
>> find("osVersion")
> [1] "package:utils"
>>
> ----------------------------------------
>
> {it is put into utils at package load time}

Thanks Martin!

But I like Iñaki's suggestion (check Pango version) even more;  that
looks like it will be precise (compared to deparsing 'osVersion'), plus
it will nicely transition other Linux distros when they presumably
transition to the newer Pango.

Paul

>      > 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
>      >>>>> <[hidden email]> wrote:
>      >>>>>>
>>>>>> <snip>
>      >>>>>>
>>>>>> 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
>      >>>>>
>      >>>>> ______________________________________________
>      >>>>> [hidden email] 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
>      >>> [hidden email]
>      >>> 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
>      > [hidden email]
>      > http://www.stat.auckland.ac.nz/~paul/
>
>      > ______________________________________________
>      > [hidden email] 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
[hidden email]
http://www.stat.auckland.ac.nz/~paul/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

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

Paul Murrell-2
In reply to this post by R devel mailing list


On 31/03/20 8:04 pm, Nicolas Mailhot wrote:

> Le mardi 31 mars 2020 à 15:07 +1300, Paul Murrell a écrit :
>
>>
>
>> 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) ...
>
> Ah, the endless design discussions… Myself I prefer a consistent design
> like Dejavu, over cobbling symbols of different designs, because they
> used to be in separate fonts. Anyway:
>
>> <map code="0x239b" name="uni239B"/><!-- LEFT PARENTHESIS UPPER HOOK
>> -->
>>
>> ... while OpenSymbol has ...
>>
>> <map code="0xf8eb" name="parenlefttp"/><!-- ???? -->
>>
>> ... but neither has the other.
>
> OpenSymbol is incorrect (it suffers from the same pre-unicode bias as
> R). However, it is, to my knowledge, actively maintained. You can ask
> its upstream (LibreOffice) for Unicode conformance fixes if you find
> problems. Especially when it’s just fixing the map of an existing
> glyph, that should not be hard for them to fix. Anything PUA-related
> won’t interoperate well in an unicode world.
>
> (you can ask DejaVu too, maybe a request from a project like R will
> wake up its maintainers. But, that’s a long shot. DejaVu suffers from
> an almost done state without enough remaining work to interest
> designers).
>
> Regards,
>

Thanks again!  I will try contacting with those font projects.

In the meantime, I will look at allowing the user to select a
symbol-to-unicode mapping or a symbol-to-unicode-using-PUA mapping
alongside their choice of symbolfamily so that we can get a variety of
things to work for now.

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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

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

Paul Murrell-2
In reply to this post by Paul Murrell-2
Hi

The R branch ...

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

... is now set up so that it works "out of the box" on Fedora by setting
the default to be 'symbolfamily=cairoSymbolFont(family, usePUA=FALSE)'
when grSoftVersion()["pango"] is greater than "1.44".

This means that on Fedora 31 (at least on the Docker container I am
testing on) "sans"->"NimubusSans" is used as the symbol font by default
and R converts Adobe Symbol Encoding code points to non-PUA UTF8 code
points.  This is not the prettiest result, but it is a lot better than
the page full of missing glyphs that we had.

The default on less "bleeding edge" systems, e.g., my Ubuntu 18.04,
remains 'symbolfamily="Symbol"'.

The default on other platforms is supposed to be the same as it was, but
I need help to confirm that.  I have set up a github repo ...

https://github.com/pmur002/R-symfam-testing

... that describes how to test this on macOS and Windows if anyone has
time to do so.

I will start trying to set up a Windows test unless someone beats me to it.

Paul

On 30/03/20 3: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
>>> <[hidden email]> wrote:
>>>>
>>>> <snip>
>>>>
>>>> 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
>>>
>>> ______________________________________________
>>> [hidden email] 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
[hidden email]
http://www.stat.auckland.ac.nz/~paul/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

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

Iñaki Ucar
On Mon, 6 Apr 2020 at 04:59, Paul Murrell <[hidden email]> wrote:

>
> Hi
>
> The R branch ...
>
> https://svn.r-project.org/R/branches/R-symfam/
>
> ... is now set up so that it works "out of the box" on Fedora by setting
> the default to be 'symbolfamily=cairoSymbolFont(family, usePUA=FALSE)'
> when grSoftVersion()["pango"] is greater than "1.44".

That is awesome, thanks! Will you port this to the R-3-6-branch?

--
Iñaki Úcar

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

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

Paul Murrell-2


On 6/04/20 8:21 pm, Iñaki Ucar wrote:

> On Mon, 6 Apr 2020 at 04:59, Paul Murrell <[hidden email]> wrote:
>>
>> Hi
>>
>> The R branch ...
>>
>> https://svn.r-project.org/R/branches/R-symfam/
>>
>> ... is now set up so that it works "out of the box" on Fedora by setting
>> the default to be 'symbolfamily=cairoSymbolFont(family, usePUA=FALSE)'
>> when grSoftVersion()["pango"] is greater than "1.44".
>
> That is awesome, thanks! Will you port this to the R-3-6-branch?

I'll be very pleased if I can get this merged in time for R 4.0.0.

I am not sure if there will be any further patch releases in the R 3.6
series.  That would require wider discussion within R-core.
Paul
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
[hidden email]
http://www.stat.auckland.ac.nz/~paul/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

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

Paul Murrell-2
In reply to this post by Paul Murrell-2

The R-symfam branch (r78176) is now working, for my basic tests, on ...

Ubuntu (pango < 1.44)
Ubuntu (no pango)
Fedora (pango > 1.44)
Windows

I need help to confirm that this builds on macOS and that the basic
tests work ...

https://github.com/pmur002/R-symfam-testing

Brian has been helping with the build, but I am still looking for
someone who can run the tests please.  Happy to be fed PDF files to
scrutinize myself;  it's generating the PDF files on macOS that I need
help with.

Paul

On 6/04/20 2:59 pm, Paul Murrell wrote:

> Hi
>
> The R branch ...
>
> https://svn.r-project.org/R/branches/R-symfam/
>
> ... is now set up so that it works "out of the box" on Fedora by setting
> the default to be 'symbolfamily=cairoSymbolFont(family, usePUA=FALSE)'
> when grSoftVersion()["pango"] is greater than "1.44".
>
> This means that on Fedora 31 (at least on the Docker container I am
> testing on) "sans"->"NimubusSans" is used as the symbol font by default
> and R converts Adobe Symbol Encoding code points to non-PUA UTF8 code
> points.  This is not the prettiest result, but it is a lot better than
> the page full of missing glyphs that we had.
>
> The default on less "bleeding edge" systems, e.g., my Ubuntu 18.04,
> remains 'symbolfamily="Symbol"'.
>
> The default on other platforms is supposed to be the same as it was, but
> I need help to confirm that.  I have set up a github repo ...
>
> https://github.com/pmur002/R-symfam-testing
>
> ... that describes how to test this on macOS and Windows if anyone has
> time to do so.
>
> I will start trying to set up a Windows test unless someone beats me to it.
>
> Paul
>
> On 30/03/20 3: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
>>>> <[hidden email]> wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>> 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
>>>>
>>>> ______________________________________________
>>>> [hidden email] 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
[hidden email]
http://www.stat.auckland.ac.nz/~paul/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

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

Gabriel Becker-2
Paul et al,

I will try to do this tonight or tomorrow, though it will not be built with
th system tools because I have yet to get that tto work locally (spent a
good chunk of this morning trying).

I will send a separate messaage regarding those difficulties as well so
that we can at least confirm that they are due to a malconfiguration on my
part.

Best,
~G

On Tue, Apr 7, 2020 at 7:25 PM Paul Murrell <[hidden email]>
wrote:

>
> The R-symfam branch (r78176) is now working, for my basic tests, on ...
>
> Ubuntu (pango < 1.44)
> Ubuntu (no pango)
> Fedora (pango > 1.44)
> Windows
>
> I need help to confirm that this builds on macOS and that the basic
> tests work ...
>
> https://github.com/pmur002/R-symfam-testing
>
> Brian has been helping with the build, but I am still looking for
> someone who can run the tests please.  Happy to be fed PDF files to
> scrutinize myself;  it's generating the PDF files on macOS that I need
> help with.
>
> Paul
>
> On 6/04/20 2:59 pm, Paul Murrell wrote:
> > Hi
> >
> > The R branch ...
> >
> > https://svn.r-project.org/R/branches/R-symfam/
> >
> > ... is now set up so that it works "out of the box" on Fedora by setting
> > the default to be 'symbolfamily=cairoSymbolFont(family, usePUA=FALSE)'
> > when grSoftVersion()["pango"] is greater than "1.44".
> >
> > This means that on Fedora 31 (at least on the Docker container I am
> > testing on) "sans"->"NimubusSans" is used as the symbol font by default
> > and R converts Adobe Symbol Encoding code points to non-PUA UTF8 code
> > points.  This is not the prettiest result, but it is a lot better than
> > the page full of missing glyphs that we had.
> >
> > The default on less "bleeding edge" systems, e.g., my Ubuntu 18.04,
> > remains 'symbolfamily="Symbol"'.
> >
> > The default on other platforms is supposed to be the same as it was, but
> > I need help to confirm that.  I have set up a github repo ...
> >
> > https://github.com/pmur002/R-symfam-testing
> >
> > ... that describes how to test this on macOS and Windows if anyone has
> > time to do so.
> >
> > I will start trying to set up a Windows test unless someone beats me to
> it.
> >
> > Paul
> >
> > On 30/03/20 3: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
> >>>> <[hidden email]> wrote:
> >>>>>
> >>>>> <snip>
> >>>>>
> >>>>> 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
> >>>>
> >>>> ______________________________________________
> >>>> [hidden email] 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
> [hidden email]
> http://www.stat.auckland.ac.nz/~paul/
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

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

Gabriel Becker-2
Hi Paul,

So I've run the tests (and am  attaching all numerous pdfs here) but the
takeaway from what I can see is as follows:

raw, without specifying font family, "look good" (see plot*raw.pdf)  from
your branch (my eye is upset by the positioning of the phi symbol in plot2,
but I've confirmed that it looks the same generated from 3.5.1, so
that isn't your branch).

The various font family settings seem to work too, from what I can tell.
Both font families you suggested, however, Helvetica and Apple Symbols (the
s is important) have significantly incomplete coverage with PUA on. Apple
Symbols does have nearly complete coverage (though  to my eye the symbols
are all smaller...) with PUA turned off, but Helvetica remains very spotty,
with disabling PUA only modestly increasing it's coverage, and not in the
places that seem likely to matter.

I hope that helps,
~G

On Tue, Apr 7, 2020 at 8:59 PM Gabriel Becker <[hidden email]> wrote:

> Paul et al,
>
> I will try to do this tonight or tomorrow, though it will not be built
> with th system tools because I have yet to get that tto work locally (spent
> a good chunk of this morning trying).
>
> I will send a separate messaage regarding those difficulties as well so
> that we can at least confirm that they are due to a malconfiguration on my
> part.
>
> Best,
> ~G
>
> On Tue, Apr 7, 2020 at 7:25 PM Paul Murrell <[hidden email]>
> wrote:
>
>>
>> The R-symfam branch (r78176) is now working, for my basic tests, on ...
>>
>> Ubuntu (pango < 1.44)
>> Ubuntu (no pango)
>> Fedora (pango > 1.44)
>> Windows
>>
>> I need help to confirm that this builds on macOS and that the basic
>> tests work ...
>>
>> https://github.com/pmur002/R-symfam-testing
>>
>> Brian has been helping with the build, but I am still looking for
>> someone who can run the tests please.  Happy to be fed PDF files to
>> scrutinize myself;  it's generating the PDF files on macOS that I need
>> help with.
>>
>> Paul
>>
>> On 6/04/20 2:59 pm, Paul Murrell wrote:
>> > Hi
>> >
>> > The R branch ...
>> >
>> > https://svn.r-project.org/R/branches/R-symfam/
>> >
>> > ... is now set up so that it works "out of the box" on Fedora by
>> setting
>> > the default to be 'symbolfamily=cairoSymbolFont(family, usePUA=FALSE)'
>> > when grSoftVersion()["pango"] is greater than "1.44".
>> >
>> > This means that on Fedora 31 (at least on the Docker container I am
>> > testing on) "sans"->"NimubusSans" is used as the symbol font by default
>> > and R converts Adobe Symbol Encoding code points to non-PUA UTF8 code
>> > points.  This is not the prettiest result, but it is a lot better than
>> > the page full of missing glyphs that we had.
>> >
>> > The default on less "bleeding edge" systems, e.g., my Ubuntu 18.04,
>> > remains 'symbolfamily="Symbol"'.
>> >
>> > The default on other platforms is supposed to be the same as it was,
>> but
>> > I need help to confirm that.  I have set up a github repo ...
>> >
>> > https://github.com/pmur002/R-symfam-testing
>> >
>> > ... that describes how to test this on macOS and Windows if anyone has
>> > time to do so.
>> >
>> > I will start trying to set up a Windows test unless someone beats me to
>> it.
>> >
>> > Paul
>> >
>> > On 30/03/20 3: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
>> >>>> <[hidden email]> wrote:
>> >>>>>
>> >>>>> <snip>
>> >>>>>
>> >>>>> 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
>> >>>>
>> >>>> ______________________________________________
>> >>>> [hidden email] 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
>> [hidden email]
>> http://www.stat.auckland.ac.nz/~paul/
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

plot001apsymNoPUA.pdf (38K) Download Attachment
plot001raw.pdf (59K) Download Attachment
plot001helvNoPUA.pdf (48K) Download Attachment
plot001apsym.pdf (37K) Download Attachment
plot001helv.pdf (47K) Download Attachment
plot002apsymNoPUA.pdf (16K) Download Attachment
plot002apsym.pdf (16K) Download Attachment
plot002helvNoPUA.pdf (19K) Download Attachment
plot002helv.pdf (19K) Download Attachment
plot002raw.pdf (19K) Download Attachment
plot003apsym.pdf (30K) Download Attachment
plot003apsymNoPUA.pdf (30K) Download Attachment
plot003helv.pdf (37K) Download Attachment
plot003helvNoPUA.pdf (37K) Download Attachment
plot003raw.pdf (35K) Download Attachment
plot004apsym.pdf (21K) Download Attachment
plot004apsymNoPUA.pdf (21K) Download Attachment
plot004helv.pdf (28K) Download Attachment
plot004raw.pdf (27K) Download Attachment
plot004helvNoPUA.pdf (28K) Download Attachment
plot005apsym.pdf (17K) Download Attachment
plot005apsymNoPUA.pdf (17K) Download Attachment
plot005helv.pdf (19K) Download Attachment
plot005helvNoPUA.pdf (19K) Download Attachment
plot005raw.pdf (20K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Paul Murrell-2
In reply to this post by Gabriel Becker-2

Thanks Gabriel.  Simon and Brian are also helping out.  I will start a
speparate thread for the four of us to coordinate.

Paul

On 8/04/20 3:59 pm, Gabriel Becker wrote:

> Paul et al,
>
> I will try to do this tonight or tomorrow, though it will not be built
> with th system tools because I have yet to get that tto work locally
> (spent a good chunk of this morning trying).
>
> I will send a separate messaage regarding those difficulties as well so
> that we can at least confirm that they are due to a malconfiguration on
> my part.
>
> Best,
> ~G
>
> On Tue, Apr 7, 2020 at 7:25 PM Paul Murrell <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     The R-symfam branch (r78176) is now working, for my basic tests, on ...
>
>     Ubuntu (pango < 1.44)
>     Ubuntu (no pango)
>     Fedora (pango > 1.44)
>     Windows
>
>     I need help to confirm that this builds on macOS and that the basic
>     tests work ...
>
>     https://github.com/pmur002/R-symfam-testing
>
>     Brian has been helping with the build, but I am still looking for
>     someone who can run the tests please.  Happy to be fed PDF files to
>     scrutinize myself;  it's generating the PDF files on macOS that I need
>     help with.
>
>     Paul
>
>     On 6/04/20 2:59 pm, Paul Murrell wrote:
>      > Hi
>      >
>      > The R branch ...
>      >
>      > https://svn.r-project.org/R/branches/R-symfam/
>      >
>      > ... is now set up so that it works "out of the box" on Fedora by
>     setting
>      > the default to be 'symbolfamily=cairoSymbolFont(family,
>     usePUA=FALSE)'
>      > when grSoftVersion()["pango"] is greater than "1.44".
>      >
>      > This means that on Fedora 31 (at least on the Docker container I am
>      > testing on) "sans"->"NimubusSans" is used as the symbol font by
>     default
>      > and R converts Adobe Symbol Encoding code points to non-PUA UTF8
>     code
>      > points.  This is not the prettiest result, but it is a lot better
>     than
>      > the page full of missing glyphs that we had.
>      >
>      > The default on less "bleeding edge" systems, e.g., my Ubuntu 18.04,
>      > remains 'symbolfamily="Symbol"'.
>      >
>      > The default on other platforms is supposed to be the same as it
>     was, but
>      > I need help to confirm that.  I have set up a github repo ...
>      >
>      > https://github.com/pmur002/R-symfam-testing
>      >
>      > ... that describes how to test this on macOS and Windows if
>     anyone has
>      > time to do so.
>      >
>      > I will start trying to set up a Windows test unless someone beats
>     me to it.
>      >
>      > Paul
>      >
>      > On 30/03/20 3: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
>      >>>> <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      >>>>>
>      >>>>> <snip>
>      >>>>>
>      >>>>> 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
>      >>>>
>      >>>> ______________________________________________
>      >>>> [hidden email] <mailto:[hidden email]> 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
>     [hidden email] <mailto:[hidden email]>
>     http://www.stat.auckland.ac.nz/~paul/
>
>     ______________________________________________
>     [hidden email] <mailto:[hidden email]> 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
[hidden email]
http://www.stat.auckland.ac.nz/~paul/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

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

Paul Murrell-2
In reply to this post by Gabriel Becker-2

Thanks for this Gabriel - extremely useful.
Those results look pretty good.

Paul

On 8/04/20 9:55 pm, Gabriel Becker wrote:

> Hi Paul,
>
> So I've run the tests (and am  attaching all numerous pdfs here) but the
> takeaway from what I can see is as follows:
>
> raw, without specifying font family, "look good" (see plot*raw.pdf)  
> from your branch (my eye is upset by the positioning of the phi symbol
> in plot2, but I've confirmed that it looks the same generated from
> 3.5.1, so that isn't your branch).
>
> The various font family settings seem to work too, from what I can tell.
> Both font families you suggested, however, Helvetica and Apple Symbols
> (the s is important) have significantly incomplete coverage with PUA on.
> Apple Symbols does have nearly complete coverage (though  to my eye the
> symbols are all smaller...) with PUA turned off, but Helvetica remains
> very spotty, with disabling PUA only modestly increasing it's coverage,
> and not in the places that seem likely to matter.
>
> I hope that helps,
> ~G
>
> On Tue, Apr 7, 2020 at 8:59 PM Gabriel Becker <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Paul et al,
>
>     I will try to do this tonight or tomorrow, though it will not be
>     built with th system tools because I have yet to get that tto work
>     locally (spent a good chunk of this morning trying).
>
>     I will send a separate messaage regarding those difficulties as well
>     so that we can at least confirm that they are due to a
>     malconfiguration on my part.
>
>     Best,
>     ~G
>
>     On Tue, Apr 7, 2020 at 7:25 PM Paul Murrell
>     <[hidden email] <mailto:[hidden email]>> wrote:
>
>
>         The R-symfam branch (r78176) is now working, for my basic tests,
>         on ...
>
>         Ubuntu (pango < 1.44)
>         Ubuntu (no pango)
>         Fedora (pango > 1.44)
>         Windows
>
>         I need help to confirm that this builds on macOS and that the basic
>         tests work ...
>
>         https://github.com/pmur002/R-symfam-testing
>
>         Brian has been helping with the build, but I am still looking for
>         someone who can run the tests please.  Happy to be fed PDF files to
>         scrutinize myself;  it's generating the PDF files on macOS that
>         I need
>         help with.
>
>         Paul
>
>         On 6/04/20 2:59 pm, Paul Murrell wrote:
>          > Hi
>          >
>          > The R branch ...
>          >
>          > https://svn.r-project.org/R/branches/R-symfam/
>          >
>          > ... is now set up so that it works "out of the box" on Fedora
>         by setting
>          > the default to be 'symbolfamily=cairoSymbolFont(family,
>         usePUA=FALSE)'
>          > when grSoftVersion()["pango"] is greater than "1.44".
>          >
>          > This means that on Fedora 31 (at least on the Docker
>         container I am
>          > testing on) "sans"->"NimubusSans" is used as the symbol font
>         by default
>          > and R converts Adobe Symbol Encoding code points to non-PUA
>         UTF8 code
>          > points.  This is not the prettiest result, but it is a lot
>         better than
>          > the page full of missing glyphs that we had.
>          >
>          > The default on less "bleeding edge" systems, e.g., my Ubuntu
>         18.04,
>          > remains 'symbolfamily="Symbol"'.
>          >
>          > The default on other platforms is supposed to be the same as
>         it was, but
>          > I need help to confirm that.  I have set up a github repo ...
>          >
>          > https://github.com/pmur002/R-symfam-testing
>          >
>          > ... that describes how to test this on macOS and Windows if
>         anyone has
>          > time to do so.
>          >
>          > I will start trying to set up a Windows test unless someone
>         beats me to it.
>          >
>          > Paul
>          >
>          > On 30/03/20 3: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
>          >>>> <[hidden email]
>         <mailto:[hidden email]>> wrote:
>          >>>>>
>          >>>>> <snip>
>          >>>>>
>          >>>>> 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
>          >>>>
>          >>>> ______________________________________________
>          >>>> [hidden email] <mailto:[hidden email]>
>         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
>         [hidden email] <mailto:[hidden email]>
>         http://www.stat.auckland.ac.nz/~paul/
>
>         ______________________________________________
>         [hidden email] <mailto:[hidden email]> 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
[hidden email]
http://www.stat.auckland.ac.nz/~paul/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

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

R devel mailing list
In reply to this post by Gabriel Becker-2
Le mercredi 08 avril 2020 à 02:55 -0700, Gabriel Becker a écrit :
> Hi Paul,

Hi Gabriel,

Thanks a lot for the testing.

> The various font family settings seem to work too, from what I can
> tell. Both font families you suggested, however, Helvetica and Apple
> Symbols (the s is important) have significantly incomplete coverage
> with PUA on.

That is to be expected, the AMS symbol dump in PUA space was a quick
hack to make pre-unicode symbols available in an unicode world, pending
their normalisation.

That standardisation is long past (IIRC it occured by unicode 3.2
released in March 2002), so no newly created/updated font family is
going to place those symbols in PUA anymore.

Now adding the AMS symbols to new fonts has been slow, due to the large
amount of software hardcoding Symbol (and equivallent) and masking the
actual glyph userbase to font makers. It will accelerate with more apps
expecting plain unicode by default.

Thanks for the testing!

Regards,

--
Nicolas Mailhot

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

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

Kenny Bell-2
Hi all,

I have found after upgrading to R 4.0.0 (among other upgrades so this may
not be the cause) that the degree symbol doesn't work correctly on Ubuntu
18.04. Googling brought me to this thread that appears related.

I tried running:
cairo_pdf()
plot.new(); text(0.5,0.5, bquote(120*degree*N), cex=5)
dev.off()

and the ubuntu plot has the degree symbol vertically in the center of the
line. The Windows one correctly shows as superscript.

Anyone else see this behaviour?

Cheers,
Kenny

On Fri, Apr 10, 2020 at 3:36 AM Nicolas Mailhot via R-devel <
[hidden email]> wrote:

> Le mercredi 08 avril 2020 à 02:55 -0700, Gabriel Becker a écrit :
> > Hi Paul,
>
> Hi Gabriel,
>
> Thanks a lot for the testing.
>
> > The various font family settings seem to work too, from what I can
> > tell. Both font families you suggested, however, Helvetica and Apple
> > Symbols (the s is important) have significantly incomplete coverage
> > with PUA on.
>
> That is to be expected, the AMS symbol dump in PUA space was a quick
> hack to make pre-unicode symbols available in an unicode world, pending
> their normalisation.
>
> That standardisation is long past (IIRC it occured by unicode 3.2
> released in March 2002), so no newly created/updated font family is
> going to place those symbols in PUA anymore.
>
> Now adding the AMS symbols to new fonts has been slow, due to the large
> amount of software hardcoding Symbol (and equivallent) and masking the
> actual glyph userbase to font makers. It will accelerate with more apps
> expecting plain unicode by default.
>
> Thanks for the testing!
>
> Regards,
>
> --
> Nicolas Mailhot
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Rplot001_ubuntu.pdf (8K) Download Attachment
Rplot001_windows.pdf (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Paul Murrell-2

I am not seeing that problem on my 18.04 ...

 > sessionInfo()
R version 4.0.0 Patched (2020-05-12 r78431)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.4 LTS

Matrix products: default
BLAS:   /home/pmur002/R/R-4-0-branch/BUILD/lib/libRblas.so
LAPACK: /home/pmur002/R/R-4-0-branch/BUILD/lib/libRlapack.so

locale:
  [1] LC_CTYPE=en_NZ.UTF-8       LC_NUMERIC=C
  [3] LC_TIME=en_NZ.UTF-8        LC_COLLATE=en_NZ.UTF-8
  [5] LC_MONETARY=en_NZ.UTF-8    LC_MESSAGES=en_NZ.UTF-8
  [7] LC_PAPER=en_NZ.UTF-8       LC_NAME=C
  [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.0.0

Paul

On 26/05/20 2:21 pm, Kenny Bell wrote:

> Hi all,
>
> I have found after upgrading to R 4.0.0 (among other upgrades so this may
> not be the cause) that the degree symbol doesn't work correctly on Ubuntu
> 18.04. Googling brought me to this thread that appears related.
>
> I tried running:
> cairo_pdf()
> plot.new(); text(0.5,0.5, bquote(120*degree*N), cex=5)
> dev.off()
>
> and the ubuntu plot has the degree symbol vertically in the center of the
> line. The Windows one correctly shows as superscript.
>
> Anyone else see this behaviour?
>
> Cheers,
> Kenny
>
> On Fri, Apr 10, 2020 at 3:36 AM Nicolas Mailhot via R-devel <
> [hidden email]> wrote:
>
>> Le mercredi 08 avril 2020 à 02:55 -0700, Gabriel Becker a écrit :
>>> Hi Paul,
>>
>> Hi Gabriel,
>>
>> Thanks a lot for the testing.
>>
>>> The various font family settings seem to work too, from what I can
>>> tell. Both font families you suggested, however, Helvetica and Apple
>>> Symbols (the s is important) have significantly incomplete coverage
>>> with PUA on.
>>
>> That is to be expected, the AMS symbol dump in PUA space was a quick
>> hack to make pre-unicode symbols available in an unicode world, pending
>> their normalisation.
>>
>> That standardisation is long past (IIRC it occured by unicode 3.2
>> released in March 2002), so no newly created/updated font family is
>> going to place those symbols in PUA anymore.
>>
>> Now adding the AMS symbols to new fonts has been slow, due to the large
>> amount of software hardcoding Symbol (and equivallent) and masking the
>> actual glyph userbase to font makers. It will accelerate with more apps
>> expecting plain unicode by default.
>>
>> Thanks for the testing!
>>
>> Regards,
>>
>> --
>> Nicolas Mailhot
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>> ______________________________________________
>> [hidden email] 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
[hidden email]
http://www.stat.auckland.ac.nz/~paul/

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

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

Kenny Bell-2
Hi Paul,

I tried downgrading to R 3.4.4 and I still see the problem. I also have a
conda environment that doesn't exhibit the problem so it's something
environmental.

Any tips for possible solutions/troubleshooting would be appreciated!

Cheers,
Kenny

On Tue, May 26, 2020 at 3:09 PM Paul Murrell <[hidden email]>
wrote:

>
> I am not seeing that problem on my 18.04 ...
>
>  > sessionInfo()
> R version 4.0.0 Patched (2020-05-12 r78431)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 18.04.4 LTS
>
> Matrix products: default
> BLAS:   /home/pmur002/R/R-4-0-branch/BUILD/lib/libRblas.so
> LAPACK: /home/pmur002/R/R-4-0-branch/BUILD/lib/libRlapack.so
>
> locale:
>   [1] LC_CTYPE=en_NZ.UTF-8       LC_NUMERIC=C
>   [3] LC_TIME=en_NZ.UTF-8        LC_COLLATE=en_NZ.UTF-8
>   [5] LC_MONETARY=en_NZ.UTF-8    LC_MESSAGES=en_NZ.UTF-8
>   [7] LC_PAPER=en_NZ.UTF-8       LC_NAME=C
>   [9] LC_ADDRESS=C               LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] compiler_4.0.0
>
> Paul
>
> On 26/05/20 2:21 pm, Kenny Bell wrote:
> > Hi all,
> >
> > I have found after upgrading to R 4.0.0 (among other upgrades so this may
> > not be the cause) that the degree symbol doesn't work correctly on Ubuntu
> > 18.04. Googling brought me to this thread that appears related.
> >
> > I tried running:
> > cairo_pdf()
> > plot.new(); text(0.5,0.5, bquote(120*degree*N), cex=5)
> > dev.off()
> >
> > and the ubuntu plot has the degree symbol vertically in the center of the
> > line. The Windows one correctly shows as superscript.
> >
> > Anyone else see this behaviour?
> >
> > Cheers,
> > Kenny
> >
> > On Fri, Apr 10, 2020 at 3:36 AM Nicolas Mailhot via R-devel <
> > [hidden email]> wrote:
> >
> >> Le mercredi 08 avril 2020 à 02:55 -0700, Gabriel Becker a écrit :
> >>> Hi Paul,
> >>
> >> Hi Gabriel,
> >>
> >> Thanks a lot for the testing.
> >>
> >>> The various font family settings seem to work too, from what I can
> >>> tell. Both font families you suggested, however, Helvetica and Apple
> >>> Symbols (the s is important) have significantly incomplete coverage
> >>> with PUA on.
> >>
> >> That is to be expected, the AMS symbol dump in PUA space was a quick
> >> hack to make pre-unicode symbols available in an unicode world, pending
> >> their normalisation.
> >>
> >> That standardisation is long past (IIRC it occured by unicode 3.2
> >> released in March 2002), so no newly created/updated font family is
> >> going to place those symbols in PUA anymore.
> >>
> >> Now adding the AMS symbols to new fonts has been slow, due to the large
> >> amount of software hardcoding Symbol (and equivallent) and masking the
> >> actual glyph userbase to font makers. It will accelerate with more apps
> >> expecting plain unicode by default.
> >>
> >> Thanks for the testing!
> >>
> >> Regards,
> >>
> >> --
> >> Nicolas Mailhot
> >>
> >> ______________________________________________
> >> [hidden email] mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >>
> >> ______________________________________________
> >> [hidden email] 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
> [hidden email]
> http://www.stat.auckland.ac.nz/~paul/
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

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

Kenny Bell-2
I was actually able to reproduce this on a relatively fresh install of
18.04 (a virtualbox). Paul, did you run apt update && apt upgrade before
trying to reproduce?

On Tue, May 26, 2020 at 4:36 PM Kenny Bell <[hidden email]> wrote:

> Hi Paul,
>
> I tried downgrading to R 3.4.4 and I still see the problem. I also have a
> conda environment that doesn't exhibit the problem so it's something
> environmental.
>
> Any tips for possible solutions/troubleshooting would be appreciated!
>
> Cheers,
> Kenny
>
> On Tue, May 26, 2020 at 3:09 PM Paul Murrell <[hidden email]>
> wrote:
>
>>
>> I am not seeing that problem on my 18.04 ...
>>
>>  > sessionInfo()
>> R version 4.0.0 Patched (2020-05-12 r78431)
>> Platform: x86_64-pc-linux-gnu (64-bit)
>> Running under: Ubuntu 18.04.4 LTS
>>
>> Matrix products: default
>> BLAS:   /home/pmur002/R/R-4-0-branch/BUILD/lib/libRblas.so
>> LAPACK: /home/pmur002/R/R-4-0-branch/BUILD/lib/libRlapack.so
>>
>> locale:
>>   [1] LC_CTYPE=en_NZ.UTF-8       LC_NUMERIC=C
>>   [3] LC_TIME=en_NZ.UTF-8        LC_COLLATE=en_NZ.UTF-8
>>   [5] LC_MONETARY=en_NZ.UTF-8    LC_MESSAGES=en_NZ.UTF-8
>>   [7] LC_PAPER=en_NZ.UTF-8       LC_NAME=C
>>   [9] LC_ADDRESS=C               LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] stats     graphics  grDevices utils     datasets  methods   base
>>
>> loaded via a namespace (and not attached):
>> [1] compiler_4.0.0
>>
>> Paul
>>
>> On 26/05/20 2:21 pm, Kenny Bell wrote:
>> > Hi all,
>> >
>> > I have found after upgrading to R 4.0.0 (among other upgrades so this
>> may
>> > not be the cause) that the degree symbol doesn't work correctly on
>> Ubuntu
>> > 18.04. Googling brought me to this thread that appears related.
>> >
>> > I tried running:
>> > cairo_pdf()
>> > plot.new(); text(0.5,0.5, bquote(120*degree*N), cex=5)
>> > dev.off()
>> >
>> > and the ubuntu plot has the degree symbol vertically in the center of
>> the
>> > line. The Windows one correctly shows as superscript.
>> >
>> > Anyone else see this behaviour?
>> >
>> > Cheers,
>> > Kenny
>> >
>> > On Fri, Apr 10, 2020 at 3:36 AM Nicolas Mailhot via R-devel <
>> > [hidden email]> wrote:
>> >
>> >> Le mercredi 08 avril 2020 à 02:55 -0700, Gabriel Becker a écrit :
>> >>> Hi Paul,
>> >>
>> >> Hi Gabriel,
>> >>
>> >> Thanks a lot for the testing.
>> >>
>> >>> The various font family settings seem to work too, from what I can
>> >>> tell. Both font families you suggested, however, Helvetica and Apple
>> >>> Symbols (the s is important) have significantly incomplete coverage
>> >>> with PUA on.
>> >>
>> >> That is to be expected, the AMS symbol dump in PUA space was a quick
>> >> hack to make pre-unicode symbols available in an unicode world, pending
>> >> their normalisation.
>> >>
>> >> That standardisation is long past (IIRC it occured by unicode 3.2
>> >> released in March 2002), so no newly created/updated font family is
>> >> going to place those symbols in PUA anymore.
>> >>
>> >> Now adding the AMS symbols to new fonts has been slow, due to the large
>> >> amount of software hardcoding Symbol (and equivallent) and masking the
>> >> actual glyph userbase to font makers. It will accelerate with more apps
>> >> expecting plain unicode by default.
>> >>
>> >> Thanks for the testing!
>> >>
>> >> Regards,
>> >>
>> >> --
>> >> Nicolas Mailhot
>> >>
>> >> ______________________________________________
>> >> [hidden email] mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>> >>
>> >>
>> >> ______________________________________________
>> >> [hidden email] 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
>> [hidden email]
>> http://www.stat.auckland.ac.nz/~paul/
>>
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

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

Kenny Bell-2
I can also confirm that the latest  https://hub.docker.com/_/r-base has the
correct behaviour.

On Tue, May 26, 2020 at 5:05 PM Kenny Bell <[hidden email]> wrote:

> I was actually able to reproduce this on a relatively fresh install of
> 18.04 (a virtualbox). Paul, did you run apt update && apt upgrade before
> trying to reproduce?
>
> On Tue, May 26, 2020 at 4:36 PM Kenny Bell <[hidden email]> wrote:
>
>> Hi Paul,
>>
>> I tried downgrading to R 3.4.4 and I still see the problem. I also have a
>> conda environment that doesn't exhibit the problem so it's something
>> environmental.
>>
>> Any tips for possible solutions/troubleshooting would be appreciated!
>>
>> Cheers,
>> Kenny
>>
>> On Tue, May 26, 2020 at 3:09 PM Paul Murrell <[hidden email]>
>> wrote:
>>
>>>
>>> I am not seeing that problem on my 18.04 ...
>>>
>>>  > sessionInfo()
>>> R version 4.0.0 Patched (2020-05-12 r78431)
>>> Platform: x86_64-pc-linux-gnu (64-bit)
>>> Running under: Ubuntu 18.04.4 LTS
>>>
>>> Matrix products: default
>>> BLAS:   /home/pmur002/R/R-4-0-branch/BUILD/lib/libRblas.so
>>> LAPACK: /home/pmur002/R/R-4-0-branch/BUILD/lib/libRlapack.so
>>>
>>> locale:
>>>   [1] LC_CTYPE=en_NZ.UTF-8       LC_NUMERIC=C
>>>   [3] LC_TIME=en_NZ.UTF-8        LC_COLLATE=en_NZ.UTF-8
>>>   [5] LC_MONETARY=en_NZ.UTF-8    LC_MESSAGES=en_NZ.UTF-8
>>>   [7] LC_PAPER=en_NZ.UTF-8       LC_NAME=C
>>>   [9] LC_ADDRESS=C               LC_TELEPHONE=C
>>> [11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C
>>>
>>> attached base packages:
>>> [1] stats     graphics  grDevices utils     datasets  methods   base
>>>
>>> loaded via a namespace (and not attached):
>>> [1] compiler_4.0.0
>>>
>>> Paul
>>>
>>> On 26/05/20 2:21 pm, Kenny Bell wrote:
>>> > Hi all,
>>> >
>>> > I have found after upgrading to R 4.0.0 (among other upgrades so this
>>> may
>>> > not be the cause) that the degree symbol doesn't work correctly on
>>> Ubuntu
>>> > 18.04. Googling brought me to this thread that appears related.
>>> >
>>> > I tried running:
>>> > cairo_pdf()
>>> > plot.new(); text(0.5,0.5, bquote(120*degree*N), cex=5)
>>> > dev.off()
>>> >
>>> > and the ubuntu plot has the degree symbol vertically in the center of
>>> the
>>> > line. The Windows one correctly shows as superscript.
>>> >
>>> > Anyone else see this behaviour?
>>> >
>>> > Cheers,
>>> > Kenny
>>> >
>>> > On Fri, Apr 10, 2020 at 3:36 AM Nicolas Mailhot via R-devel <
>>> > [hidden email]> wrote:
>>> >
>>> >> Le mercredi 08 avril 2020 à 02:55 -0700, Gabriel Becker a écrit :
>>> >>> Hi Paul,
>>> >>
>>> >> Hi Gabriel,
>>> >>
>>> >> Thanks a lot for the testing.
>>> >>
>>> >>> The various font family settings seem to work too, from what I can
>>> >>> tell. Both font families you suggested, however, Helvetica and Apple
>>> >>> Symbols (the s is important) have significantly incomplete coverage
>>> >>> with PUA on.
>>> >>
>>> >> That is to be expected, the AMS symbol dump in PUA space was a quick
>>> >> hack to make pre-unicode symbols available in an unicode world,
>>> pending
>>> >> their normalisation.
>>> >>
>>> >> That standardisation is long past (IIRC it occured by unicode 3.2
>>> >> released in March 2002), so no newly created/updated font family is
>>> >> going to place those symbols in PUA anymore.
>>> >>
>>> >> Now adding the AMS symbols to new fonts has been slow, due to the
>>> large
>>> >> amount of software hardcoding Symbol (and equivallent) and masking the
>>> >> actual glyph userbase to font makers. It will accelerate with more
>>> apps
>>> >> expecting plain unicode by default.
>>> >>
>>> >> Thanks for the testing!
>>> >>
>>> >> Regards,
>>> >>
>>> >> --
>>> >> Nicolas Mailhot
>>> >>
>>> >> ______________________________________________
>>> >> [hidden email] mailing list
>>> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> >>
>>> >>
>>> >> ______________________________________________
>>> >> [hidden email] 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
>>> [hidden email]
>>> http://www.stat.auckland.ac.nz/~paul/
>>>
>>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

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

Kenny Bell-2
I also tried just upgrading to 20.04 and that seemed to fix it.

On Tue, May 26, 2020 at 5:38 PM Kenny Bell <[hidden email]> wrote:

> I can also confirm that the latest  https://hub.docker.com/_/r-base has
> the correct behaviour.
>
> On Tue, May 26, 2020 at 5:05 PM Kenny Bell <[hidden email]> wrote:
>
>> I was actually able to reproduce this on a relatively fresh install of
>> 18.04 (a virtualbox). Paul, did you run apt update && apt upgrade before
>> trying to reproduce?
>>
>> On Tue, May 26, 2020 at 4:36 PM Kenny Bell <[hidden email]> wrote:
>>
>>> Hi Paul,
>>>
>>> I tried downgrading to R 3.4.4 and I still see the problem. I also have
>>> a conda environment that doesn't exhibit the problem so it's something
>>> environmental.
>>>
>>> Any tips for possible solutions/troubleshooting would be appreciated!
>>>
>>> Cheers,
>>> Kenny
>>>
>>> On Tue, May 26, 2020 at 3:09 PM Paul Murrell <[hidden email]>
>>> wrote:
>>>
>>>>
>>>> I am not seeing that problem on my 18.04 ...
>>>>
>>>>  > sessionInfo()
>>>> R version 4.0.0 Patched (2020-05-12 r78431)
>>>> Platform: x86_64-pc-linux-gnu (64-bit)
>>>> Running under: Ubuntu 18.04.4 LTS
>>>>
>>>> Matrix products: default
>>>> BLAS:   /home/pmur002/R/R-4-0-branch/BUILD/lib/libRblas.so
>>>> LAPACK: /home/pmur002/R/R-4-0-branch/BUILD/lib/libRlapack.so
>>>>
>>>> locale:
>>>>   [1] LC_CTYPE=en_NZ.UTF-8       LC_NUMERIC=C
>>>>   [3] LC_TIME=en_NZ.UTF-8        LC_COLLATE=en_NZ.UTF-8
>>>>   [5] LC_MONETARY=en_NZ.UTF-8    LC_MESSAGES=en_NZ.UTF-8
>>>>   [7] LC_PAPER=en_NZ.UTF-8       LC_NAME=C
>>>>   [9] LC_ADDRESS=C               LC_TELEPHONE=C
>>>> [11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C
>>>>
>>>> attached base packages:
>>>> [1] stats     graphics  grDevices utils     datasets  methods   base
>>>>
>>>> loaded via a namespace (and not attached):
>>>> [1] compiler_4.0.0
>>>>
>>>> Paul
>>>>
>>>> On 26/05/20 2:21 pm, Kenny Bell wrote:
>>>> > Hi all,
>>>> >
>>>> > I have found after upgrading to R 4.0.0 (among other upgrades so this
>>>> may
>>>> > not be the cause) that the degree symbol doesn't work correctly on
>>>> Ubuntu
>>>> > 18.04. Googling brought me to this thread that appears related.
>>>> >
>>>> > I tried running:
>>>> > cairo_pdf()
>>>> > plot.new(); text(0.5,0.5, bquote(120*degree*N), cex=5)
>>>> > dev.off()
>>>> >
>>>> > and the ubuntu plot has the degree symbol vertically in the center of
>>>> the
>>>> > line. The Windows one correctly shows as superscript.
>>>> >
>>>> > Anyone else see this behaviour?
>>>> >
>>>> > Cheers,
>>>> > Kenny
>>>> >
>>>> > On Fri, Apr 10, 2020 at 3:36 AM Nicolas Mailhot via R-devel <
>>>> > [hidden email]> wrote:
>>>> >
>>>> >> Le mercredi 08 avril 2020 à 02:55 -0700, Gabriel Becker a écrit :
>>>> >>> Hi Paul,
>>>> >>
>>>> >> Hi Gabriel,
>>>> >>
>>>> >> Thanks a lot for the testing.
>>>> >>
>>>> >>> The various font family settings seem to work too, from what I can
>>>> >>> tell. Both font families you suggested, however, Helvetica and Apple
>>>> >>> Symbols (the s is important) have significantly incomplete coverage
>>>> >>> with PUA on.
>>>> >>
>>>> >> That is to be expected, the AMS symbol dump in PUA space was a quick
>>>> >> hack to make pre-unicode symbols available in an unicode world,
>>>> pending
>>>> >> their normalisation.
>>>> >>
>>>> >> That standardisation is long past (IIRC it occured by unicode 3.2
>>>> >> released in March 2002), so no newly created/updated font family is
>>>> >> going to place those symbols in PUA anymore.
>>>> >>
>>>> >> Now adding the AMS symbols to new fonts has been slow, due to the
>>>> large
>>>> >> amount of software hardcoding Symbol (and equivallent) and masking
>>>> the
>>>> >> actual glyph userbase to font makers. It will accelerate with more
>>>> apps
>>>> >> expecting plain unicode by default.
>>>> >>
>>>> >> Thanks for the testing!
>>>> >>
>>>> >> Regards,
>>>> >>
>>>> >> --
>>>> >> Nicolas Mailhot
>>>> >>
>>>> >> ______________________________________________
>>>> >> [hidden email] mailing list
>>>> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>> >>
>>>> >>
>>>> >> ______________________________________________
>>>> >> [hidden email] 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
>>>> [hidden email]
>>>> http://www.stat.auckland.ac.nz/~paul/
>>>>
>>>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
12