# Issue with Bera font and fontenc package

I'm using \usepackage[T1]{fontenc} to typeset an article in LaTeX. Using the default font, the input

Erd\H{o}s


produces the desired

Erdős


in the output, which I can copy and paste properly. Based on my understanding, this is thanks to the package fontenc However, when I use the font \usepackage{bera} in addition to \usepackage[T1]{fontenc}, the same output now copies and pastes as

Erd ̋
os


which is what I would get if I wasn't using \usepackage[T1]{fontenc} in the first place. Am I missing something? This happens regardless of which package I load first.

Edit: Here's an example of what I mean. Depending on whether or not I use the Bera font, I get different results for the output.

\documentclass{amsart}

%\usepackage{bera}
\usepackage[T1]{fontenc}

\begin{document}

Erd\H{o}s

\end{document}

• Welcome! Please can you give us compilable code rather than just a snippet? – cfr Jul 25 '18 at 22:32
• I edited the post. I'm also using pdfLaTeX, so that's strange to me. – Benson Jul 25 '18 at 22:40
• Odd, maybe I'll try to find another machine to test it on. Thanks! – Benson Jul 25 '18 at 22:43
• With or without \usepackage[T1]{fontenc} is irrelevant, because the package bera loads it anyway. I can confirm the issue with Bera, which depends from the fact that the font used is a virtual one that composes the ő with an o and the double acute accent, rather than having a single glyph. – egreg Jul 25 '18 at 22:44
• @egreg Why does it work for me? – cfr Jul 25 '18 at 22:49

If DejaVu Serif, Sans and Mono is an option, but you do not wish (or cannot) switch to another engine or just don't want to mess around with fontspec and extended compilation times, you can perfectly well use these fonts with pdfTeX instead.

\documentclass{amsart}

\usepackage{dejavu}
\usepackage[T1]{fontenc}

\begin{document}

Erd\H{o}s

\end{document}


Moreover, if you do want to use the opentype versions with XeTeX or LuaTeX, the recommended approach would be to use the relevant package:

\documentclass{amsart}

\usepackage{dejavu-otf}

\begin{document}

Erd\H{o}s

\end{document}


Do note, too, that, if you prefer, you can write Erdős in your source. This will work out-of-the box with XeTeX or LuaTeX. For pdfTeX, add

\usepackage[utf8]{inputenc}


If using this line or using XeTeX or LuaTeX, you must ensure that your .tex file is saved in UTF8 encoding. This is generally default for most editors nowadays, but there are some exceptions such as TeXShop.

• Thanks for this answer! I wasn’t aware of that package, which seems to have been added a few months ago. It does work in pdflatex and solve the issue. +1 – Davislor Jul 26 '18 at 2:15
• Also note that UTF-8 input encoding has been the default in LaTeX since April 2018. I still leave \inputenc in my pdflatex examples for the sake of anyone using an older version. – Davislor Jul 26 '18 at 2:17
• @Davislor Eek! I didn't know that. What about TeXShop? – cfr Jul 26 '18 at 3:08
• It’s a change to the LaTeX 3 core, so I think it affects everything, but I haven’t tried TeXShop specifically. I’ve been using UTF-8 religiously for a while now anyway, and \usepackage[utf8]{inputenc} is, so far as I know, completely benign? So. I’ve kept it in my code samples and never had a problem. – Davislor Jul 26 '18 at 3:12
• @Davislor Almost everything I have is UTF8 encoded (but not quite everything). But TeXShop does not use UTF8 encoding by default - unless it has changed very recently. (It took me a while to figure this out as it didn't occur to me for a while that this was why the student's code wasn't working as I expected. Fresh install of MacTeX, all defaults ...) – cfr Jul 26 '18 at 3:16

While @egreg diagnosed your problem in the comments, let me give you a workaround.

The Bera family of fonts is a clone of Bitstream Vera. So are the DejaVu fonts, which are in modern encodings, with extremely good coverage of Unicode. You can use those instead in either lualatex or xelatex.

\documentclass[varwidth, preview]{standalone}
\usepackage{fontspec}

\setmainfont{DejaVu Serif}
\defaultfontfeatures{Scale=MatchUppercase}
\setsansfont{DejaVu Sans}
\setmonofont{DejaVu Sans Mono}

\begin{document}
Paul Erd\H{o}s \textit{Paul Erdős} \textbf{Paul Erdős \textit{Paul Erdős}}

\textsf{Paul Erd\H{o}s \textit{Paul Erdős} \textbf{Paul Erdős \textit{Paul Erdős}}}

\texttt{Paul Erd\H{o}s \textit{Paul Erdős} \textbf{Paul Erdős \textit{Paul Erdős}}}
\end{document}


There are even two versions of a math font matching it, TeX Gyre DejaVu Math, which you can use in unicode-math. Unfortunately, it does not support sans-serif letters.

Since this sets the encoding to Unicode, copy-and-paste works. In fact, I used it to paste Erdős back into the document.

Compare the output with Bera, for which copying and pasting fails:

\documentclass[varwidth, preview]{standalone}
\usepackage[T1]{fontenc} % Redundant with bera.
\usepackage{textcomp}
\usepackage[utf8]{inputenc} % The default since 2018
\usepackage{bera}

\begin{document}
Paul Erd\H{o}s \textit{Paul Erdős} \textbf{Paul Erdős \textit{Paul Erdős}}

\textsf{Paul Erd\H{o}s \textit{Paul Erdős} \textbf{Paul Erdős \textit{Paul Erdős}}}

\texttt{Paul Erd\H{o}s \textit{Paul Erdős} \textbf{Paul Erdős \textit{Paul Erdős}}}
\end{document}


### ETA:

@cfr points out that there are also dejavu and dejavu-otf packages. Loading dejavu instead of bera fixes your issue and also works in pdflatex, which this approach does not. See her answer for details. That said, do consider upgrading to the modern toolchain.

I wasn’t aware of dejavu-otf until she pointed it out to me, and it probably is a good idea to load it if its settings work for you, as she suggests. It’s likely to get updated if the commands you need to load the fonts ever change. And, if you install the package and update from time to time, you’re sure to have the latest version of the fonts.

• I realise this is one of your standard formulae, but there is no good reason to do it this way in this case and doing it this way just makes things look a whole lot more complicated than they need to be. First, the OP does not need to switch engines to use DejaVu. Second, if the OP does wish to switch, manual fontspec configuration is not the best way to do it. – cfr Jul 26 '18 at 1:42
• @cfr Your way of loading the package is fine, but I don’t think mine is wrong, and there have been times I’ve needed to. Two reasons that I’ve run into: scaling automatically to the height of the main font rather than with a manual package option, and switching to the font only for one particular script. – Davislor Jul 26 '18 at 2:22
• Of course yours isn't wrong and of course you may need to. But for people copying code from here into their documents, I think the package is a much better option. You want the complexity, but somebody looking for an answer here is, statistically, more likely to just want something which works by default. – cfr Jul 26 '18 at 3:07
• @cfr I also recently became aware that Will Robertson is deprecating the kind of font selection I used here and now suggests loading families by file names. That is complicated enough and fragile enough that I’d rather just use the package. Up to now, I’ve honestly found it simpler to use the same standard formula, as you say. – Davislor Jul 26 '18 at 3:07
• I heard vaguely about that. Won't that cause no end of trouble? Or is that just me? – cfr Jul 26 '18 at 3:12

When \usepackage{bera} is loaded, the output font encoding is automatically switched to T1, so loading \usepackage[T1]{fontenc} explicitly or not is irrelevant.

What is the problem? Let's look in the beraserif subpackage, to discover that the font family name is fve; therefore we look for t1fve.fd, that shows

\DeclareFontShape{T1}{fve}{m}{n}{
<-> \fve@@Scale fver8t
}{}


OK, 8t, according to Karl Berry’s font name scheme means a T1 encoded font. However, we can examine it with vftovp fver8t to get output starting with

(VTITLE )
(FAMILY UNSPECIFIED)
(FACE F MRR)
(CODINGSCHEME EXTENDED TEX FONT ENCODING - LATIN)
(DESIGNSIZE R 10.0)
(COMMENT DESIGNSIZE IS IN POINTS)
(COMMENT OTHER SIZES ARE MULTIPLES OF DESIGNSIZE)
(CHECKSUM O 10526223250)
(FONTDIMEN
(SLANT R 0.0)
(SPACE R 0.318)
(STRETCH R 0.191)
(SHRINK R 0.076)
(XHEIGHT R 0.519)
(EXTRASPACE R 0.076)
(PARAMETER D 8 R 0.729)
(PARAMETER D 9 R 0.76)
(PARAMETER D 10 R 0.928)
(PARAMETER D 11 R 0.222)
(PARAMETER D 12 R 0.928)
(PARAMETER D 13 R 0.236)
(PARAMETER D 14 R 0.636)
(PARAMETER D 15 R 0.0)
(PARAMETER D 16 R 1.2)
)
(MAPFONT D 0
(FONTNAME fver8r)
(FONTCHECKSUM O 12607565666)
(FONTAT R 1.0)
(FONTDSIZE R 10.0)
)


This is a virtual font, using the “raw” fver8r as base and remapping it. Now we can look into tables and discover that ő is assigned slot '245 (octal) in the T1 encoding; so let's look for O 256 in the human readable form of the virtual font:

(CHARACTER O 256
(CHARWD R 0.602)
(CHARHT R 0.7955)
(CHARDP R 0.020499)
(MAP
(PUSH)
(MOVEDOWN R -0.014)
(MOVERIGHT R 0.051)
(SETCHAR O 5)
(POP)
(SETCHAR C o)
)
)


Hey! It seems we found the problem! The “ő” glyph is composed of two glyphs from the raw font. Let's try the final experiment. Compile with pdftex the following test file

\pdfcompresslevel=0
\pdfobjcompresslevel=0
\nopagenumbers

\font\test=fver8t \test

\char'256

\bye


The first two instruction will make an almost human readable PDF file. At its start we find

3 0 obj
<<
/Length 74
>>
stream
BT
/F52 9.9626 Tf 92.433 760.067 Td [(\005)]TJ -0.508 -0.14 Td [(o)]TJ
ET

endstream
endobj


that makes the problem clear: the PDF file encodes two glyphs. Why the accent appears after the “o” on copying and pasting depends on features and heuristics of PDF viewers.

If you look in the output of vftovp, you'll see that every accented character is realized in a similar way to ő.

With other fonts this doesn't happen. For instance, with \usepackage{dejavu} the font family name is DejaVuSerif-TLF and a similar trail following as before leads to examining the output of vftovp DejaVuSerif-tlf-t1 where we find

(CHARACTER O 256
(CHARWD R 0.6021)
(CHARHT R 0.7925)
(CHARDP R 0.0137)
(MAP
(SETCHAR O 256)
)
)


No composed glyph! Hurray!