Use the fontawesome package for the HTML dependency on Font Awesome

[rich-iannone]

The fontawesome package maintains an HTML dependency function that Shiny currently uses to generate FA icons. With this PR, the fontawesome package is taken as a dependency itself (in Imports) and the fontawesome::fa_html_dependency() is invoked inside html_dependency_font_awesome() (to keep things simple).

I performed several tests to ensure icons from several generations of Font Awesome appear. I also tested with self-contained: true, self-contained: false, and runtime: shiny and everything passed (FA icon always gets rendered). Here is the R Markdown document that tests HTML output with several generations of FA icons:

---
output: html_document
---

```{r, include=FALSE}
htmltools::tagList(rmarkdown::html_dependency_font_awesome())
library(fontawesome)
```

# Here are icons obtained through the FontAwesome HTML dependency.

## Version 6

<i class="fa-solid fa-bridge-water"></i>
<i class="fa-solid fa-chart-simple"></i>

## Version 5

<i class="fa-solid fa-wifi"></i>
<i class="fa-solid fa-suitcase"></i>
<i class="fa-solid fa-globe"></i>

## Earlier

<i class="fa-solid fa-id-card"></i>
<i class="fa-solid fa-bus"></i>
<i class="fa-solid fa-magnet"></i>

# Here are the same icons obtained through the `fontawesome::fa()` function.

## Version 6

`r fa("bridge-water")`
`r fa("chart-simple")`

## Version 5

`r fa("wifi")`
`r fa("suitcase")`
`r fa("globe")`

## Earlier

`r fa("id-card")`
`r fa("bus")`
`r fa("magnet")`

The rendering of icons has no problems and it matches icons obtained from another method (using fontawesome::fa()):

Fixes: #2276
Fixes: #1661

[cderv]

I also tested with self-contained: true, self-contained: false, and runtime: shiny and everything passed

Did you test R Markdown website too or maybe Flexdashboard ? I think they use the current dependency from rmarkdown directly

[rich-iannone]

Those are good candidates for manual testing. Will definitely test those as well. Thanks!

[cderv]

Some general thoughts after thinking about the topic to maybe discuss live together:

I wonder if we have a benefit to reexport the function from rmarkdown directly. I believe it was done to be used in other package like

• pagedown rstudio/pagedown@db0764a/R/resume.R#L17
• flexdashboard rstudio/flexdashboard@33458ea/R/dependencies.RL4
  as mentioned in Use fontawesome R package for HTML dependencies #2276

However we are indeed using it for navbar in website (see #2042 that needs to be dealt with after / with this topic - mentioning so that it is on your radar) - so we need to use the package anyway in rmarkdown

One scenario I had in mind could be for us to

• Use conditionally fontawesome when navbar is set in R Markdown website. We would have the package as Suggests only, and warn if package is not installed when navbar is used.
• This would mean to have a deprecate strategy for rmarkdown::html_dependency_font_awesome() - start throwing warning for package that may use it, and then removing the exportation. We could do that the xfun way or it would be a could opportunity to leverage some tooling like lifecycle IMO

   > lifecycle::deprecate_soft("a", "rmarkdown::html_dependency_font_awesome()", "fontawesome::fa_html_dependency()")
   Warning message:
   `html_dependency_font_awesome()` was deprecated in rmarkdown a.
   ℹ Please use `fontawesome::fa_html_dependency()` instead.
   This warning is displayed once every 8 hours.
   Call `lifecycle::last_lifecycle_warnings()` to see where this warning was generated. 

• Our other package could use fontawesome directly.

However, before fontawesome package, rmarkdown::html_dependency_font_awesome() was quite used as shown in seach so maybe that is not worth breaking all those usage for one addition to Imports. After writing this, I am thinking this is probably better not to deprecate 🤔

@rich-iannone @yihui some thoughts on that ?

[rich-iannone]

I took the source files from this flexdashboard example (https://testing-apps.shinyapps.io/flexdashboard-shiny-crandash/) and ran it locally. The FA icons appear in their value boxes; they do use the rmarkdown HTML dependency function directly.

[rich-iannone]

I'm more in favor of the non-deprecation route. Also I would like to fix #2042. Perhaps, before merging, we should talk about all the related issues at our next meeting (or sooner).

[yihui]

I am thinking this is probably better not to deprecate

I agree.

[yihui]

We can probably delete the directory inst/rmd/h/fontawesome, too, but it depends on whether we want to Import or Suggest fontawesome. If we want to make fontawesome a soft dependency, we can keep our (outdated) version of fontawesome. I don't have a strong opinion on this. The scope of the problems that we are trying to resolve seems to be narrow in my eyes (i.e., the icons are not actually widely used in this package), so I'm not sure if it's worth a new hard dependency.

[cderv]

The scope of the problems that we are trying to resolve seems to be narrow in my eyes (i.e., the icons are not actually widely used in this package), so I'm not sure if it's worth a new hard dependency.

That is why at first as was thinking about deprecated to remove this function in the long term as user should use fontawesome 📦 directly and not through rmarkdown.

If we want to make fontawesome a soft dependency

This would mean that:

• if fontawesome is available, then we use its HTML dependency
• if not available we fallback to our internal one, even if outdated

Is that right ?

That could be a in-between solution to not Import the package indeed. In that case, I would probably add a message or a warning (probably using xfun::do_once()) to state that an outdated fontawesome would be used and the fontawesome would be used. But one could argue that this is like doing a soft deprecation probably 😅
We could check if an icon is available or not in our version, but probably too much complicated to do and maintain for the benefit.

It is just that silently doing the fallback will not prevent user to not understand why an icon is not showing, and also not teach people about the fontawesome package.

[rich-iannone]

I thought a bit more about this and came away with the conclusion that having to install fontawesome separately might be confusing to a lot of users and it could cause problems when publishing across different environments. Usually for me when there's an 'optional' package there's always a clear error and message to install that optional package (for extra functionality) when using a specific function or argument. But in the case of a soft dependency it could happen that users would have icons appearing or not, or, older versions of icons being shown (not to mention the difficulty of explaining the different versions of the dependency in the documentation).

I agree that an extra dependency is not to be taken lightly but especially given that other packages like flexdashboard use the dependency function from rmarkdown directly (and they are more likely to use icons) this makes the case even stronger for fontawesome to be included in Imports.

[yihui]

Is that right ?

Yes.

Given all the potential trouble, we should probably just make fontawesome a hard dependency.

[rich-iannone]

Thanks for the discussion on this. I've removed the directory that contained the FA font files (inst/rmd/h/fontawesome).

[cderv]

Ok let's do it that way for now, and we can reduce the dependencies in the future if needed.

Thanks @rich-iannone !

[cderv]

@yihui ok for you to merge ?

[yihui]

Yes, I'll merge it in a minute.