Regarding the first message, there is a beamer class option professionalfont which sets an \if, specifically \ifbeamer@suppressreplacements to decide whether beamer would handle some special font stuff or there was some other package to do it instead. unicode-math checks to see if that \if has been set to true and if not, it issues the warning and then sets it to true. So loading unicode-math ensures that that \if is set to true, but it might not be done as early as if you'd set the class option.
However, if you do set the class option, then you will get the warning:
"professionalfont" is obsolete. Use font theme "professionalfonts" instead
There are two things to notice here. First is that the class option is not professionalfonts (as unicode-math claims) but professionalfont. Second, that it is obsolete. Rather, you should issue the command:
\usefonttheme{professionalfonts}
somewhere in your preamble. What this does is:
\mode<presentation>{\beamer@suppressreplacementstrue}
so it sets the same \if but only in presentation mode. Thus it is ignored in article mode. Since the unicode-math test only checks for the class being beamer, and not for the beamerarticle package, this is consistent. Thus the correct preamble is:
\documentclass{beamer}
\usefonttheme{professionalfonts}
\usepackage{unicode-math}
Lastly, there should not be any actual problem if the middle line is missed since all it does is what unicode-math does when checking for the beamer class. Thus the actual effect of the middle line is to suppress the warning with the unicode-math package.
(Andrew now goes off and changes the preamble of his presentations because he'd been getting that warning with the professionalfonts class option and not understanding why he got it.)
The user guide of the fontspec package is indeed quite lengthy. However, I would not go as far as calling it intimidating. There's a huge and wonderful world out there related to OpenType and TrueType fonts, and it's not surprising (to me at least) that the manual that explains how to explore this world isn't brief.
In what follows, I will assume that your tex document is encoded according to the UTF8 standard. Aside: If your document uses only ASCII, it's automatically UTF8-compliant.
I have an educated guess as to why the user guide of the fontspec package doesn't explain how one might "translate" directives such as \usepackage{lmodern}, \renewcommand{\sfdefault}{cmbr}, \usepackage{charter}, or \usepackage[scaled=0.85]{beramono} to LuaLaTeX. The putative reason is quite simple: For the most part, no translation is necessary. If you're going to use font packages with LuaLaTeX that were designed originally for use under pdfLaTeX, just keep using them under LuaLaTeX and you'll be fine. (Do see below, though, for same caveats and exceptions.) If you do so, though, don't load the fontspec package as well.
For instance, the program
\documentclass{article}
\usepackage{lmodern}
\renewcommand{\sfdefault}{cmbr}
\begin{document}
The quick brown fox jumps over the lazy dog.
\sffamily
The quick brown fox jumps over the lazy dog.
\end{document}
produces the same output when run under either pdfLaTeX or LuaLaTeX:
Likewise, the program
\documentclass{article}
\usepackage{charter}
\usepackage[scaled=0.85]{beramono}
\begin{document}
The quick brown fox jumps over the lazy dog.
\sffamily
The quick brown fox jumps over the lazy dog.
\end{document}
produces the same output when compiled with either pdfLaTeX or LuaLaTeX:
The qualifier "for the most part" that was used above needs some explaining. As @UlrikeFischer points outs in a comment, an adjustment to the approach outlined above is necessary if the document contains "accented" characters which aren't included in the basic ASCII character set. (As noted above, I assume that the entire document is UTF-8 encoded.) If the document contains such characters, it is necessary to load the luainputenc package with the option utf8. With this adjustment made, the following code
\documentclass{article}
\usepackage[utf8]{luainputenc} % Not: "\usepackage[utf8]{inputenc}"
\usepackage{newtxtext}
\begin{document}
Grüße äöüÄÖÜ, \em Grüße äöüÄÖÜ
\end{document}
once again produces identical results when compiled under pdfLaTeX and LuaLaTeX:
Excerpting from the user guide of the luainputenc package:
From the user point of view, adapting an old document for LuaTEX is really easy: replacing inputenc by luainputenc in the preamble is enough. Note that luainputenc automatically loads inputenc if called with an old engine, so you will still be able to compile your documents with pdfTEX without changing them
That said, as @UlrikeFischer has pointed out in comments to this answer, some issues related to hyphenation may remain if you're using the luainputenc package. For instance, words with accented characters (like Grüße) may no longer be hyphenated, and LuaLaTeX's output may therefore not be exactly the same as if using pdflatex. Hence, in the long run it may nevertheless be a good idea to switch to fontspec in order to obtain optimal results.
When working with OpenType fonts, there are no packages -- with only a few exceptions (eg., the Libertine font family) -- that allow them to be used under pdf(La)TeX. To use OpenType fonts, one thus has to use either Xe(La)TeX or Lua(La)TeX -- typically in conjunction with the fontspec package. Since these fonts can't be used under pdfLaTeX anyway, a translation of instructions wouldn't be meaningful, right?
Best Answer
Your example works as there exists suitable font definitions files for the "lmr" and the "lmss" families for the EU2 font encoding in the
euencpackage. (If you look in the log-file you will see that aeu2lmss.fdis loaded).If you would replace
lmodernby e.g.timesit would no longer work. You would see in the log-file a warning:And the document wouldn't use helvet but the fallback lmr.
To be able to use the helvet font you would have to switch the fontencoding to an encoding for which font definitions for helvet exists, e.g. T1-encoding. But with this encoding you will no longer be able to input non-ascii-chars directly: